ISO/IEC 42001, the NIST AI RMF and the EU AI Act: a practitioner’s comparison
A management-system standard, a voluntary risk framework and a binding regulation. This white paper compares what each requires, where they overlap and where they diverge, and sets out how to build one AI governance program that serves all three.
- Published
- October 15, 2026
- Reading time
- 18 minutes
- Written by
- MarkTillson AI Governance Practice
Abstract. Organizations building or buying AI systems now face three reference points that are often discussed as if they were interchangeable. ISO/IEC 42001:2023 is a certifiable management-system standard. The NIST AI Risk Management Framework is a voluntary, outcome-oriented framework. The EU Artificial Intelligence Act is binding law with obligations that depend on role and risk. This paper compares their purpose, structure and requirements; maps where they reinforce each other; identifies where satisfying one does not satisfy another; and proposes a single program architecture. It is written for chief risk officers, CISOs, heads of data and AI, and internal audit leaders who must decide how to sequence the work.
1. Three instruments, three purposes
The most common mistake we see is choosing between these instruments as if they competed. They answer different questions. ISO/IEC 42001 answers: does this organization have a functioning system for governing AI? The NIST AI RMF answers: has this organization identified, measured and managed the risks of its AI systems in a structured way? The EU AI Act answers: has this provider or deployer met its legal obligations for this AI system?
| ISO/IEC 42001:2023 | NIST AI RMF 1.0 | EU AI Act | |
|---|---|---|---|
| Nature | International management-system standard | Voluntary framework | EU regulation (Regulation (EU) 2024/1689), directly applicable |
| Published | December 2023 | January 2023; Generative AI Profile (NIST AI 600-1) July 2024 | Entered into force August 2024; obligations phased, with high-risk dates amended in 2026 |
| Unit of focus | The organization’s AI management system | AI risks across the lifecycle | Individual AI systems and models, by role and risk category |
| Can you be certified? | Yes, by accredited certification bodies | No; organizations self-declare alignment | Conformity assessment for high-risk systems; not a general certification |
| Structure | Clauses 4–10 plus Annex A (38 reference controls across nine objectives) and guidance annexes | Four functions (Govern, Map, Measure, Manage) with 19 categories and 72 subcategories; companion Playbook | Prohibitions, transparency duties, high-risk requirements, GPAI obligations, governance and penalties |
| Consequence of non-alignment | Certificate not granted or withdrawn | None directly; reputational and contractual | Administrative fines and enforcement by authorities |
2. ISO/IEC 42001: the management system
ISO/IEC 42001 follows the harmonized structure shared by ISO management-system standards such as ISO/IEC 27001. Clauses 4 to 10 require the organization to understand its context and the role it plays in relation to AI (developer, provider, user and so on), establish leadership commitment and an AI policy, plan by assessing AI risks and AI system impacts, provide resources and competence, operate controls, evaluate performance through monitoring, internal audit and management review, and improve continually.
Annex A provides 38 reference controls organized under nine objectives, spanning AI policies, internal organization, resources, impact assessment, the AI system lifecycle, data for AI systems, information for interested parties, use of AI systems and third-party relationships. As with ISO/IEC 27001, these are reference controls: the organization selects those that are necessary and justifies its choices in a statement of applicability. Annex B gives implementation guidance; further annexes discuss organizational objectives, risk sources and use across sectors.
Several companion standards fill in detail: ISO/IEC 22989 for concepts and terminology, ISO/IEC 23894 for AI risk management guidance and ISO/IEC 42005 for AI system impact assessment. ISO/IEC 42006, published in 2025, sets requirements for the bodies that audit and certify AI management systems, which matters when selecting a certification body.
It does not prescribe technical thresholds for accuracy, robustness or fairness, and it does not by itself demonstrate that any particular AI system is safe. It demonstrates that the organization has a governed process for making and reviewing those judgments.
3. NIST AI RMF: the risk vocabulary
The NIST AI Risk Management Framework organizes activity into four functions. Govern establishes the culture, policies, accountability and processes for AI risk management and applies across the others. Map establishes the context for each AI system: its purpose, users, data, assumptions and potential impacts. Measure uses quantitative and qualitative methods to analyze, assess and track risks. Manage prioritizes and acts on risks, including response and recovery.
The framework describes the 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. It also recognizes that they involve trade-offs. NIST’s Generative AI Profile (NIST AI 600-1) applies the framework to risks that are novel to or exacerbated by generative AI, such as confabulation, information integrity and information security, and suggests corresponding actions.
The framework’s strength is its practical vocabulary for the system level: it tells teams what to look at when they assess a specific AI system. Its limitation, from an assurance perspective, is that it is voluntary and outcome-based. There is no certificate, and “aligned with the NIST AI RMF” means whatever the organization can evidence.
4. The EU AI Act: obligations by role and risk
The AI Act applies according to an actor’s role (provider, deployer, importer or distributor) and the category of the AI system or model. Certain practices are prohibited outright. Specified AI systems carry transparency duties. General-purpose AI models carry documentation and information duties, with additional obligations for models with systemic risk. The most demanding obligations attach to high-risk AI systems, defined through Annex I (safety components of regulated products) and Annex III (listed use cases such as employment, credit scoring, education, essential services, law enforcement and migration).
For high-risk systems, providers must implement a risk management system (Article 9), data and data governance practices (Article 10), technical documentation (Article 11), record-keeping through logging (Article 12), transparency and information to deployers (Article 13), human oversight (Article 14), and appropriate accuracy, robustness and cybersecurity (Article 15), within a quality management system (Article 17), followed by conformity assessment and registration. Deployers have their own obligations under Article 26, including using systems in accordance with instructions, assigning human oversight to competent people and monitoring operation; certain deployers must also carry out a fundamental rights impact assessment under Article 27.
Following the 2026 amendments, the high-risk obligations apply from 2 December 2027 for Annex III systems and 2 August 2028 for Annex I systems. Prohibitions, general-purpose AI obligations and the Article 50 transparency duties already apply.
5. Where they reinforce each other
The table below maps major governance topics across the three. “Strong” means the instrument addresses the topic directly; “Supporting” means it addresses the topic indirectly or in less detail.
| Topic | ISO/IEC 42001 | NIST AI RMF | EU AI Act (high-risk) |
|---|---|---|---|
| Accountability and roles | Strong: leadership, roles, responsibilities (cl. 5; A.3) | Strong: Govern | Strong: defined actor obligations |
| AI system inventory | Strong: implied by scope and lifecycle controls | Strong: Map, Govern | Supporting: registration of high-risk systems |
| Risk assessment | Strong: AI risk assessment and treatment (cl. 6, 8) | Strong: Map, Measure | Strong: Art. 9 risk management system |
| Impact assessment | Strong: AI system impact assessment (A.5; ISO/IEC 42005) | Strong: Map (impacts on individuals and society) | Strong for certain deployers: Art. 27 FRIA |
| Data governance | Strong: data for AI systems (A.7) | Supporting: Map, Measure | Strong: Art. 10, with specific quality criteria |
| Technical documentation | Supporting: lifecycle documentation | Supporting | Strong: Art. 11 and Annex IV, prescriptive content |
| Logging and traceability | Supporting: event logs (A.6) | Supporting: Measure, Manage | Strong: Art. 12 automatic logging |
| Human oversight | Supporting: use of AI systems (A.9) | Supporting: Govern, Manage | Strong: Art. 14, design for effective oversight |
| Accuracy, robustness, security | Supporting: objectives, verification | Strong: Measure; trustworthiness characteristics | Strong: Art. 15, including resilience to attacks |
| Third parties and suppliers | Strong: third-party relationships (A.10) | Strong: Govern (third-party risk) | Strong: value-chain obligations |
| Monitoring and improvement | Strong: cl. 9–10 | Strong: Manage | Strong: post-market monitoring, serious incident reporting |
6. Where satisfying one does not satisfy another
Certification is not conformity
An ISO/IEC 42001 certificate shows that a management system meets the standard. It does not establish that a given high-risk system meets Articles 9 to 15 of the AI Act, and ISO/IEC 42001 is not, on its own, a harmonized standard giving a presumption of conformity. Harmonized standards for the Act are being developed through CEN-CENELEC. Expect them to draw on international work, but plan for their specific content.
Prescriptive content versus principles
The AI Act specifies content: what technical documentation must contain (Annex IV), what logs must enable, what instructions for use must say. ISO/IEC 42001 and the NIST AI RMF set principles and processes. A program designed only to the standard will need additional, system-specific artifacts for each high-risk system.
Scope of applicability
ISO/IEC 42001 applies to whatever scope the organization defines. The NIST AI RMF applies wherever the organization chooses to use it. The AI Act applies by law, according to role and system category, whether or not the organization has chosen to include the system in its governance scope. Inventory and classification must therefore be complete, not selective.
Security depth
None of the three is a substitute for technical security testing. Article 15 requires resilience against attempts to exploit vulnerabilities, including data poisoning, model evasion and adversarial examples; the NIST Generative AI Profile highlights information security risks. Demonstrating these properties requires adversarial testing of the actual system for prompt injection, data leakage, model extraction and unsafe tool use. Policy alone cannot show it.
7. One program, three outputs
We recommend building a single AI governance program with ISO/IEC 42001 as the management-system spine, the NIST AI RMF as the system-level risk method, and an AI Act obligations layer applied according to role and classification.
Recommended sequence
- Inventory and classify. Identify every AI system in development, in production and procured, with purpose, role, data, supplier and owner. Screen each for prohibited practices, Article 50 transparency duties and potential Annex I or Annex III high-risk status, and record the reasoning.
- Establish governance. Approve an AI policy, define roles (including accountable owners per system), set the risk appetite and create the AI risk and impact assessment procedures. These are ISO/IEC 42001 clauses 5 and 6, and the NIST Govern function.
- Assess systems with one method. Use the NIST AI RMF Map and Measure functions as the template for system-level assessment, adding the Generative AI Profile where relevant, and record results in a format that also serves the ISO/IEC 42001 risk treatment plan.
- Test adversarially. Red-team systems that are high-impact, customer-facing or connected to tools and data, and feed findings into treatment.
- Add the regulatory layer to in-scope systems. For any system likely to be high-risk, start the Annex IV technical documentation, logging design, human oversight design and quality management integration now. These take the longest.
- Operate and audit. Run internal audit and management review, then decide whether to pursue ISO/IEC 42001 certification. Certification is valuable where customers, regulators or partners expect it; it is not a legal requirement.
8. A decision guide by organization type
| If you are… | Prioritize | Why |
|---|---|---|
| A SaaS company embedding generative AI features, selling to enterprises | Inventory, NIST AI RMF assessments, Article 50 review, then ISO/IEC 42001 certification | Buyers’ questionnaires and certification expectations drive commercial outcomes; transparency duties already apply |
| A bank or insurer using AI in credit or underwriting decisions | Classification against Annex III, deployer obligations, integration with model risk management and DORA | Likely high-risk use cases with supervisory attention; existing model-risk disciplines can be extended |
| A provider of a high-risk AI system | Quality management system, Annex IV documentation, logging and oversight design, conformity assessment planning | The most prescriptive obligations fall on providers, and they take the longest to build |
| A US-headquartered organization with limited EU exposure | NIST AI RMF as the operating method, ISO/IEC 42001 for external assurance | Voluntary frameworks shape customer and regulator expectations; certification gives portable evidence |
9. Common pitfalls
- Governance without an inventory. Policies that cannot name the systems they govern will fail audit and regulatory scrutiny alike.
- Treating procured AI as out of scope. Deployers have obligations under the Act, and third-party AI is within ISO/IEC 42001’s supplier controls.
- Confusing a model card with technical documentation. Annex IV content is far broader.
- Assuming certification equals compliance. It does not, and buyers and regulators know the difference.
- Leaving security to the end. Adversarial weaknesses found late can force architectural change.
Key takeaways
- They answer different questions: organizational governance, system risk and legal obligation.
- Use ISO/IEC 42001 as the spine, the NIST AI RMF as the system-level method and the AI Act as an obligations layer.
- A 42001 certificate is not AI Act conformity, and should never be presented as such.
- Start with a complete inventory and recorded classification.
- Begin high-risk documentation and oversight design now; the deferral to December 2027 is shorter than it looks.
- Adversarial testing is indispensable to all three.
Sources
- ISO/IEC 42001:2023, Information technology, Artificial intelligence, Management system.
- ISO/IEC 22989:2022; ISO/IEC 23894:2023; ISO/IEC 42005:2025; ISO/IEC 42006:2025.
- NIST, AI 100-1, Artificial Intelligence Risk Management Framework (AI RMF 1.0), January 2023, and the AI RMF Playbook.
- NIST, AI 600-1, Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile, July 2024.
- Regulation (EU) 2024/1689 (Artificial Intelligence Act), as amended in 2026 by the Digital Omnibus on AI.
Our AI governance practice builds this program end to end: the inventory, the ISO/IEC 42001 management system, NIST-based system assessments, AI red teaming and the AI Act evidence layer. You finish ready for your certification audit and ready for your regulator. Talk to the authors about where to start.
