HITRUST AI Risk Management Assessment guide

What the HITRUST AI Risk Management Assessment asks for

The HITRUST AI Risk Management Assessment is a non-certified assessment of how an organization manages risk across its AI systems, using 51 curated controls mapped to the NIST AI RMF and ISO/IEC 23894:2023. Its output is an AI Risk Management Insights Report, not a certificate. If a customer, board or regulator has asked for evidence of AI risk management, this assessment answers that request with a scored, documented view of your practices, and it tells you where the gaps are. The risk it addresses is AI systems that nobody owns, measures or reviews. In practice this usually means a product team has put a model or an AI-enabled feature into production, a data science group runs another, and a business unit buys a third from a vendor, with no single list of what exists. Three problems make this hard to fix. Ownership is split across engineering, security, legal, data and the business. Many organizations have no inventory of AI systems that records purpose, data sources and owners. And few have agreed risk criteria, so one team calls a system high risk while another calls the same system low risk. The assessment forces these questions into the open, which is often the most useful part of the work.

The assessment also incorporates guidance from the OWASP Top 10 for LLMs, so it covers failure modes specific to language models such as prompt injection, sensitive data disclosure and insecure output handling, alongside governance and risk processes. Confirm with HITRUST which edition of that OWASP guidance the current assessment version references, since OWASP revises its lists. Do not confuse this assessment with the HITRUST AI Security Assessment and Certification, which tests security controls on deployed AI systems and can result in an ai1 or ai2 certification. The risk management assessment asks whether your AI risk process works. The security certification asks whether specific AI systems are secured. Before you commit, decide which question your customer or regulator is asking, and whether a non-certified report will satisfy it.

Which AI systems, teams and vendors fall inside the assessment

The AI Risk Management Assessment covers what the organization says it covers, so scope is the first decision that shapes the work. The cards below separate the decisions that change effort most: the inventory, the teams that own AI, third-party models, and the data that feeds them.

Build the AI system inventory first

Every AI system, model and AI-enabled feature the organization uses needs a row in one inventory before scope can be set. Include internal models, fine-tuned models, prompt-driven features and AI embedded in products bought from others. Record owner, purpose, users and whether the system touches regulated data. An incomplete inventory is the most common reason scope changes after kickoff, so ask your assessor how they expect the list to be evidenced. Each unlisted system is a gap an assessor can raise later.

Decide which use cases are in scope

Scope is set by use case as well as by system. The same model can be low risk in an internal summarization tool and high risk in a patient-facing or credit-related workflow. Document each use case, the decisions it informs and the people affected by its outputs. Use cases that influence regulated decisions usually need deeper risk treatment and more evidence of monitoring, so their inclusion changes the amount of work per control area.

Map which business units build, buy and deploy AI

AI work usually sits in several places: data science teams that build models, product teams that embed AI features, and operations teams that deploy vendor tools. Each group runs its own risk decisions, so each one needs a named owner in scope. Ask who approves new AI use, who signs off on model changes and who can switch a system off. Gaps between these groups tend to surface during evidence collection, when no one can show the approval record for a given system.

Treat third-party models and AI services explicitly

Models and AI APIs supplied by vendors still create risk the organization must manage, even when the vendor controls the training data and infrastructure. Decide whether each third-party model is in scope as a system the organization deploys, and collect the vendor evidence the organization relies on. Shared responsibility for these services should be written down, including who monitors output quality and who handles vendor model changes. Reliance on a vendor's own attestations does not remove the need to show the organization's own oversight.

Trace the data that feeds each system

Training data, fine-tuning sets, retrieval sources and prompt inputs all determine what a system can leak or get wrong. Map where each dataset comes from, who may use it, whether it contains personal or regulated information and how long it is retained. Retrieval pipelines that index internal documents often reach more data than the use case needs, so check access scope as well as source. Data flows that cross into vendor systems are a frequent source of scope questions.

Confirm what the assessor will test

Before fieldwork, agree in writing which systems, teams and vendors the assessment covers and which are excluded with a reason. Exclusions that look reasonable internally may not hold up when an assessor asks how the excluded system was kept out of the AI inventory. Confirm how the scope will be recorded in the Insights Report so later customers and auditors can see what was assessed. Revisit scope when AI systems, processes or regulatory requirements change significantly, since HITRUST recommends repeating the assessment at least annually.

