ISO/IEC 23894 to NIST AI RMF Mapping: AI Risk Process Crosswalk

What each framework contributes

ISO/IEC 23894:2023 is titled "Information technology, Artificial intelligence, Guidance on risk management." ISO describes it as covering the processes for effective implementation and integration of AI risk management. It follows the structure of the ISO 31000 risk process, which regulated enterprises with an existing risk function will already recognize.

The NIST AI RMF is voluntary and is organized around four functions: Govern, Map, Measure and Manage. It states outcomes by category and subcategory. Practices sit in the companion Playbook, and NIST also publishes profiles, including the Generative AI Profile (NIST AI 600-1, released July 26, 2024).

The frameworks answer different questions. ISO/IEC 23894 tells a risk team what sequence of activities to run and how to embed them in the organization. The AI RMF tells the same team which outcomes a trustworkthy AI risk program should be able to show. Treating them as complementary avoids running two programs. Neither is a set of prescriptive controls, so alignment depends on the organization's own decisions and the evidence it keeps.

Crosswalk by risk process step

The table maps each ISO/IEC 23894 process step to the AI RMF functions it most directly supports. It is a function-level starting point. Pull the clause numbers and subcategory identifiers from the published texts when you build the auditable version.

• Scope, context and criteria: Govern (policies, roles, risk tolerance) and Map (system purpose, setting, stakeholders). Risk criteria are set in Govern and applied in Map and Measure.
• Risk identification: Map. Identify risks in the context of each system's use, data, impacts and limits.
• Risk analysis and evaluation: Measure for analysis methods, metrics and testing. Evaluation against criteria draws on Govern, and decisions about acceptability feed Manage.
• Risk treatment: Manage. Prioritize risks, select responses, implement treatment plans and verify that they work.
• Monitoring and review: Measure and Manage for ongoing tracking and response, with Govern covering review of the program itself.
• Communication, consultation, recording and reporting: Govern across all functions, with Map covering stakeholder input. Records link each decision to its treatment and evidence.

Where the mapping stops being one-to-one

Three differences matter in practice. First, scope and emphasis. ISO/IEC 23894 is a process standard, so it is explicit about sequence and integration. The AI RMF is outcome-oriented and puts governance in its own function that applies across the others, while ISO places comparable activity in leadership, framework and integration guidance around the process. Second, terminology. "Risk treatment" in ISO and "Manage" in the AI RMF overlap heavily but are not identical, and "Measure" spans both analysis and testing activity that ISO would split between steps. Third, prescriptiveness. Neither framework mandates specific controls.

A stakeholder comment submitted to NIST in 2022 proposed mapping Manage to risk treatment, noting that both include implementing treatment plans and verifying their effectiveness. That is a reasonable reading but it is one stakeholder's suggestion, not NIST's mapping.

Crosswalk versions also matter. NIST's January 2023 crosswalk targeted the final draft of ISO/IEC 23894 and is now marked superseded. A revised crosswalk from INCITS/AI, dated August 14, 2025, is listed on NIST's AI RMF Center as a community submission. NIST states that listing does not imply endorsement or that either resource comprehensively covers the other. As of November 2026, NIST also states that AI RMF 1.0 is being updated, so any mapping should carry a version and date and be revisited when the revision is published.

Building one risk process that satisfies both

Start from the ISO/IEC 23894 process as the operating sequence, since it is what teams execute, and tag each step and its outputs with the AI RMF functions and categories it supports. This gives one risk register, one set of criteria and one treatment workflow, with a view for each framework rather than two parallel processes.

Three decisions are worth settling early. Set risk criteria once, in the governance layer, and reference them from assessment so that evaluation decisions are consistent. Define treatment options and the owner for each, so every accepted, mitigated, transferred or avoided risk leads to a named control. Define the monitoring cadence and what triggers re-assessment, such as a model change, a new tool or data source, or a new use case.

Record the mapping version, its date and its known limits alongside the process. Assign an owner to track changes to ISO/IEC AI standards and the AI RMF, including its in-progress update, and to re-validate the mapping when they change. If generative AI is in use, fold the relevant Generative AI Profile actions into the same process rather than keeping a separate list.

Treatment and monitoring that depend on runtime enforcement

Not every step in the crosswalk produces runtime behavior. Setting criteria, assigning roles and documenting context are organizational activities. Treatment is different. A decision to restrict what data a model may receive, which tools an agent may call, or when a person must approve an action is only a treatment if something enforces it while the system runs. A policy document that is reviewed after the fact does not verify that the treatment worked on any given interaction.

Monitoring has the same dependency. The Generative AI Profile includes action MS-2.7-009: regularly assess and verify that security measures remain effective and have not been compromised. Verification of that kind needs ongoing records, not a point-in-time review. The profile also calls for documenting the origin and history of training and generated data, which is a provenance and documentation task rather than a runtime control. A complete program covers both kinds of activity.

For audit readiness, each step should leave an artifact an auditor can trace from risk decision to control to outcome.

• Documented risk criteria and context for each AI system, with version and approval date
• Risk register entries showing identification, analysis and evaluation decisions
• Treatment plans linking each risk to a specific control, owner and acceptance decision
• Records of control operation: what was allowed, changed, blocked or escalated, and when
• Monitoring and effectiveness-verification results, with review dates and follow-up actions
• Communication and reporting records, plus the mapping version used

Enforcing treatment decisions in the execution path

Trussed addresses the runtime portion of this crosswalk. It enforces policy in the execution path across models, agents, tools, MCP servers, AI sites and coding assistants. Actions include allow, redact, block, rate limit and escalate for human approval, applied at the level of individual interactions and tool calls. Policy is enforced at runtime, not reviewed after the fact.

That enforcement produces continuous, audit-ready evidence, mapped to HIPAA, NAIC, NYDFS, the EU AI Act and NIST. In the crosswalk above, this supports the control-operation and verification records under treatment and monitoring. Trussed runs in production in regulated enterprises, with 100+ models under one policy plane and 30+ GB of audit evidence generated per day. It can be deployed self-managed in the customer cloud, with configurable retention and data residency.

It does not replace the risk process. Risk criteria, assessment, acceptance decisions and reporting remain with the risk function, and Trussed enforces the policies those decisions produce.