NIST AI RMF vs ISO/IEC 42001: Which AI Framework to Adopt and How They Map

AI governance leads are regularly asked to pick between the NIST AI Risk Management Framework and ISO/IEC 42001, when the two were built to do different jobs and work best together. The NIST AI RMF (NIST AI 100-1) is a voluntary framework of outcomes for managing AI risk across the lifecycle. ISO/IEC 42001:2023 is an international standard that specifies requirements for an AI management system (AIMS) and can be independently certified. This guide compares their structure, scope, evidence and cost, shows how the AI RMF functions map to 42001 clauses, and gives decision guidance for organisations of different sizes and markets. It is for AI governance, GRC and security leads building or reviewing an AI programme. Status was checked on 13 November 2026: NIST states the AI RMF 1.0, released on 26 January 2023, is being revised as part of the White House AI Action Plan, and ISO/IEC 42001 remains edition 1.0, published 18 December 2023.

Key takeaways

• Short answer: use the AI RMF to decide what good AI risk management looks like, and ISO/IEC 42001 to run it as an auditable system. Organisations that need a certificate for customers or regulators choose 42001; most benefit from using the AI RMF and its profiles inside it.
• One is outcomes, the other is requirements. The AI RMF describes outcomes in four functions (GOVERN, MAP, MEASURE, MANAGE) and is explicitly not a checklist; 42001 uses "shall" requirements in clauses 4 to 10 plus normative Annex A controls.
• Only 42001 can be certified. Certification bodies audit against it, and ISO/IEC 42006:2025 sets requirements for those bodies. There is no AI RMF certification from NIST.
• They map well but not perfectly. A crosswalk on NIST's AI Resource Center maps AI RMF subcategories to 42001 clauses and Annex B guidance, with weaker coverage for inventory, decommissioning and environmental impact.
• Neither secures the AI system on its own. Both require risk assessment and treatment, but technical controls for prompt injection, model access and agent identities come from security frameworks you add.

What each one is

NIST AI RMF 1.0

Published by NIST as AI 100-1, the AI RMF is intended for voluntary use to build trustworthiness into the design, development, use and evaluation of AI systems. Its Core has four functions. GOVERN is cross-cutting and is meant to inform and be infused throughout the other three. MAP establishes context, intended purpose and impacts and informs a go or no-go decision. MEASURE analyses, benchmarks and monitors risk, including testing, evaluation, verification and validation (TEVV). MANAGE allocates resources to mapped and measured risks, including incident response and communication. The Core lists 6 GOVERN, 5 MAP, 4 MEASURE and 4 MANAGE categories. The framework names seven characteristics of trustworthy AI: valid and reliable; safe; secure and resilient; accountable and transparent; explainable and interpretable; privacy-enhanced; and fair with harmful bias managed. Companion resources include the Playbook, crosswalks, the Generative AI Profile (NIST AI 600-1, released 26 July 2024) and a concept note for a critical infrastructure profile (7 April 2026). See the NIST AI RMF Guide.

ISO/IEC 42001:2023

ISO/IEC 42001 specifies requirements and guidance for establishing, implementing, maintaining and continually improving an AI management system. It applies to any organisation, of any size or type, that provides or uses AI-based products or services. It follows the same high-level clause structure as ISO/IEC 27001: context (4), leadership (5), planning (6, including 6.1.2 AI risk assessment, 6.1.3 AI risk treatment and 6.1.4 AI system impact assessment), support (7), operation (8), performance evaluation (9, including internal audit and management review) and improvement (10). Annex A (normative) lists reference control objectives and controls, Annex B (normative) gives implementation guidance, Annex C lists potential AI-related objectives and risk sources, and Annex D covers use across domains and sectors. See the ISO/IEC 42001 Guide.

Side-by-side comparison

How they map

NIST's AI Resource Center lists a crosswalk from the AI RMF to ISO/IEC 42001 (provider shown as Microsoft, a third party; NIST notes inclusion does not imply endorsement). It maps each AI RMF subcategory to 42001 clauses and Annex B guidance, many-to-many. It was written against the FDIS draft of 42001, so check clause numbers against the published edition. Examples from that crosswalk:

The pattern behind the table is consistent. GOVERN outcomes land mostly in leadership, support and the policy and organisation guidance (clauses 5 and 7, B.2 and B.3). MAP outcomes land in impact and risk assessment (6.1.4, 8.2 to 8.4 and B.5). MEASURE and MANAGE outcomes land in operation, monitoring and improvement (8, 9, 10 and the B.6 lifecycle guidance). A second crosswalk listed by NIST, from INCITS/AI dated 14 August 2025, maps ISO/IEC 23894 to the AI RMF and is useful if you use 23894 as your risk process under 42001 clause 6. In practice, one well-built risk register, one impact assessment method and one monitoring plan can serve both frameworks, provided each entry carries both the AI RMF subcategory and the 42001 clause it evidences.

Where the mapping is thin, plan extra work:

• AI system inventory (GOVERN 1.6): maps only to resource clauses. 42001 does not name an inventory clause, so define one as part of scope (4.3) and resources.
• Decommissioning (GOVERN 1.7, MANAGE 2.4): rely on general operation and monitoring guidance; add explicit retirement and override procedures.
• Third-party intellectual property (GOVERN 6.1): supplier controls do not address IP directly.
• Environmental impact (MEASURE 2.12): covered only through societal impact and resources.
• Risk tolerance (MAP 1.5): maps only to 6.1.1; set criteria explicitly in your AI risk assessment method.

Which to adopt: decision guidance

• Choose ISO/IEC 42001 first when customers, procurement teams or regulators ask for certified assurance, when you already run an ISO/IEC 27001 ISMS and can extend it, or when you sell AI products internationally. See the ISO 42001 Readiness Checklist.
• Choose the NIST AI RMF first when you need to start quickly without certification, when US public sector or US-centred customers reference it, or when your main gap is risk thinking for generative AI, where NIST AI 600-1 gives concrete actions.
• Use both in most mid-size and large organisations: 42001 as the management system and audit spine, the AI RMF functions and profiles as the method for identifying and measuring risk inside clauses 6 and 8.
• Small organisations: start with an AI RMF-based policy, inventory and risk register; move to 42001 when a customer or contract requires a certificate.
• Regulated EU providers: neither framework is the law. Map obligations under the EU AI Act separately; see EU AI Act for AI Agents.

How to run them together: a phased approach

1. Scope and inventory (months 0 to 2): define the AIMS scope under clause 4.3 and build an inventory of AI systems, models, agents and suppliers (GOVERN 1.6). Record owner, purpose, data and the identities each system uses.
2. Policy and roles: write the AI policy (5.2) and assign roles (5.3), mirroring GOVERN 2 accountability outcomes.
3. Risk and impact method: adopt MAP and MEASURE outcomes as your AI risk assessment method for 6.1.2 and 8.2, and use ISO/IEC 42005 for impact assessment (6.1.4, 8.4). Select Annex A controls and record justifications in a statement of applicability.
4. Pilot on two or three systems: one generative AI use case, one agent with tool access and one classic model. Run the full cycle, including TEVV, and fix the method before scaling.
5. Operate and measure: set objectives (6.2), monitoring (9.1) and MANAGE treatment plans. Run an internal audit (9.2) and a management review (9.3).
6. Certify if needed: choose an accredited certification body (see ISO/IEC 42006), then stage 1 and stage 2 audits. If the audit finds major nonconformities, treat them under 10.2 rather than narrowing scope to pass.

Where identity fits

Both frameworks expect you to know what AI systems you have and who or what can act through them, yet neither names identity controls directly. AI agents, model endpoints and pipelines run as service accounts, API keys, OAuth clients and workload identities. Put those non-human identities in the AI inventory, tie each to an accountable owner (GOVERN 2, clause 5.3), include credential misuse and excessive agent permissions as AI risk sources in 6.1.2, and test them under MEASURE. Map technical access controls to ISO/IEC 27001 or NIST SP 800-53 (AC-6 Least Privilege) where they already live. See the Agentic AI Identity Guide and the Agentic AI Risk Assessment Template.

Worked scenarios

