ISO 42001 vs NIST AI RMF, an implementation comparison

Every enterprise risk leader I speak to is being asked the same question by a board, a regulator or a customer: which AI governance framework are we using? The honest answer for most organisations is "both, eventually." ISO/IEC 42001 and the NIST AI Risk Management Framework (AI RMF) are the two reference points the market has settled on, and they are designed for different jobs. This piece sets out what each framework is actually asking you to build, where they diverge in practice, and how a GRC team can run them as one programme rather than two.

What each framework is, in one paragraph

ISO/IEC 42001:2023 is a certifiable management system standard for AI, modelled on the same Annex SL structure as ISO 27001 and ISO 9001. It tells you to build an AI Management System (AIMS) with a stated scope, leadership commitment, risk and impact assessments, documented controls (Annex A), measurement, internal audit and management review. It is process-shaped: an auditor can come in and check that the system exists and is operating.

NIST AI RMF 1.0 is a voluntary, outcome-oriented framework organised around four functions, Govern, Map, Measure and Manage, that an organisation applies to each AI system across its lifecycle. It is not certifiable. It is a structured way of thinking about AI risk, with a profile mechanism that lets you tailor it to a sector or use case. Where ISO 42001 asks "do you have a system?", NIST AI RMF asks "for this AI system, what risks have you identified, measured and treated?"

The structural difference that matters

ISO 42001 is organisation-level. NIST AI RMF is system-level. That single difference drives almost every implementation choice that follows. ISO 42001 wants a policy, an inventory, an owner, a risk methodology, a control set and an audit programme that cover all of your AI activity. NIST AI RMF wants you to walk a specific model or deployment through Map (context, intended use, stakeholders), Measure (analytic evaluation against trustworthiness characteristics), Manage (treatment, monitoring, incident response) and Govern (the wrapper that makes the other three repeatable).

In practice this means ISO 42001 is the shape of your programme and NIST AI RMF is the shape of the work you do on each AI system inside it. Treating them as alternatives leads to duplication and confusion. Treating them as layers gives you a programme that is both certifiable and operationally rigorous.

Scope, applicability and what triggers them

ISO 42001 applies once you decide to stand up a management system, typically because a customer, a regulator or your own board wants third-party assurance that AI risk is being managed coherently. It is the right answer when you are selling AI features into regulated enterprises, when the EU AI Act puts you in the high-risk provider or deployer category, or when you already run an ISO 27001 programme and want to extend the same operating model.

NIST AI RMF applies the moment you have an AI system worth governing. There is no certification trigger. US federal contractors, anyone aligning with the NIST Cybersecurity Framework, and any organisation looking for a defensible, public method for assessing a model will land here. The two frameworks are explicitly cross-walked by ISO and NIST, so adopting one does not preclude the other.

Controls, functions and where the work actually lands

ISO 42001 Annex A gives you a control set across 9 control objectives covering policies, internal organisation, resources, impact assessment, AI system lifecycle, data, information for interested parties, use of AI systems and third-party relationships. The control set is closer to ISO 27001's Annex A in feel than to a prescriptive technical standard. You implement, document and test.

NIST AI RMF gives you categories and sub-categories inside Govern, Map, Measure and Manage. Govern.1 expects documented policies and roles. Map.1 expects context to be established. Measure.2 expects analytic evaluation against the trustworthiness characteristics (valid and reliable, safe, secure and resilient, accountable and transparent, explainable and interpretable, privacy-enhanced, fair with harmful bias managed). Manage.1 expects risks to be prioritised, treated and monitored. The work product is an AI system profile that any reviewer can read end-to-end.

The overlap is large and intentional. ISO 42001's impact assessment maps onto NIST AI RMF Map. ISO 42001's measurement and operational controls map onto NIST AI RMF Measure and Manage. ISO 42001's leadership, policy and audit clauses map onto NIST AI RMF Govern. If you write your AI system profile once, in a format that satisfies NIST's Map / Measure / Manage prompts, you have already produced the artefact ISO 42001 expects to see in a per-system risk and impact assessment.

Risk methodology: where the two frameworks part company

ISO 42001 inherits ISO 31000's posture: you define a risk methodology, you apply it consistently, you record decisions. It does not tell you what taxonomy to use. NIST AI RMF is more opinionated. It introduces trustworthiness characteristics as first-class risk dimensions and expects you to measure against them. For a GRC team this is the most useful piece of NIST to pull into an ISO programme: it gives you a defensible default taxonomy when your ISO methodology would otherwise be silent on what "AI risk" actually contains.

