AI GOVERNANCE AND REGULATION / ADVANCED

One Control Set, Many Frameworks: Mapping NIST AI RMF, ISO/IEC 42001 And The EU AI Act

Running separate programmes for each AI framework wastes effort. This crosswalk maps common governance activities to NIST AI RMF, ISO standards and the EU AI Act so one control can serve all three.

Checked against primary sources and independently reviewed on . Sources are listed at the end.

An organisation that sells AI products into Europe, answers to US customers and wants an international certificate can end up with three overlapping programmes: one for the EU AI Act, one built on the NIST AI Risk Management Framework, and one for ISO/IEC 42001. Each has its own vocabulary, but underneath they ask for many of the same things.

This article maps those shared activities across the three so that a single control can produce evidence for all of them. It assumes you know the basics covered in What AI Governance Means and The EU AI Act After The Digital Omnibus.

Why The Frameworks Differ In Kind

The three sources are different types of document, and the crosswalk only works if you keep that in mind. The EU AI Act is binding law with fines, and most of its detailed duties apply only to specific systems, chiefly high-risk ones.1 The NIST AI RMF is a voluntary framework organised into functions, categories and subcategories that describe outcomes rather than mandatory steps.2 ISO/IEC 42001 sets requirements for an AI management system within an organisation, and certification against it is voluntary unless a customer demands it.3

So the direction of the mapping matters. A control designed to satisfy a specific AI Act article will usually also count as evidence for the matching NIST outcome and ISO management system activity. The reverse is weaker: meeting a NIST subcategory does not prove you met a legal requirement, because the law sets specific content, timing and recipients.

The Crosswalk

The table maps eight governance activities. NIST references are to subcategories in AI RMF 1.0. AI Act references are to Regulation (EU) 2024/1689 as amended by the Digital Omnibus, and apply mainly to high-risk systems unless stated.1 4 For ISO, the table names the relevant standard rather than clause numbers; ISO/IEC 23894 is guidance on AI risk management and is not certifiable.5 ISO/IEC 42001 sets requirements for the management system as a whole, so most activities sit inside it; check the standard itself, which is not free, for the exact clauses.

ActivityNIST AI RMF 1.0ISO StandardsEU AI Act
AI System InventoryGOVERN 1.6: mechanisms to inventory AI systemsISO/IEC 42001 management system requirementsNo general inventory duty; registration in the EU database for most Annex III high-risk systems, and for Annex III systems a provider judges not high-risk (Articles 6(4) and 49)
Roles And AccountabilityGOVERN 2.1: roles, responsibilities and lines of communicationISO/IEC 42001 management system requirementsProvider and deployer duties (Articles 16 and 26); value chain roles (Article 25); quality management system (Article 17)
Risk AssessmentMAP 1.1 and MAP 5.1: context, likelihood and magnitude of impactsISO/IEC 42001 risk processes, with ISO/IEC 23894 as guidanceRisk management system across the lifecycle (Article 9)
Impact On PeopleMAP 5.1: impacts on individuals, groups and societyISO/IEC 42005: AI system impact assessmentFundamental rights impact assessment for certain deployers (Article 27)
Data Governance And BiasMAP 2.3 and MEASURE 2.11: data suitability, fairness and biasISO/IEC 42001 management system requirementsData and data governance (Article 10); bias detection data basis (new Article 4a)
Testing And SecurityMEASURE 2.3, 2.6 and 2.7: performance, safety, security and resilienceISO/IEC 42001, alongside ISO/IEC 27001 where an information security management system already existsAccuracy and cybersecurity (Article 15); adversarial testing for systemic-risk models (Article 55)
Human OversightMAP 3.5: processes for human oversightISO/IEC 42001 management system requirementsHuman oversight by design (Article 14) and competent oversight by deployers (Article 26)
Monitoring And IncidentsMEASURE 2.4, MANAGE 4.1 and MANAGE 4.3: monitoring, incident response and communicationISO/IEC 42001 requirement to maintain and continually improve the management systemPost-market monitoring (Article 72); serious incident reports on a fixed clock, 15 days at most and shorter for the gravest cases (Article 73)
Governance activities mapped across frameworks, as of October 2026. A starting point for control design, not a legal opinion.

