ISO/IEC 23894 AI Risk Management Checklist

An ISO/IEC 23894 checklist is useful when every checked box points to a dated risk decision and a person who can explain it. Start with one AI system. The six checks below take it through scope, identification, analysis, treatment, monitoring and review, with a pass condition and evidence for each step. ISO/IEC 23894:2023 is customizable guidance for managing AI risk. This is a working checklist an organization can adapt, rather than a certification test or a list of legal obligations.

TL;DR

Use these three conditions to decide whether a checked item has enough substance to review.

• Name the AI system, its owner, users, model route and data before rating any risk.
• For each material risk, retain the assessment, treatment decision, control test and residual-risk approval.
• Reopen a check after a model, data, provider or use-case change; a signed form from August cannot prove an October deployment still behaves the same way.

Scope and identify the risk

The first two checks establish the assessed system and the specific ways it could cause harm.

• Check 1: Inventory the system. Owner: the application owner. Pass when the record names the business purpose, user or agent population, model provider, data categories, connected tools and deployment boundary. Retain an approved system inventory and a dated data-flow diagram. A support summarizer that sends case notes to a hosted model needs its own system ID; a second route using interview transcripts needs a separate assessment. The AI risk register template shows how to carry that ID into each risk row.
• Check 2: Record credible failure modes. Owner: the risk lead with engineering and privacy input. Pass when the team has considered risks from the actual use case, including unauthorized disclosure, unreliable output, automation scope and affected people. Retain a workshop record or risk register entry with a scenario, affected party and cause. A prompt containing a customer address sent to an unapproved model is one scenario. An inaccurate case summary changing a benefits decision is another; request filtering alone cannot assess that outcome.

Analyze and choose treatment

The next pair turns an identified scenario into an approved, testable decision.

• Check 3: Rate the risk using stated criteria. Owner: the risk lead. Pass when likelihood, impact, existing safeguards and uncertainty are recorded against criteria agreed before the score was assigned. Retain the rubric version and the dated assessment. The same disclosure scenario can have a different impact when the payload contains public product text rather than a customer's case record. Do not let a single numeric score hide that distinction.
• Check 4: Approve a treatment and residual risk. Owner: the accountable business owner, with a technical control owner. Pass when the treatment names a control, scope, test method, due date and the person accepting any remaining risk. Retain the treatment record and approval. For the case-note example, an organization might restrict approved model routes and block a classified data field before an HTTP model call. That is an organizational control choice informed by the risk assessment, not a control prescribed by ISO/IEC 23894. The companion controls mapping makes the owner and test explicit.

Test, monitor and revisit

Evidence from operation closes the loop, provided someone also knows when to reopen it.

• Check 5: Prove the treatment operates. Owner: the control operator. Pass when a permitted case, a denied case and a changed-policy case produce the expected decision and a retrievable record. Retain the test fixture, policy version, timestamp, result and a redacted request identifier. For model quality or bias risks, use evaluation samples and human review records as well; a gateway log cannot prove output quality. The audit evidence package walks through a sample retrieval.
• Check 6: Set a review trigger. Owner: the system owner. Pass when a model version change, new data class, provider change, material incident or scheduled review opens a new assessment with a due date. Retain the change record, reassessment decision and closure evidence. A calendar reminder without a named owner or a link to the system ID is a weak trigger. Put the trigger beside the deployment change request so the reviewer sees it before the next release.

Use the guidance with clear boundaries

The NIST AI Risk Management Framework is another voluntary source for teams building a risk process. Its Govern, Map, Measure and Manage functions can help check whether an assessment has an owner, context, measurement and response. Use the framework's own language when creating a crosswalk; avoid presenting this checklist as a clause-by-clause interpretation of ISO text your team has not reviewed under licence.

I would hold a checklist marked complete if its treatment row lacks a failed-case test. A green status with no sample result tells an assessor what the team intended, while a test record shows what happened. The physical packet can be small: one system ID on the inventory page, the same ID on each risk row, and a dated approval beside the test result.

DeepInspect

DeepInspect can assess policy on HTTP AI requests routed through its gateway and record a decision with the caller context supplied by the integration, destination and policy state. Those records can support Check 5 for the routed request layer. System discovery, model evaluation, consent, vendor review and residual-risk acceptance still need their own owners and evidence.

Book a technical deep dive at deepinspect.ai.