Does HITRUST publish one required AI risk-assessment template?

HITRUST supplies the assessment framework and control structure. The organization's exact risk record depends on scope, assessment type, system facts, and assessor guidance. Use the current HITRUST materials and confirm the selected assessment requirements with the authorized assessor.

Can a provider certification replace request-level assessment?

A provider report describes the covered provider environment and period. The deploying organization still decides who may use the model and what data may leave. Request-level evidence shows that local decision in operation.

How often should the assessment be reviewed?

Set a scheduled review and event triggers. A new model or provider is a trigger. A new data class is another. Material policy changes, incidents, and changed downstream decisions should reopen the file.

HITRUST AI Risk Assessment at the LLM Request Boundary

A HITRUST AI risk assessment needs a defined system and a testable request path. The useful unit is one authenticated person or agent sending one classified prompt through an approved HTTP route to one model endpoint. That unit gives the assessment team something it can inspect and sample.

The HITRUST CSF is a broad information-security and privacy framework. HITRUST says the framework is the foundation for its e1, i1, and r2 assessments. An LLM gateway supplies evidence for part of that scope. It does not own the assessment.

TL;DR

A HITRUST AI risk assessment starts with the real LLM data flow and the people accountable for it.
Each risk needs an owner, a control, evidence, and a residual-risk decision.
Request evidence should preserve identity and data class, plus model destination and policy version. It also needs time and outcome.
Controls for local tools, model development, endpoints, and human decisions need separate owners.

Define the assessment object before scoring risk

Start with one business use case. Name the application, its owner, the people affected, and the decision supported by the model. Draw the path from authenticated user to the application. Continue through retrieval and the HTTP policy point, then finish at the model provider and output recipient.

A whiteboard diagram with six boxes is more useful than a vendor slide covered in certification logos. The diagram shows where personal information enters and where the prompt crosses organizational custody. It also exposes direct provider routes that bypass policy.

Record the model family and endpoint. Add the provider account, deployment region, retention setting, and approved purpose. The system boundary is now specific enough for a control owner to test.

The AI DPIA guide gives the wider privacy assessment structure. The HITRUST file should link that privacy record to the technical path instead of repeating it.

Identify risk at prompt and response level

Risk statements should describe an event and consequence. "Sensitive clinical text reaches an unapproved model" is testable. "AI may create privacy concerns" is too vague for control design.

Prompt risks include unauthorized users and excessive context. They also include an unapproved provider or a route with the wrong retention setting. Response risks include unsupported clinical text entering a record, sensitive output reaching the wrong person, and an unsafe downstream action.

Score likelihood and impact using the organization's approved method. Keep the factual basis beside the score. A high score may come from patient impact or regulatory exposure. It can also come from broad access and weak detection. The score is a decision aid, rather than a substitute for architecture.

My opinion is that a risk register without one sampled request is paperwork about a system nobody has observed. The team should open a permitted event and a refused event during review.

Map each risk to an operating control

An identity risk maps to authentication outside the gateway and authorization at the request boundary. The application supplies the verified user or workload identity. Policy decides which model and route that principal may use.

A disclosure risk maps to prompt classification and destination policy. The control inspects the assembled request immediately before transmission. It may permit the call, redact selected content, choose an approved route, or refuse the request.

A configuration risk maps to version control and approval. Model allowlists and data rules need named owners. Every decision record should retain the active policy version so the assessor can connect behavior to the approved configuration.

An evidence risk maps to an independent record. The record is stronger when the application cannot rewrite its own authorization history. The HITRUST AI audit evidence guide lists the fields and sampling pattern.

Use NIST AI RMF as a supporting AI view

The NIST AI Risk Management Framework is voluntary. NIST describes it as a way to include trustworthiness considerations in the design and use of AI systems. Its Govern, Map, Measure, and Manage functions can help the assessment team organize AI-specific questions while HITRUST remains the chosen assurance framework.

Govern identifies ownership and risk tolerance. Map captures context and affected parties. Measure tests model behavior and control performance. Manage records treatment and acceptance decisions.

The mapping should stay explicit. A NIST AI RMF worksheet is supporting evidence. It is not a HITRUST certification, and it cannot prove that production requests followed policy.

Build an evidence packet an assessor can sample

The evidence packet needs design records and operating records. Design evidence includes the data-flow diagram, approved use case, model register, policy, test plan, and owner approvals. Operating evidence includes allowed requests and denied requests. It also includes policy changes and incident tickets.

For each sampled request, retain a stable event identifier. Record the originating identity and acting agent. Add purpose, content classification, endpoint, region, policy version, decision, and timestamp. Keep a content hash when full prompt retention would create unnecessary risk.

Place one printed sample on the conference-room table. The assessor should be able to move from the risk statement to the control and then to that event without guessing which system holds the proof.

State inherited controls and uncovered paths

Provider assurance can support physical controls and platform security. Contract terms can support retention and incident duties. Those inherited controls do not prove that a particular employee had authority to send a patient record on Tuesday.

List every uncovered path. Local model execution is outside an HTTP gateway. So are STDIO tools and direct database calls. Endpoint compromise and stolen credentials need other controls. Model training and validation need their own evidence. Human review rights belong to the application workflow.

This boundary statement is part of the risk treatment. It prevents one product from receiving credit for controls it cannot perform and makes the remaining owner visible.

DeepInspect

DeepInspect is an enforcement point for HTTP traffic between authenticated users or agents and LLM endpoints. It can evaluate application-supplied identity, classify prompt content, enforce model and destination policy, and record each decision outside the calling application's write path.

That evidence can support the request-boundary portion of a HITRUST AI risk assessment. Legal scope and risk acceptance remain with the organization. Endpoint security, local execution, model development, and human decision controls remain with their named owners.

Book a technical deep dive at deepinspect.ai.