How an assessor tests AI risk management practices

This table shows how an assessor examines each area of AI risk management in a HITRUST AI Risk Management Assessment, what evidence they request and where organizations commonly fall short. Read it as a preparation checklist: each row names a test, the proof it needs and the gap that most often appears.

Control area	How the assessor tests it	Evidence requested	Common finding
AI risk policy and governance	Reviews whether the AI risk policy assigns accountability, defines scope and is approved by appropriate leadership	Approved policy, governance charter, role assignments and meeting records showing oversight	Policy exists but roles are not assigned to named owners
AI system inventory	Compares the inventory against systems in use, including vendor-provided and embedded AI features	Current AI inventory with owners, purpose and data sources, plus discovery method used	Inventory omits shadow AI tools or third-party models in production
Interviews with system owners	Asks owners how risks were identified, treated and reviewed for their systems, and checks answers against records	Interview notes and owner-confirmed risk descriptions	Owners describe controls that the risk register does not reflect
Sampling against the risk process	Selects AI systems and traces each through identification, assessment, treatment and monitoring	Risk assessments, treatment plans and monitoring outputs for each sampled system	Sampled systems have no completed risk assessment before go-live
Risk registers, scorecards and treatment decisions	Inspects risk entries for rating basis, treatment choice and link to the responsible owner	Risk register extracts, scoring criteria, treatment decisions and residual risk ratings	Risk accepted without owner sign-off or documented rationale
Re-assessment triggers	Checks whether changes in systems, processes or regulatory requirements prompted a documented review	Change records, regulatory tracking notes and dated re-assessment history	No defined trigger, so risks stay unchanged after model or data changes
Results and reporting	Scores each area and records gaps, then issues the AI Risk Management Insights Report with maturity levels and prioritized recommendations	Assessor scorecards, maturity ratings, gap analysis and recommendation list in the Insights Report	Non-certified outcome: findings guide improvement but do not produce a certificate

How to prepare for the AI Risk Management Assessment, step by step

This sequence moves an organization from an unknown AI estate to a documented, evidenced position against the assessment's harmonized controls, so the independent review starts from known facts rather than discovery.

Build the AI system inventory
The organization lists every AI system it builds, buys, embeds or relies on, including models, third-party AI services, internal tools that call a model, and any agents with tool access. Each entry names the business owner, the technical owner, the data it touches and the people or customers it affects. The step is done when every system has a row in one inventory that the risk owners have reviewed and signed off. Teams often miss shadow AI and vendor features, so the inventory should be checked against procurement records and access logs before it is accepted.
Define risk criteria and ownership
Leadership sets how AI risk is rated, such as the impact categories, likelihood scale and the thresholds that trigger a review or a stop. It also assigns a named owner for each risk category and each system, and defines who approves exceptions. The output is a written risk criteria document and a responsibility map that the inventory points to. Without this, later scoring has no agreed basis, so the assessor will have no consistent way to judge the ratings the organization reports.
Map existing practices to the framework topics
The team compares current policies, procedures and technical controls against the NIST AI RMF functions of Govern, Map, Measure and Manage, and against the topics in ISO/IEC 23894:2023. Each practice is linked to the function or topic it supports, and gaps are marked where no practice exists. The output is a crosswalk workbook that shows which practices cover which topics, with the owner and location of the supporting document. Confirm the current assessment control set and its mapping directly in HITRUST's materials, since the controls are curated and the mapping may be refreshed.
Run a self-assessment to find gaps
Using the crosswalk, a team that does not include the people who built the controls scores each relevant control on whether a documented procedure exists, whether it is in use, and whether there is evidence it works. The team records every gap with a short description and an assigned owner. The output is a gap register ranked by risk from the inventory. Self-assessment results stay internal and are not submitted, so they can be candid. Organizations that have run other HITRUST readiness work often reuse that method here, but the scoring rules and evidence expectations differ and should be checked against the current assessment materials.
Close gaps with documented procedures
Owners write or revise the procedures that address each gap, such as model intake review, evaluation before release, prompt injection testing, data handling for training and retrieval, monitoring of model behavior, and incident handling for AI failures. Each procedure is approved, dated and assigned to the people who run it. The output is a versioned set of AI risk procedures and a register that marks each gap as closed, accepted with a documented risk decision, or still open. Staff should be trained on the procedures before the evidence period begins, so the records show practice rather than paperwork.
Collect evidence samples
The organization gathers the records that show each procedure running: review tickets, risk register entries, evaluation reports, test results from red teaming or tools such as garak, trace or monitoring logs from platforms such as Langfuse, change approvals and incident records. Evidence is kept for a defined period and stored where it can be retrieved with its date and owner. The output is an evidence index that links each control to the samples that support it. Samples should come from real operation, and any gaps in the record should be explained rather than filled in after the fact.
Engage an independent assessor
Once the inventory, procedures and evidence are in place, the organization asks an independent assessor to review them and issue the AI Risk Management Insights Report. The organization should confirm who the assessor is, how the engagement is scoped, what the assessor will test, and what the report covers before work begins. A readiness partner can help assemble the systems and evidence, but only the independent assessor issues the report. The output is a signed scope, an evidence package ready for review and a named assessor contact. Plan the assessment again at least annually, or sooner when AI systems, processes or regulatory requirements change significantly, as HITRUST recommends.

