ISO/IEC 23894 AI risk assessment template: how to identify, analyze, and evaluate AI risks

What the template has to do

ISO/IEC 23894:2023 gives guidance on how organizations that develop, produce, deploy or use AI products, systems and services can manage AI-specific risk, and how to integrate risk management into AI-related activities and functions. It is guidance. It is not a certification scheme, so the template is an internal instrument that shows how your organization applied the guidance, not a document submitted for certification.

The practical value of a template is consistency. Without fixed fields and agreed scales, two teams assessing similar systems produce assessments that cannot be compared or aggregated. The template should therefore mirror the process stages: context and criteria, identification (including risk sources), analysis with separate consequence and likelihood assessments, evaluation, treatment selection, treatment plans, and monitoring and review.

The analysis fields have a natural basis in the NIST AI RMF definition of risk, which is the composite of an event's probability of occurring and the magnitude of its consequences. If you add NIST AI RMF cross-references to template rows, use the revised ISO/IEC 23894 to NIST AI RMF crosswalk dated August 14, 2025, which supersedes the earlier draft-era crosswalk. Check clause numbers against your copy of the published standard. NIST has also said AI RMF 1.0 is being updated, and ISO/IEC DTS 25568 on generative AI risks was still under development as of November 2026, so keep cross-reference and generative AI fields easy to revise.

Define risk criteria and ownership before populating the register

Criteria come first because every later rating depends on them. A register filled in before the scales are approved has to be re-rated afterward. The criteria section should record the risk categories in use, the scale for consequence and likelihood, the combined rating levels, and the maximum risk the organization will tolerate before a deployment decision is escalated.

The NIST AI RMF Playbook offers a usable starting point. It suggests categorizing sources of risk (financial, operational, safety and wellbeing, business, reputational, and model), rating levels of risk from negligible to high, and documenting a maximum allowable risk tolerance with go/no-go deployment thresholds. The AI RMF itself does not prescribe risk tolerance. That is an organizational decision and may be constrained by legal or regulatory requirements, so record who approved the criteria, at what level, and when.

Scoring scales are yours to define, and anchored descriptions matter more than the number of points. For unintended data disclosure, consequence levels can be tied to the classification of the data and the affected population. For unsafe tool use, they can be tied to whether an action is reversible and which systems it touches. For unreliable outputs, they can be tied to whether a person reviews the output before it is acted on. Anchors like these let different assessors reach the same rating.

Every risk needs a named individual owner and a responsible response team. A team name alone does not tell anyone who accepts the residual risk.

Worked entries for common AI risks

The entries below are illustrative. Ratings depend entirely on your approved scales.

Unintended data disclosure: the risk source is user prompts or retrieved content containing regulated personal data that is sent to a model or returned to a user. The consequence is exposure of protected data, rated against your data classification anchors. Existing controls might include an access policy and user guidance. The evaluation compares the combined rating with the threshold. If it exceeds it, the treatment is to mitigate by detecting and redacting the data in each interaction, with a named owner and a residual rating after the control is assumed to work.

Unsafe tool use: the source is an agent allowed to call tools with write access. The consequence depends on reversibility and the systems affected. Treatment might be to restrict which tools can be called, rate limit calls, and require human approval for high-impact actions. Residual risk should be re-rated after those controls exist, not before.

Unreliable outputs: the source is a model producing incorrect content that feeds a decision. Here the treatment may combine mitigation, such as mandatory human review, with an explicit accept decision for lower-impact uses. The accepted portion needs a rationale and an approver, because acceptance is a decision that must be recorded, not a default state.

Connecting treatment decisions to enforceable controls

The NIST Playbook lists risk response options as mitigate, transfer, avoid, or accept, and says responses to high-priority risks should be developed, planned and documented with responsible teams identified. That vocabulary works well as a template field. Pair it with the rationale and trade-offs for each decision, since reviewers will later ask why a treatment was chosen.

Not every option produces runtime evidence. For accept and transfer, the evidence is a documented decision, an owner, and an approval date. For avoid, it is the decision not to deploy or to remove a capability. Mitigation is where the gap between assessment and operation tends to open: a control described in the register may exist only as policy text, or may behave differently in production than it did at design time.

Risks at the level of individual interactions and tool calls can close that gap when the treatment is enforced as policy in the execution path rather than reviewed after the fact. The relevant actions are allow, redact, block, rate limit, and escalate for human approval. Trussed enforces policy in the execution path across models, agents, tools, and MCP servers, and the enforcement itself generates audit-ready evidence, mapped to frameworks including NIST. In template terms, the evidence-expected field for such a row points to enforcement records for the review period. The scope is individual interactions and tool calls, so risks that sit outside that scope still need their own controls and evidence types.