NIST AI RMF vs ISO 42001: which one should you start with?
A practical comparison of NIST AI RMF and ISO/IEC 42001. What each is for, what they ask of you, where they overlap, and how to pick a starting point.
NIST AI RMF and ISO 42001 get set against each other as competing standards. They are not competitors. One is a risk management framework and the other is a management system standard. That category difference determines almost everything about how you would use them.
Here is the honest version, and a way to pick.
The category difference is the whole story
NIST AI RMF 1.0 is a voluntary framework published by a US federal agency. It describes four functions called Govern, Map, Measure and Manage, and organises trustworthiness characteristics under them. There is no certification, no auditor, no certificate at the end. You cannot pass it. You adopt it, and you tell people you adopted it.
ISO/IEC 42001:2023 is a certifiable management system standard. It follows the same shape as ISO 27001 and ISO 9001. Clauses 4 to 10 define the management system, and Annex A lists 38 controls you implement and justify. An accredited body audits you and issues a certificate that expires and needs surveillance audits to stay valid.
That difference cascades through everything else:
| NIST AI RMF | ISO/IEC 42001 | |
|---|---|---|
| Type | Voluntary risk framework | Certifiable management system standard |
| Structure | 4 functions, 19 categories | Clauses 4–10 plus 38 Annex A controls |
| Output | Internal risk practice | An audited certificate |
| Cost | Your time | Your time, plus certification body fees and surveillance |
| Buyer recognition | Growing, US-centric | Immediate, international, procurement-legible |
| Enforces anything? | No | Only through the certificate you would lose |
The practical consequence is blunt. NIST AI RMF costs nothing and proves nothing to a third party. ISO 42001 costs real money and proves something specific to a procurement team.
What NIST AI RMF asks of you
The framework is organised at the category level, which is the level at which it is usable. Nineteen categories in total.
Govern (6). Policies and procedures for AI risk, accountability structures, workforce diversity and accessibility, a culture of risk awareness, engagement with relevant AI actors, and third-party and supply-chain risk policies.
Map (5). Establish context, categorise the system, document capabilities and expected benefits and costs, understand risks and benefits of all components, and assess impacts to individuals, groups, communities and society.
Measure (4). Select appropriate methods and metrics, evaluate for trustworthy characteristics, track identified risks over time, and gather feedback about measurement efficacy.
Manage (4). Prioritise and respond to risks, maximise benefits and minimise negative impacts, manage third-party risks, and maintain treatment, response, recovery and communication plans.
The subcategories beneath these go much finer, but they map many-to-one onto the categories and are too granular to attest against per system. Category level is where a system owner can give a meaningful answer.
The real strength of the framework is Map. It forces you to write down what a system is for and who it can hurt. Work through Map and you may find you cannot enumerate your AI systems at all, which is worth the exercise on its own.
The real weakness is that nothing makes you do it. Nothing in it stops the documentation being written once, for a slide deck, and never opened again.
What ISO 42001 asks of you
Two halves. The first is larger than it looks.
Clauses 4 to 10 are the management system: context of the organisation, leadership commitment, planning, support, operation, performance evaluation and improvement. If you have been through ISO 27001, this is familiar machinery. Objectives, internal audits, management review, corrective actions, continual improvement. Most of the ongoing effort lives here, and none of it is AI-specific.
Annex A is 38 controls across nine clauses:
| Clause | Controls | Concern |
|---|---|---|
| A.2 Policies related to AI | 3 | The AI policy, its alignment with other policies, its review |
| A.3 Internal organisation | 2 | Roles and responsibilities, reporting concerns |
| A.4 Resources for AI systems | 5 | Data, tooling, compute and human resources, documented |
| A.5 Assessing impacts | 4 | Impact assessment process, documentation, effects on people and society |
| A.6 AI system life cycle | 9 | Responsible design, requirements, verification, deployment, operation, technical documentation, event logs |
| A.7 Data for AI systems | 5 | Acquisition, quality, provenance, preparation |
| A.8 Information for interested parties | 4 | System documentation, external reporting, incident communication |
| A.9 Use of AI systems | 3 | Processes and objectives for responsible use, intended use |
| A.10 Third-party relationships | 3 | Allocating responsibilities across suppliers and customers |
A.6 is the largest clause and the most demanding, because A.6.2.8 asks for event logs. Not a policy about logging. Actual records of what the system did. If you cannot produce a record of the model calls and decisions for a system, A.6.2.8 is a finding, and no amount of documentation closes it.
Overlap and differences
The overlap is substantial. NIST’s GOVERN 1 and 2 map onto ISO’s A.2 and A.3 almost directly. MAP 1–5 covers much of A.5 and A.6.2.2. MANAGE 3 and A.10 are both third-party risk. Do one properly and you have done a meaningful fraction of the other, which is why crosswalking matters more than choosing.
Three differences are real.
ISO requires a management system and NIST does not. Objectives, internal audit, management review, continual improvement. Most of the recurring cost lands here. It is also the machinery that keeps the programme running after the initial push, and a voluntary framework has no equivalent of it.
NIST goes deeper on measurement. MEASURE 1 through 4 asks for methods, metrics, tracking over time, and feedback on whether the measurement is working. ISO’s A.6.2.4 verification and validation is much thinner on how you would quantify fairness or robustness.
ISO is procurement-legible. A certificate answers a security questionnaire. “We follow NIST AI RMF” invites a follow-up question, and the follow-up is always “show me”.
So which do you start with?
The honest answer turns on one thing. Is anyone external asking?
Start with NIST AI RMF if nobody is demanding proof yet, you do not have an AI inventory, and you need internal practice before you can be audited on anything. It is free, it starts where you are, and Map will tell you how bad your inventory problem is. Six months of NIST AI RMF is good preparation for certification later.
Start with ISO 42001 if customers or procurement are already asking, you sell into enterprises or the public sector, or you already run ISO 27001 and can extend the machinery instead of building it. The marginal cost on top of an existing ISO management system is far lower than the first one cost.
If you are EU-exposed, neither is the priority. The EU AI Act is binding law with penalties attached, and most of it is already in force. Prohibitions applied from February 2025, GPAI obligations from August 2025, and transparency and Annex III high-risk requirements from August 2026. ISO 42001 is not a defence against any of it. Classify your systems against the Act first, then use ISO 42001 as the management system that operationalises the result. That sequencing works in practice: the Act tells you what you must do, and ISO gives you the machine that does it repeatedly.
The thing that makes either one survivable
Whichever you pick, the failure mode is identical. The framework ends up in a document set that drifts away from what your systems do, and the drift gets discovered during an audit.
The way out is to stop treating the framework as a document and start treating it as an attribute of each system. Each AI system carries its own control assessments, its own evidence and its own owner. Coverage rolls up from the systems instead of being asserted at the top. When a system changes, its assessments go stale visibly rather than quietly.
That structure also makes the frameworks compose instead of compete. An assessment recorded against ISO A.5.2 is evidence for NIST MAP 5 and for EU AI Act Article 9. Same underlying work, claimed once. Evidence each framework separately and you do the same work three times, then have to reconcile three answers to one question.
Pick the one that matches whoever is asking, then crosswalk the other onto the same assessments instead of running it as a second programme.
More resources
Human in the loop for AI agents: from a policy line to a proxy that holds the call
Why 'a human reviews high-risk actions' fails as a policy, and how to make it a condition the proxy checks against each tool call's arguments and holds.
ReferenceAI governance glossary: 40 terms worth getting right
Plain definitions for the terms that come up in AI governance work: regulation, risk assessment, agents and MCP, shadow AI, and the telemetry underneath it all.
FrameworksHow to classify a high-risk AI system under the EU AI Act
A step-by-step walkthrough of EU AI Act classification: role, prohibited practices, Annex III, the Article 6(3) derogations, and the obligations each triggers.