ISO/IEC 23894 vs ISO 31000: What AI Risk Management Adds to Enterprise Risk
ISO/IEC 23894 is AI-specific guidance on risk management. It extends ISO 31000 rather than replacing it. An organization with an ISO 31000-aligned program keeps its principles, framework and process, then extends context, assessment, treatment, monitoring and recording to cover AI systems. The extension only counts once treatment decisions are enforced and evidenced where AI executes.
Where an existing ISO 31000 program needs extending
- Is every AI system and AI-enabled workflow within the stated scope and context?
- Do risk evaluation criteria, thresholds and tolerances exist for AI use cases, with a named approver?
- Does assessment cover AI-specific risk sources and not only conventional IT risk?
- Does each treatment decision name the point in execution where it is applied?
- Is treatment effectiveness verified against actual interactions, not assumed from the policy?
- Can recording and reporting show a specific outcome for a specific interaction or tool call?
Evaluation criteria for runtime controls that support treatment
How the two standards relate
ISO describes ISO 31000 as providing principles, a framework and a process for managing risk. The 2018 edition is generic guidance. ISO also states that it is not a certifiable standard, although it provides guidance for internal or external audit programmes. ISO says using it can help organizations increase the likelihood of achieving objectives, improve identification of opportunities and threats, and allocate resources effectively for risk treatment.
ISO lists ISO/IEC 23894:2023 as guidance on risk management within information technology and artificial intelligence. Its abstract says it describes processes for the effective implementation and integration of AI risk management. The relationship is that of a general standard and a domain-specific guide. ISO 31000 supplies the structure, and ISO/IEC 23894 applies that structure to AI.
That has two practical consequences. First, an established ISO 31000-aligned program is the starting point, not something to rebuild. Second, because ISO 31000 is not certifiable, an organization should not describe its AI risk practice as certified on the strength of either document. The realistic assurance route is internal or external audit against the guidance, which makes the quality of recorded evidence the central question.
The shared process, side by side
The table follows the ISO 31000 process steps and notes where an AI program typically needs to extend each one. The right-hand column is a practical reading of what AI changes. It is not a clause-by-clause restatement of the standard.
- Context and scope: ISO 31000 establishes internal and external context. For AI, add the systems in scope, how they are used, who is affected and which interactions they have with data and tools.
- Communication and consultation: ISO 31000 engages stakeholders throughout. For AI, include the teams that build, deploy and use AI, plus the people affected by its outputs.
- Risk assessment: ISO 31000 covers identification, analysis and evaluation. For AI, identify risk sources specific to AI behavior, and set evaluation criteria for AI use cases.
- Risk treatment: ISO 31000 selects and implements options. For AI, each option needs an enforceable mechanism in the systems that execute AI, not only a policy statement.
- Monitoring and review: ISO 31000 monitors the process and the risks. For AI, monitor treatment effectiveness against actual interactions over time and across changes.
- Recording and reporting: ISO 31000 documents the process and its outcomes. For AI, records need to show what was applied to which interaction, in a form an auditor can examine.
What AI risk management adds
ISO 31000 is deliberately neutral about the nature of the risk. AI-specific guidance exists because AI systems change the inputs to each step in the process. Risk sources include model behavior, the data a system receives and returns, and the tools and actions a system can reach. Objectives for AI systems extend beyond availability and confidentiality to include the intended outcomes of the system's use. The risk picture also changes across the stages of an AI system's life, from design through operation, so assessment is not a one-time exercise.
Two framing points carry over from ISO 31000. Risk is not only negative. The NIST AI RMF, which adapts its wording from ISO 31000:2018, treats AI impacts as potentially positive, negative or both, resulting in opportunities or threats. A register that records only downside risk is narrower than that framing. Risk evaluation criteria also matter. Industry commenters on the NIST AI RMF argued for criteria that help set risk thresholds and clarify tolerance and appetite. For AI, someone needs to decide what level of risk is acceptable for each use case, and who approves it, before treatment can be designed.
Organizations that also use the NIST AI RMF will find that the two fit together. Industry commenters have mapped its Map function to context and consultation, Measure to risk assessment, and Manage to risk treatment. Community-submitted crosswalks between ISO/IEC 23894 and the AI RMF exist, including a revised version dated August 2025, but they are not official positions. Any evidence mapped to a crosswalk should name the version it uses.
Where treatment is enforced and evidenced
Both ISO 31000 and ISO/IEC 23894 treat risk treatment as more than choosing an option. According to industry commentary, they include a response function within implementing treatment plans, inclusive of verification of effectiveness. That is the point where a register entry has to become an operational control.
For AI, this usually means enforcement in the execution path. A treatment decision such as "personal data must not leave the organization in prompts" is only effective if something applies it to each request. Typical treatment actions map to a small set of runtime outcomes: allow the interaction, redact part of it, block it, rate limit it, or escalate it for human approval. The record of which action was applied, to which interaction or tool call, under which policy, is the evidence that supports recording and reporting and lets monitoring verify effectiveness.
Trussed enforces policy in the execution path across models, agents, tools, MCP servers, AI sites and coding assistants, using exactly these actions: allow, redact, block, rate limit, escalate for human approval. Enforcement generates continuous audit-ready evidence, mapped to HIPAA, NAIC, NYDFS, the EU AI Act and NIST. The scope is individual interactions and tool calls. It does not address model lineage, dataset provenance or end-to-end workflow tracing, which sit outside this treatment layer and need their own approach.
From shared risk process to AI execution
ISO 31000
Principles, framework and process for managing any risk.
ISO/IEC 23894
Guidance on implementing and integrating AI risk management.
Risk treatment
Decisions on how each AI risk is addressed.
Runtime enforcement
Allow, redact, block, rate limit or escalate on each interaction and tool call.
Recording and reporting
Evidence an auditor or regulator can examine.
Turn AI risk treatment into enforced policy and evidence
See how policy is enforced on individual interactions and tool calls, and how the evidence supports recording and reporting.
See How Evidence Is Produced