Evidence that supports each AI risk management area

The AI Risk Management Assessment is judged on whether your records show a working process, not a one-time document set. The six artifacts below connect the inventory, the risk decisions, the operating evidence and the governance record, so each can be traced to the others when an assessor samples them.

AI system inventory

The inventory lists every AI system in scope, with its owner, purpose, data sources, model or vendor dependencies and the business processes it touches. It is the starting point for every other artifact, because an assessor will test whether risk assessments cover systems that actually exist. Check that shadow tools, embedded vendor AI features and retired systems are recorded or explicitly excluded with a reason. Review it on a fixed cadence and whenever a new system is approved or an existing one changes its data or model. Ask your assessor early which level of detail they expect for vendor-hosted models.

Risk assessment records with criteria

Each AI system needs a written risk assessment that states the criteria used to rate likelihood and impact, the risks identified (for example, hallucination, data leakage, prompt injection or biased outputs) and the scoring applied. Assessors look for consistent criteria across systems, not a different method for each team. Keep the criteria document versioned so you can show which version applied to each assessment. Record who reviewed the assessment and when it was last revisited.

Risk treatment and acceptance decisions

For every identified risk, the record should show whether it was mitigated, transferred, avoided or accepted, and the controls that support that choice. Acceptance decisions need a named owner with authority to accept the risk, the date of approval and any conditions attached. An assessor will test whether accepted risks are revisited and whether owners can explain their reasoning. Avoid generic sign-offs by a shared mailbox. Confirm with your assessor how they want residual risk recorded before the cycle starts.

Monitoring and test results from AI systems

Operating evidence shows that the risks you identified are watched in production. This includes logs of model behavior, traces of requests through retrieval and tool steps, and results from adversarial or red team testing. Open-source tools such as garak for probing language models and Langfuse for tracing requests can produce this evidence, but the test scope, schedule and findings still need to be documented and tied back to the risk register. Check that findings produce tracked actions rather than disappearing into a log.

Change records that trigger re-assessment

Change records show when a model version, prompt set, data source, vendor or regulatory requirement changed, and whether that change triggered a review of the affected risk assessment. HITRUST recommends performing the assessment at least annually or when AI systems, processes or regulatory requirements change significantly, so the link between change tickets and risk reviews is what an assessor will test. Define in writing what counts as a significant change for your organization, and keep the decision recorded even when you conclude no re-assessment is needed.

Governance meeting minutes

Minutes from AI governance or risk committee meetings show who reviewed inventory changes, risk acceptances and monitoring results, and what they decided. Assessors use them to confirm that governance is active between annual cycles and that decisions flow into the risk register. Record attendance, decisions, owners and due dates, and keep the minutes with the artifacts they reference. Confirm with your assessor how many meetings and which topics they expect to see for the period under review.

What the HITRUST AI Risk Management Assessment costs to meet

This table lists the cost components an organization should expect when preparing for the AI Risk Management Assessment, who is paid for each, whether it is one-time or recurring, and what moves it up or down. Use it to structure your request for a written scope and quote, since no figures are given here and fees come from each provider's quote.