The other quiet divergence is on harm. NIST AI RMF is explicit that AI risk includes harm to individuals, groups, organisations, ecosystems and society. ISO 42001 gestures at this through its impact assessment clause but leaves the breadth to the implementer. If you are operating in the EU AI Act perimeter or any consumer-facing context, importing NIST's harm framing into your ISO impact assessment template is the cheapest single upgrade you can make.

Evidence, audit and what an assessor actually reads

An ISO 42001 certification audit looks like every other ISO management system audit: scope statement, policy, leadership minutes, AI inventory, risk and impact assessments, operational records, internal audit reports, management review, non-conformity log, evidence of continual improvement. The assessor walks the clauses and Annex A controls. The evidence is largely managerial.

A NIST AI RMF review, internal or customer-driven, looks at a specific system: documented context, intended use, data lineage, model cards or equivalent, evaluation results, monitoring telemetry, incident history, decommissioning plan. The evidence is largely technical. The two evidence sets share a backbone (policy, roles, inventory, change control) and diverge at the leaves. A sensible evidence architecture stores the shared backbone once and tags artefacts so they can be presented in either shape.

Running both as one programme

The operating pattern I recommend is straightforward:

• Adopt ISO/IEC 42001 as the management system. It gives you scope, leadership commitment, an audit cadence and a certifiable wrapper customers and regulators recognise.
• Adopt NIST AI RMF as the per-system methodology inside that wrapper. Every AI system in the inventory gets a profile structured around Map, Measure, Manage, with Govern handled at the programme level.
• Write one impact assessment template that satisfies both: ISO 42001 Clause 6.1.4 fields on top, NIST trustworthiness characteristics and harm framing underneath. SMEs complete one document, not two.
• Pick one risk taxonomy. Use NIST's trustworthiness characteristics as the default. Map it explicitly to your enterprise risk taxonomy so AI risk rolls up into the same register the board already reads.
• Cross-walk the control set. ISO 42001 Annex A on the left column, NIST AI RMF sub-categories on the right, evidence in the middle. Maintain it as a single artefact.
• Align the audit cadence. ISO internal audits are annual or more frequent; NIST profile reviews should fire on material change to the system (new data, retrain, new use case) and at least annually. Same evidence, two triggers.
• Track EU AI Act alignment alongside both. The EU AI Act is the regulation; ISO 42001 and NIST AI RMF are the operational toolkits that get you there.

Where each framework falls short, honestly

ISO 42001 will not, on its own, make your engineers think harder about model behaviour. It is a management system. Run it in isolation and you get tidy documentation and a certificate; you do not necessarily get safer models. NIST AI RMF will not, on its own, give you a programme. It is a methodology. Run it in isolation and you get strong per-system profiles and no audit trail of leadership oversight or continual improvement. The combination addresses both gaps. Neither framework, used alone or together, replaces the substantive obligations of the EU AI Act, sector regulation (DORA, MiFID, HIPAA), or contractual commitments. They are the connective tissue, not the spine.

What to do on Monday morning

• Decide whether you need certification in the next 12 to 18 months. If yes, ISO 42001 is the wrapper. If no, start with NIST AI RMF on your three most material AI systems and revisit certification when the customer or regulator pressure arrives.
• Build the AI inventory. Both frameworks fail the moment you cannot list your AI systems with owner, purpose, data inputs and risk classification. This is the first artefact, not the last.
• Pick one AI system and walk it through NIST Map, Measure and Manage end-to-end. The output is your template. Do not write the template in the abstract.
• Cross-walk ISO 42001 Annex A to your existing ISO 27001 controls and to NIST AI RMF sub-categories. Most teams discover 60 to 70 per cent of the control work is already happening under another framework.
• Put the cross-walk, the inventory and the impact assessment template into the same GRC tooling your other frameworks live in. AI governance that lives in a separate spreadsheet does not survive contact with audit.

Closing

ISO 42001 and NIST AI RMF are not competing standards and the choice is rarely either/or. They are complementary tools that address different layers of the same problem: how do you demonstrate, to yourself and to others, that the AI you are building or buying is governed deliberately. Pick the wrapper, pick the methodology, write one set of artefacts that satisfies both, and the programme stops being a framework debate and starts being engineering.