ISO 42001 and the NIST AI Risk Management Framework
10 min read · updated August 4, 2026
ISO/IEC 42001 is a certifiable management system standard: you build a system, an accredited body audits it, you get a certificate. The NIST AI Risk Management Framework is voluntary guidance with no certification at all. They are frequently mentioned together and they are not alternatives.
The difference in one paragraph
| Attribute | Description |
|---|---|
| ISO/IEC 42001:2023 | An AI management system standard. Published December 2023. Certifiable by accredited third parties. Structured like ISO 27001 — clauses 4 to 10 are the management system, Annex A holds the controls. Answers 'do you run this properly?' |
| NIST AI RMF 1.0 | A voluntary framework published by the US National Institute of Standards and Technology in January 2023. Four functions, with categories and subcategories, plus a companion Playbook. Not certifiable — there is no such thing as NIST AI RMF certified. Answers 'have you thought about the right things?' |
The practical consequence: ISO 42001 is what you do when a customer or a procurement process demands proof. NIST AI RMF is what you do when you want a structure for the thinking and do not need a certificate. A great many organisations use the NIST functions to organise their work and then certify to ISO 42001 to prove it, which is a coherent sequence.
ISO/IEC 42001: what the standard requires
If you have seen ISO 27001, the shape is familiar because it uses the same harmonised structure. Clauses 4 to 10 are the management system and they are what an auditor tests:
- Context (4). Identify internal and external issues, interested parties and their requirements, and define the scope of the management system. Scope is the decision that determines what the certificate covers, and a narrow scope is a common and legitimate choice.
- Leadership (5). Top management commitment, an AI policy, and assigned roles and responsibilities.
- Planning (6). AI risk assessment and treatment, an AI system impact assessment, and objectives. This is where the standard is distinctive: impact on individuals and society is a required consideration, not only risk to the organisation.
- Support (7). Resources, competence, awareness, communication and documented information.
- Operation (8). Operational planning and control, plus carrying out the risk treatment and the impact assessments.
- Performance evaluation (9). Monitoring, measurement, internal audit and management review.
- Improvement (10). Nonconformity, corrective action and continual improvement.
Annex A holds the controls — roughly forty of them, grouped by objective — covering AI policy, internal organisation, the resources for AI systems, impact assessment, the AI system lifecycle, data for AI systems, information for interested parties, use of AI systems, and third-party relationships. Annex B gives implementation guidance for each. Annex C lists organisational objectives and risk sources. Annex D covers use of the standard across domains and sectors.
The two clauses that consume the most effort in practice are the lifecycle controls in Annex A, which require documented processes for objectives, design, verification, deployment, operation and monitoring of each AI system, and the data controls, which require you to know where your data came from and what it may be used for. Provenance is the item most organisations cannot evidence when they start.
What certification actually involves
- Define the scope. Which AI systems, which sites, which parts of the organisation. This appears on the certificate and it is what a customer will read.
- Gap assessment. Against the clauses and the Annex A controls. Usually reveals that the management system exists in fragments and is not documented as one.
- Build and operate. Policies, risk assessment methodology, impact assessment methodology, lifecycle process, inventory, records. The management system has to have been running long enough to produce evidence — you cannot certify a system that has not operated.
- Internal audit and management review. Both are required by the standard and both are checked. Missing management review minutes is a common finding.
- Stage 1 audit. The certification body reviews documentation and readiness. Findings here are cheap to fix.
- Stage 2 audit. The certification body tests whether the system is implemented and effective, by sampling evidence and interviewing people. Nonconformities are classified; major ones must be closed before certification.
- Certificate and surveillance. Certificates run for three years with surveillance audits in the intervening years and a recertification audit at the end.
Two things worth knowing before committing. Check that the certification body is accredited for 42001 specifically by a recognised accreditation body — unaccredited certificates exist and are worth what they cost. And the effort is dominated by evidence, not by documents: an auditor asks to see the impact assessment for a named system and the record of the decision it fed, not the template.
NIST AI RMF: four functions
| Function | Description |
|---|---|
| GOVERN | A culture of risk management: policies, accountability structures, workforce diversity and competence, third-party risk. Cross-cutting — it applies to all the other three rather than sitting in sequence with them. |
| MAP | Establish the context and identify risks. What the system is for, who it affects, what the assumptions are, what could go wrong and for whom. The framework's most useful contribution is insisting this happens before measurement. |
| MEASURE | Analyse, assess, benchmark and monitor. Includes choosing metrics, evaluating trustworthiness characteristics, and — pointedly — tracking the risks you identified but cannot measure. |
| MANAGE | Allocate resources to the mapped and measured risks: treat, monitor, respond, recover and communicate. |
The framework also 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. The companion Playbook gives suggested actions per subcategory, and it is the part practitioners actually use; the framework document itself is short.
What NIST AI RMF is good at is the MAP function — forcing an articulation of context, affected parties and assumptions before anyone picks a metric. What it does not do is tell you whether you have done enough. There is no threshold, no pass mark, and no external verification.
The generative AI profile
NIST published a Generative AI Profile, numbered AI 600-1, in July 2024. It is a companion rather than a replacement: it identifies risks unique to or exacerbated by generative AI — among them confabulation, dangerous or violent content, data privacy leakage, harmful bias, information integrity, information security including prompt injection, intellectual property, obscene content, and value-chain and component integration risks — and maps suggested actions to the four functions.
Its practical value is as a checklist of failure modes to test for. If you are building an evaluation set or planning a red-teaming exercise, the risk list is a better starting inventory than a blank page, and it has the advantage of being a named public document you can point at in a governance paper.
What each buys you legally
This is the section that matters and it is where most coverage is misleading.
- ISO 42001 gives no presumption of conformity with the EU AI Act. Under the Act, that presumption comes only from harmonised standards whose references are published in the Official Journal, and those are being developed by CEN-CENELEC JTC 21. ISO 42001 is not one of them. A certificate is evidence of a management system and it will help an auditor believe you; it does not satisfy Articles 8 to 15 and it is not a conformity assessment.
- NIST AI RMF has a specific statutory role in Colorado. The Colorado AI Act provides a rebuttable presumption that a developer or deployer used reasonable care where it complied with the NIST AI RMF or another recognised risk management framework. That is the strongest direct legal effect either framework has anywhere, and it is one US state.
- Both are procurement currency. The most common real reason to certify is that a customer’s security or vendor review asks for it, alongside SOC 2 and ISO 27001. That is a commercial reason and it is a perfectly good one.
- Neither replaces the legal analysis. A certified management system that has classified a system incorrectly under Annex III is a well-run process producing a wrong answer.
Which to do, and in what order
A sequence that works for an organisation with no framework in place:
- Build the inventory and the role determinations first. Neither framework tells you whether you are a provider or a deployer, and that determination drives everything with legal force.
- Use the NIST MAP function to structure the risk work. It is free, quick and produces the material both regimes need.
- Adopt the ISO 42001 clause structure for documentation even if you do not certify. It is a sensible skeleton and it means certification later is a formalisation rather than a rebuild.
- Certify when somebody is asking. If no customer, regulator or investor is asking for a certificate, the money is usually better spent on evaluation infrastructure.
- Track JTC 21 output separately. When harmonised standards are published, they — not ISO 42001 — are what gives the presumption of conformity, and that is the certificate worth having if you place high-risk systems on the EU market.