Two rows show where the law goes further. Under Article 73, a provider must report a serious incident to the market surveillance authority as soon as it has established a causal link, or a reasonable likelihood of one, between the AI system and the incident, and in any case within 15 days. Two cases are stricter. A widespread infringement or a serious and irreversible disruption of critical infrastructure must be reported immediately and within 2 days. A death must be reported as soon as a causal link is established or even suspected, and within 10 days. Each clock starts when the provider, or where relevant the deployer, becomes aware of the incident.1 NIST asks that incidents be communicated and tracked, but sets no regulator or clock.2 Likewise, the fundamental rights impact assessment in Article 27 has defined content and applies to defined deployers, while ISO/IEC 42005 offers a method you can use to produce it.6

Adding Generative AI Risks

For generative systems, NIST AI 600-1 lists 12 risks, including confabulation, information security, information integrity, harmful bias and value chain and component integration.7 Use it as a checklist when filling the risk assessment and testing rows. Value chain risk, for instance, matches NIST GOVERN 6.1 and MANAGE 3.1 on third-party data and models, and connects to the AI Act’s rules on who becomes a provider when a system is modified or rebranded (Article 25).2 Specific attack techniques to test for are covered in AI Security.

Building One Control Set

  1. Inventory And Classify

    List every AI system and model you build, buy or embed. Record its purpose, owner, data and EU AI Act tier.

  2. Start From The Strictest Source

    For each system in scope of the AI Act, design controls against the relevant articles first, since they set legal minimums.

  3. Tag Each Control

    Record which NIST subcategories and ISO activities each control also satisfies, so one piece of evidence serves several frameworks.

  4. Fill The Gaps

    Add controls for NIST or ISO outcomes the law does not require, such as decommissioning (GOVERN 1.7), for systems outside the high-risk tier.

  5. Run It As A Management System

    Review, audit and improve the controls on a cycle, which is what ISO/IEC 42001 certification will examine.

A practical sequence for building one set of controls that serves several frameworks.

Who Owns Each Row

A crosswalk only helps if someone is responsible for each activity. In practice the inventory and classification usually sit with a central AI governance or risk function, data governance with data owners, testing and security with engineering and the security team, and incident reporting with whoever already handles regulatory notifications. Writing the owner next to each row turns the table into a working plan. It also exposes gaps quickly: an activity with no owner is the one most likely to be missing when an auditor or regulator asks for evidence.

Limits Of Any Crosswalk

A mapping shows where frameworks address the same topic. It does not show that they demand the same depth. The AI Act’s technical documentation for high-risk systems has prescribed content, while a NIST outcome may be met with a lighter record. Treat each row as a prompt to check the source text, and have legal counsel confirm the AI Act columns for any system that may be high-risk.

Footnotes

  1. European Parliament and Council, “Regulation (EU) 2024/1689 (Artificial Intelligence Act)”, Articles 6, 9, 10, 14 to 17, 25 to 27, 49, 55, 72 and 73, Official Journal, 12 July 2024. eur-lex.europa.eu ↩ ↩2 ↩3

  2. NIST, “Artificial Intelligence Risk Management Framework (AI RMF 1.0)”, NIST AI 100-1, January 2023, Tables 1 to 4. nvlpubs.nist.gov ↩ ↩2 ↩3

  3. ISO, “ISO/IEC 42001:2023 Information technology, Artificial intelligence, Management system”, December 2023. iso.org ↩

  4. European Parliament and Council, “Regulation (EU) 2026/1744 (Digital Omnibus on AI)”, 8 July 2026, Official Journal, 24 July 2026, including Article 1, point (6), inserting Article 4a, and point (12), amending Article 25. eur-lex.europa.eu ↩ ↩2

  5. ISO, “ISO/IEC 23894:2023 Information technology, Artificial intelligence, Guidance on risk management”, February 2023. iso.org ↩

  6. ISO, “ISO/IEC 42005:2025 AI system impact assessment”, May 2025. iso.org ↩

  7. NIST, “Generative Artificial Intelligence Profile”, NIST AI 600-1, July 2024. nvlpubs.nist.gov ↩

  8. NIST, “AI Risk Management Framework”, accessed 7 October 2026. nist.gov ↩

Knowledge Hub content is general information. It is not legal advice, a compliance certification, a guarantee of security or a substitute for an assessment of your own systems. Standards and rules change; check the sources for the latest position.