Cost component	Who is paid or who bears it	One-time or recurring	What drives it up or down
Assessment fee	The external assessor or HITRUST, as set out in the engagement quote	One-time per assessment cycle, repeated when reassessed	Number of AI systems in scope, number of third-party models, and whether the assessment is scoped to one business unit or the enterprise
Internal staff time for inventory and risk workshops	Your own staff (no external fee, but a real internal cost)	One-time to build, then recurring at each review	A current AI system inventory lowers effort; many undocumented pilots or shadow AI tools raise it
Technical testing of AI systems	Your internal security team or a testing provider you contract separately	Recurring, at least annually or after significant change	Number of models and agents, use of prompt injection and jailbreak testing, and whether earlier test results can be reused
Evidence upkeep	Your control owners and compliance staff	Recurring throughout the assessment period	Automated logging and version-controlled records reduce effort; manual screenshots and spreadsheets increase it
External readiness help	Consultants or implementation partners, under a written scope	One-time for readiness, optional recurring support	Maturity of existing AI governance, number of regulated use cases, and how much work your team can absorb
Regulated use case analysis	Your legal, privacy and risk teams, plus any outside counsel you retain	Recurring when new use cases or regulations arise	Number of AI uses that touch regulated data or decisions, and how often regulations change
Report review and remediation	Your internal teams and any providers you engage to close gaps	One-time per cycle, with ongoing remediation	Number of prioritized recommendations and the size of gaps found in the Insights Report

Open-source tools that produce AI risk evidence

No open-source tool assesses an AI risk management practice or issues a result. The organization owns its AI risk decisions, an authorized assessor reviews the evidence, and HITRUST performs its own quality review. Tools matter because they produce the raw records an assessor will sample. Three tools map to evidence the HITRUST AI Risk Management Assessment asks organizations to show: adversarial testing of models, runtime monitoring of AI applications, and framework-based tracking of compliance mapping. Each has a license obligation that affects how you deploy it, so check those before building an evidence process around it.

garak (Apache-2.0) probes language models for hallucination, data leakage, prompt injection, misinformation, toxicity generation and jailbreaks. Each run writes a JSONL report of every attempt and evaluation, plus a hit log of attempts that found a vulnerability. The hit log is useful evidence for measurement and testing practices, provided you keep the run configuration, model version and date with each report so a reviewer can tie results to a specific system state. Read the garak README on GitHub to confirm which probes and generators your version supports. Plan for the fact that a clean run shows only what the probes tested, not that the model is free of risk.

Langfuse (MIT) captures traces of each request, including LLM calls, retrieval steps, tool executions, timing, inputs, outputs, token usage and metadata. These traces support monitoring and incident evidence, such as showing how an AI system behaved over a period or reconstructing a flagged interaction. Decide early what you log, since prompts and outputs can contain personal or regulated data, and confirm your retention and access controls match that data. The Langfuse observability overview describes trace structure. CISO Assistant (AGPL-3.0-only) ships a large framework library and runs assessments with automatic mapping between frameworks. Confirm inside your installed version whether NIST AI RMF content is present and current before relying on it, because the library changes. If you modify CISO Assistant and make it available to users over a network, AGPL-3.0 requires you to offer those users the corresponding source, so check this with counsel before deployment.

In-house team, implementation partner and assessor roles

Your organization owns its AI risk program. Staff who understand the business purpose of each AI system must make the decisions an assessor will later test, because no outside party can accept risk on your behalf or set the criteria your leaders are accountable for.

AI system inventory: Named owners maintain the list of AI systems, models, vendors and use cases, and confirm that it is complete and current.
Risk criteria and appetite: Leadership sets how AI risk is rated, what level of residual risk is acceptable and who may accept it.
Risk acceptance: Designated executives record each accepted risk in writing, with the reasoning, the compensating measures and a review date.
System owner accountability: Each owner answers for the data a system uses, its intended purpose, human oversight and changes to its behavior.
Recurring review: Schedule an annual review and an additional review after significant changes to systems, processes or regulatory requirements, as HITRUST recommends for this assessment.

