ISO/IEC 23894 vs ISO 31000: What Changes for AI Risk Management

The structural relationship

ISO 31000 provides principles, a framework and a process for managing risk. Its process covers identifying, analyzing, evaluating, treating, monitoring and communicating risks. ISO states that ISO 31000 served as a basis for the development of ISO/IEC 23894, whose published title is "Information technology — Artificial intelligence — Guidance on risk management". ISO describes the 23894 guidelines as helping organizations assess typical risks and threats to AI systems and integrate risk management for AI into their processes.

So the two documents are layered, not competing. ISO 31000 is the general method. ISO/IEC 23894 applies that method to AI. Neither is a certifiable standard. ISO describes ISO 31000 as good practice guidelines, and 23894 is guidance rather than a requirements specification. For a risk leader, the practical consequence is that an existing ISO 31000-based program is the starting point, not something to replace.

Side-by-side: what carries over and what to review

The table follows the ISO 31000 structure. Clause numbers come from NIST's crosswalk of the draft version of ISO/IEC 23894. Published numbering may differ, so use them as orientation only.

• Principles: ISO 31000 supplies the principles and 23894 builds on them. Keep your existing risk principles and vocabulary, and apply them to AI systems.
• Framework: integration, roles, resources, communication, improvement: The draft crosswalk marks integration (5.3), roles and accountabilities (5.4.3), resources (5.4.4), communication and consultation (5.4.5) and improvement (5.7) as referencing ISO 31000:2018. These are the strongest candidates for reuse, including your ERM ownership model.
• Process: identify, analyze, evaluate, treat: The same steps apply to AI systems. This is where AI-specific considerations enter your risk criteria, identification methods and treatment options.
• Monitoring and review: The draft crosswalk marks monitoring and review (6.6) as referencing ISO 31000. Treat it as a program-level process, fed by whatever evidence your controls produce.
• Certification: Neither ISO 31000 nor 23894 is certifiable. ISO/IEC 42001 is the requirements standard for an AI management system.

Where AI-specific guidance extends general risk management

The extension is mostly in application rather than in a new process. A general risk program usually reasons about processes, assets and people. AI systems add behavior that depends on models, data and the context of use. They also add outputs that vary between interactions, and tool or data access that an AI system exercises on a user's behalf. Risk identification therefore has to cover AI-related sources of risk. Risk criteria have to reflect the objectives of the AI system. Risk treatment has to be considered at more than one stage of the system's lifecycle.

The NIST AI RMF reflects the same conceptual lineage. It adapts ISO 31000:2018 language, noting that AI impacts can be positive, negative or both, resulting in opportunities or threats. It also quotes the ISO 31000:2018 definition of risk management. A shared vocabulary makes it feasible to run one risk language across ERM and AI risk work.

The implementation consequence is a mapping exercise. Take each step of your current process and ask what changes for an AI system: the risk sources you list, the criteria you evaluate against, the treatments available, and the lifecycle stage at which each applies.

How 23894 relates to ISO/IEC 42001 and the NIST AI RMF

ISO/IEC 42001:2023 specifies requirements for establishing, implementing, maintaining and continually improving an AI management system. ISO describes it as covering AI projects from risk assessment to treatment of risks, and describes 23894 as guidance on AI-related risk management. In short, 42001 is the management system you can build and certify against, and 23894 informs how the risk work inside it is done.

NIST maintains crosswalk documents between the AI RMF and ISO/IEC 23894. The earlier crosswalk against the draft is marked superseded, and a revised version dated August 2025 was submitted by INCITS/AI. Whichever crosswalk you use, record the version in your program documentation. Governance documents should also keep requirements and guidance distinct. A policy that cites 23894 as if it set certifiable requirements invites an audit question the standard cannot answer.

Which treatments can be enforced at runtime

The following classification is analysis, not something the standards prescribe. A risk treatment is runtime-enforceable when it can be applied to an individual interaction or tool call as it happens. Examples include allowing or blocking a request, redacting sensitive content, rate limiting, or escalating an action for human approval. The enforcement decision itself produces a record, which gives an auditor something to inspect beyond a policy document.

Other treatments are not runtime controls. Setting risk criteria, assigning accountabilities, allocating resources, deciding whether to deploy a system, accepting residual risk and improving the program are organizational or lifecycle activities. Their evidence is different: approvals, review records, decisions and updated documentation. Monitoring and review sits between the two. The program-level process is organizational, but it can be informed by evidence from runtime enforcement.

Misclassification is the common failure. A treatment documented as a policy but described as a control will not survive an audit request for evidence.

• Can the treatment be applied to a single interaction or tool call as it happens?
• If yes, does the enforcement decision produce a durable record an auditor can inspect?
• If no, which lifecycle or organizational process owns it, and what record does that process produce?
• Is the treatment currently enforced, or only documented as policy?
• Which claims about conformance or certification do you make, and what supports them?

Where runtime policy enforcement fits

Trussed enforces policy in the execution path across models, agents, tools, MCP servers, AI sites and coding assistants. It can allow, redact, block, rate limit, or escalate for human approval. The scope is individual interactions and tool calls. Enforcement is applied at runtime, not reviewed after the fact, and it generates continuous audit-ready evidence, mapped to frameworks including NIST. For an AI risk program, that can support the risk treatment, monitoring and recording activities that operate at the level of a single interaction or tool call.

The boundary matters. Runtime enforcement does not replace risk criteria, accountability, lifecycle decisions or program improvement. It does not make an organization conformant with ISO/IEC 23894, which is not a certifiable standard. It also does not cover model provenance or lineage, or tracing of agentic workflows end to end. Its role is to turn the runtime-enforceable portion of your treatments into enforced controls with inspectable evidence.