ISO/IEC 23894 vs NIST AI RMF: How the AI Risk Guidance Maps

Status and intended use

ISO/IEC 23894:2023 is titled "Information technology, Artificial intelligence, Guidance on risk management." Its abstract describes processes for the effective implementation and integration of AI risk management. It is guidance, and it builds on the ISO 31000 risk process, so teams that already run an ISO-style enterprise risk program will find its logic familiar.

The NIST AI RMF (AI RMF 1.0, NIST AI 100-1) is intended for voluntary use. Its stated purpose is to improve the ability to incorporate trustworthiness considerations into the design, development, use and evaluation of AI products, services and systems. The Core provides outcomes and actions that enable dialogue, understanding and activities to manage AI risks.

Because the AI RMF is voluntary and neither document should be treated as a pass/fail test, describe your position as alignment. Avoid wording that implies compliance or certification unless a separate, specific basis exists for it. As of November 2026, NIST states that AI RMF 1.0 is being revised, so the version you reference should be recorded explicitly.

Side-by-side comparison

The table summarizes the differences that matter most when you design a shared risk register and evidence model.

• Status: ISO/IEC 23894: published international standard guidance, dated 2023. NIST AI RMF: voluntary framework from NIST, with a revision in progress as of November 2026.
• Organizing structure: ISO/IEC 23894: a risk management process to implement and integrate. NIST AI RMF: four functions, with categories and subcategories beneath them.
• Style of expectation: ISO/IEC 23894: process description. NIST AI RMF: outcome statements, such as Govern 1.1 on legal and regulatory requirements being understood, managed and documented.
• Where governance sits: ISO/IEC 23894: integrated into the risk management process. NIST AI RMF: Govern is a distinct function covering policies, processes, procedures and practices across the organization.
• Companion material: ISO/IEC 23894: none assumed here. NIST AI RMF: the AI RMF Playbook for practices, and NIST AI 600-1, the Generative AI Profile released July 26, 2024.
• Terminology: Terms differ between the documents, so a recorded term-to-term mapping is needed to keep one internal vocabulary.

Where the mapping holds and where it does not

In general terms, the NIST Map function establishes context and identifies risk, Measure analyzes and assesses it, and Manage prioritizes and treats it. An ISO-style process moves through comparable steps: establishing context, assessing risk, treating risk, and monitoring and reviewing. This is the basis for most crosswalks, and it is a useful starting point.

It is not one-to-one. One industry comment on the draft framework proposed, as an option, that Map corresponds roughly to the communication and consultation and context-setting activities, Measure to risk assessment, and Manage to risk treatment. That was one commenter's view of a draft, not an official mapping, and the same comment raised terminology alignment as a concern. Treat it as an illustration of how approximate these mappings are.

The largest structural mismatch is Govern. In the AI RMF it is a function with its own outcomes, covering legal and regulatory requirements (Govern 1.1), integrating trustworthy AI characteristics into policies and processes (Govern 1.2), and determining the needed level of risk management activity from the organization's risk tolerance (Govern 1.3). In a process-oriented document, comparable expectations are spread through the framework and process rather than gathered in one function. Expect one-to-many and many-to-one links here, and expect some outcomes with no clean counterpart.

A revised ISO/IEC 23894 to AI RMF crosswalk, attributed to INCITS/AI and dated August 14, 2025, is listed on the NIST AI Resource Center. NIST's January 2023 crosswalk was written against the draft ISO standard and is marked superseded. NIST describes the listed crosswalks as community-submitted, notes that inclusion does not imply NIST endorsement, and says it does not imply either resource comprehensively covers the other.

Building a working crosswalk

A crosswalk is only useful if it is owned, versioned and tied to real activities. The steps below keep the effort bounded.

• Pin versions: Record ISO/IEC 23894:2023, AI RMF 1.0 or any later revision, and the date and author of the crosswalk relied on.
• Start from a published crosswalk: Use the revised INCITS/AI crosswalk as a starting point, then validate each row against your own program.
• Choose the primary structure: Organize the risk register around one framework and carry the other as a secondary reference column.
• Fix the vocabulary: Define one internal term per concept and note the corresponding term in each framework.
• Mark mapping confidence: Label each link as direct, partial or no counterpart, so reviewers know where judgment was applied.
• Add generative AI scope: If generative AI systems are in scope, consider NIST AI 600-1 alongside the AI RMF.

Choosing the primary organizing structure

Choose based on how your risk function already works. If your enterprise risk program follows ISO-style process language, using ISO/IEC 23894 as the backbone keeps AI risk consistent with existing registers, reviews and reporting. If your stakeholders, customers or regulators ask in NIST terms, or your teams want outcome-level statements to assign to owners, the AI RMF functions may be the more practical backbone.

Either choice works, provided the secondary framework is mapped rather than ignored. The common failure is maintaining two parallel registers with different language, which duplicates effort and produces inconsistent answers to the same question. Ask three things before locking the decision: which framework do assessors and customers cite most often, which one maps most naturally onto your existing risk taxonomy, and who validates the crosswalk when either document changes. Because NIST has a revision in progress, build the mapping so that rows can be updated without restructuring the register.

Process and oversight versus runtime enforcement and evidence

Some expectations in both frameworks are organizational by nature. Understanding and documenting legal and regulatory requirements (Govern 1.1) and deciding risk tolerance (Govern 1.3) need a documented process and an accountable owner. Technical enforcement can supply evidence that those decisions were implemented, but it cannot replace the decisions or the oversight behind them.

Other activities, mainly risk treatment and monitoring in ISO terms and much of Manage in NIST terms, can be enforced and evidenced at runtime. Trussed enforces policy in the execution path across models, agents, tools and MCP servers, at the level of individual interactions and tool calls. Interactions can be allowed, redacted, blocked, rate limited or escalated for human approval, and enforcement generates continuous audit-ready evidence mapped to frameworks including NIST. The policy is enforced at runtime, not reviewed after the fact, so the record shows what the AI was allowed to do and what it did.

That evidence supports specific treatment and monitoring rows in a crosswalk. It does not deliver certification or full framework compliance for either document, and it does not cover activities such as risk tolerance decisions or legal analysis. Map each runtime control to the exact framework activity it evidences, and mark the remaining rows as process-owned.