Before the assessment, confirm that every AI risk decision has a named owner and a dated record, since those records are the first thing an assessor will request.

Where AI risk programs fall short and how to close each gap

Most AI risk programs fail the same way: they cannot say what AI they run, who decides what risk is acceptable, or whether the controls still match the system in production. The cards below cover six gaps an assessor is likely to probe in a HITRUST AI Risk Management Assessment, with the closing action and the evidence that shows it.

Incomplete AI inventory

An inventory that lists only the models the data science team built misses shadow AI: browser tools, embedded assistants in SaaS products, and features switched on by vendor updates. Close the gap by sweeping procurement records, expense claims, identity provider application lists and network egress logs, then assigning each system an owner and a use case. Evidence is a dated inventory with owners, reviewed on a set schedule, plus records showing vendor-provided AI features were captured.

Inconsistent risk criteria

When each team scores AI risk on its own scale, the same chatbot can be rated high by legal and low by product, and no one can compare results across the organization. Agree one set of impact and likelihood criteria, define the rating thresholds in writing, and require every AI system to be scored against them. Evidence is an approved risk methodology, scored risk registers in a common format, and minutes showing the criteria were applied and challenged.

Risk accepted without evidence

Sign-offs that read 'accepted by business owner' do not show what was known when the risk was taken. Require each acceptance to name the specific risk, the test results and compensating controls relied on, the approver's authority, and an expiry date. Evidence is a risk acceptance record linked to the test output it depends on, and a list of expired acceptances that were renewed or closed.

No pre-release LLM testing

Teams often check accuracy on a sample of prompts and stop there, leaving prompt injection, data leakage and jailbreak behavior untested. Add a documented adversarial test stage before release, covering the risks in the OWASP Top 10 for LLMs that apply to the system. The open-source probe tool garak can run hallucination, leakage, injection and jailbreak probes and writes a report of every attempt and a hit log of successful ones. Evidence is the test plan, the run reports and the sign-off tied to each release.

No reassessment after changes

A model swap, a new system prompt, a retrieval source or a tool integration can change behavior while the risk record still describes the old system. Define which changes trigger a new assessment, such as a new model version, altered prompts, new data sources or new tool permissions, and record them in change management. HITRUST recommends performing the assessment at least annually or when AI systems, processes or regulatory requirements change significantly. Evidence is a change log linked to risk reviews, with dated reassessments for each trigger.

Governance that exists only on paper

A policy that names an AI governance committee means little if the committee never meets, has no decision log, and no one can show it reviewed a system. Assign named roles for AI system owners, risk reviewers and an accountable executive, then hold and minute regular reviews. Check that operating practice matches the policy by sampling systems and tracing each one to its approval, testing and monitoring records. Evidence is meeting minutes, role assignments, and a sample trail from policy to system-level records.

Questions buyers ask about the AI risk management assessment

Is the HITRUST AI Risk Management Assessment a certification?

No. The HITRUST AI Risk Management Assessment is non-certified, so it does not produce a certificate. Its output is an AI Risk Management Insights Report with scorecards, maturity levels, gap analysis and prioritized recommendations. Buyers who need a certificate for a customer or contract should look at the AI security certifications instead. The report is still useful when a customer wants evidence that your AI risk practices have been reviewed against a structured set of controls, and it gives your team a prioritized list of what to fix first. Confirm with HITRUST exactly how the report can be shared, since sharing rules for Insights Reports are set by the program and not by your implementation partner.

How does the AI risk management assessment differ from the AI security assessment and certification?

The AI risk management assessment looks at how your organization governs and manages risk across its AI systems, using 51 curated controls mapped to the NIST AI RMF and ISO/IEC 23894:2023. The AI security assessment and certification focuses on deployed AI systems and their security requirements, and it issues certifications as ai1 or ai2 when combined with an e1, i1 or r2. In practice, the risk management assessment asks whether the program around AI is sound, while the security certification asks whether specific systems are secured. Many organizations start with risk management to define ownership, policies and a risk register, then pursue security certification for the systems in scope. Ask a prospective partner to explain how they would sequence the two.

How long does preparation take for this assessment?