NIST AI RMF scenario: a US health technology company without a certification driver. The company uses AI RMF as its working method. GOVERN assigns an accountable owner for each AI system and a risk tolerance statement approved by the executive team. For a new triage assistant, MAP records intended purpose, users and foreseeable misuse, and ends with an explicit go or no-go decision before build. MEASURE sets test, evaluation, verification and validation (TEVV) criteria for accuracy across patient groups and for prompt injection resistance, using the Generative AI Profile (NIST AI 600-1) for the generative parts. MANAGE sets the response if monitoring shows drift. Nothing is certified, but the evidence is structured enough to answer a hospital customer's due diligence questions.

ISO/IEC 42001 scenario: a European software supplier asked for certification. A supplier whose enterprise customers now ask for an audited AI management system already holds ISO/IEC 27001. It extends the existing management system rather than building a second one: scope and context under clause 4, an AI policy under clause 5, AI risk assessment, risk treatment and AI system impact assessment under 6.1.2 to 6.1.4, a Statement of Applicability against Annex A controls, then internal audit and management review under clause 9. It uses the AI RMF Playbook and NIST's crosswalk as practical input for the risk assessment method, so the two frameworks support each other rather than compete.

Detection and measurement

Measure the programme, not just the paperwork. Pull evidence from the AI inventory, the risk register, TEVV results, incident records and the identity platform.

• Inventory coverage: percentage of AI systems and agents in scope with owner, purpose, risk rating and identity record.
• Assessment currency: percentage of in-scope systems with a risk and impact assessment reviewed in the last 12 months or since the last material change.
• Treatment closure: median days to close high AI risk treatment actions and corrective actions under 10.2.
• TEVV before release: share of releases with documented evaluation against the trustworthiness characteristics relevant to that system.
• Incident learning: AI incidents with a completed review feeding back into MAP and the risk register.
• Audit findings trend: internal audit nonconformities by clause over successive cycles.

Common failure patterns

• Treating the choice as either-or: teams debate frameworks for months instead of using the AI RMF as the method and 42001 as the system.
• Certificate scope too narrow: a 42001 certificate covering one product or team is presented as covering all AI use. Read the scope statement.
• AI RMF as a one-off profile: a current and target profile is written once and never measured again, losing the iterative cycle the framework calls for.
• Relying on an unchecked crosswalk: the published crosswalk was built against the FDIS draft and contains acknowledged inconsistencies; validate it before auditors see it.
• No technical depth: governance documents exist, but agent permissions, model access keys and prompt injection controls are untested. Pair both frameworks with security controls such as the OWASP LLM Top 10 LLM01 Prompt Injection Guide.
• Two parallel programmes: separate NIST and ISO workstreams keep separate registers and assessments, doubling effort and drifting apart; tag one set of records to both.
• Ignoring the revision: NIST has stated the AI RMF is being revised; programmes hard-coded to subcategory numbers will need rework.

Framework mapping

Practitioner checklist

• Decide whether anyone needs a certificate; that answer usually sets the lead framework.
• Build one AI inventory that serves GOVERN 1.6 and the 42001 scope, including agent identities.
• Write a single AI policy and role model that satisfies GOVERN 2 and clauses 5.2 and 5.3.
• Use MAP and MEASURE as the method behind 42001 risk and impact assessment.
• Apply NIST AI 600-1 actions to generative AI and agent use cases.
• Validate any crosswalk against the published 42001 text before relying on it.
• Record Annex A control decisions and justifications in a statement of applicability.
• Run internal audit and management review on a fixed annual cycle.
• Track the AI RMF revision and plan a mapping refresh when it is published.

Standards and references

• NIST: AI Risk Management Framework
• NIST AI Resource Center: AI RMF Core
• NIST AI Resource Center: AI RMF Crosswalks
• NIST AI Resource Center: NIST AI RMF to ISO/IEC 42001 Crosswalk
• IEC: ISO/IEC 42001:2023 Artificial intelligence, Management system
• VDE Verlag: ISO/IEC 42001:2023 preview, table of contents and scope

Related NHI Mgmt Group resources: AI Governance Guide · NIST AI 600-1 Generative AI Profile Guide · ISO/IEC 42005 AI System Impact Assessment Guide · ISO/IEC 23894 AI Risk Management Guide