No fixed duration is published here, so treat any timeline you receive as a estimate to test rather than a promise. Preparation time is driven mainly by how much AI governance already exists. An organization with a documented AI inventory, named owners, a risk methodology and recorded decisions will move faster than one that is still defining which systems count as AI. Other drivers include the number of AI systems in scope, how many business units build or buy AI, whether third-party models and vendors are involved, and how much evidence must be gathered from logs, tickets and approval records. Ask any partner to break the timeline into discovery, control mapping, evidence collection, gap work and report review, and to tie each phase to named deliverables.

What does the work need from our internal team?

The work needs time from people who own AI decisions, not only from security staff. Expect requests for an inventory of AI systems and their owners, documented data sources and model choices, risk assessments, change records, vendor due diligence, and evidence that reviews happen. Legal, privacy, product and data science teams usually contribute to governance questions, and an executive sponsor must accept the risk decisions the report surfaces. Name a single internal coordinator who can answer evidence requests quickly. Without that role, evidence collection tends to stall, because the assessment depends on documented practice rather than informal knowledge. Ask a partner which roles they expect to interview and how many hours of contributor time they assume.

Can our team run this assessment without an implementation partner?

Yes, an internal team can run the assessment itself if it has the skills, time and access to the evidence. Nothing in the program requires an outside firm for the assessment to be performed. The practical question is whether your team can map its current practices to the controls, identify gaps honestly, and produce evidence that holds up when reviewed. A partner can prepare systems, controls and evidence, and help with tooling and remediation, but the organization owns its controls and decisions. Be aware that partners do not issue the report. Decide what you want outside help for, such as tooling, evidence automation or remediation, and what your own staff will keep.

How often should we repeat the AI risk management assessment?

HITRUST recommends performing the assessment at least annually. Repeat it sooner when AI systems, processes or regulatory requirements change significantly. Examples of significant change include adopting a new model provider, deploying an AI system into a regulated decision, changing data sources, or a new regulation that affects how your AI is governed. Because the assessment is non-certified, there is no certificate that expires, so the schedule is a governance decision you set and document. Build the repeat cycle into your AI risk process so that the annual review uses the previous report as its baseline, and keep a record of which gaps were closed between cycles.

What should we ask a partner to include in a written scope?

A written scope should state the AI systems and business units in scope, the controls and framework mapping used, the deliverables, and the acceptance criteria. Ask the partner to list each deliverable, who receives it, and what evidence will be collected and from where. Require clear boundaries: which systems are excluded, which third-party AI services are only assessed through their documentation, and which items the organization must provide. Confirm roles in writing. The organization owns its controls, the partner prepares systems and evidence, and HITRUST issues the Insights Report through its own process. Also ask about remediation support, retesting, change handling, and how the fee is structured, since DeployOpen works from fixed, written scopes and provides a quote from that scope.

How DeployOpen prepares AI risk evidence for this assessment

DeployOpen plans, implements and documents the self-hosted open-source platforms that produce AI risk management evidence inside your own infrastructure. We prepare systems, controls and evidence for the HITRUST AI Risk Management Assessment, while your organization owns its controls and HITRUST Authorized External Assessors perform the assessment.

How we scope

Written scope agrees which AI systems, processes and business units the 51 curated controls cover.
We map your existing AI inventory, model owners and data flows against the assessment control set before work starts.
Engagements are fixed-scope, with deliverables and timelines confirmed in writing; ongoing support is available as a retainer.

How we build

We deploy and configure open-source tooling such as Langfuse for trace-level records of LLM calls, retrieval steps and tool executions.
We run garak probes against language models to produce JSONL attempt logs and hit logs for prompt injection and data leakage testing.
We integrate evidence collection into your environment so logs, approvals and review records are kept as the assessment expects.

How we hand over

We document each control's owner, procedure, evidence location and review cadence in a format your assessor can trace.
We deliver a gap analysis against the assessment's control set, with prioritized remediation items your teams can own.
Handover includes runbooks so your staff can rerun testing and refresh evidence when AI systems or regulatory requirements change.

How we support

Retainers cover upgrades, evidence refreshes and continuous testing ahead of each annual review of AI risk practices.
We help you prepare for the assessor's review of evidence, but the assessor and HITRUST issue the report, not DeployOpen.
Confirm with your assessor and HITRUST which evidence formats and sampling rules apply to your AI scope before implementation.