NIST AI RMF vs ISO 42001 vs the EU AI Act: One Is Law, One Is Certifiable, One Is Free — What an NIS2 Entity Should Adopt First
Short answer: these are not three options to choose between. The EU AI Act is a regulation: you don’t adopt it, it applies to you according to your role as a provider or deployer of AI systems. ISO/IEC 42001 is a management-system standard you buy, implement and can have certified. The NIST AI Risk Management Framework (AI RMF) is a free, voluntary US framework with no certificate at all. For most NIS2 entities, which use AI built by someone else, the sensible order is: establish your AI Act role first, fold your AI systems into the Article 21 risk process you already run (using the NIST AI RMF as a free reference), and pay for ISO 42001 certification only when customers or your own product strategy make it worth the money.
NIS2 itself asks for none of the three. In the text of Directive (EU) 2022/2555, “artificial intelligence” appears only in recitals 51 and 89, and both treat AI as a defensive tool entities may adopt, not as something to govern (we counted every mention in our ISO 42001 and EU AI Act analysis). That doesn’t put AI outside NIS2. Article 6(1)(b) defines a network and information system as “any device or group of interconnected or related devices, one or more of which, pursuant to a programme, carry out automatic processing of digital data” — a definition that covers a model server, a copilot tenant or an AI-enabled SCADA add-on. Article 21’s all-hazards duty therefore already covers your AI estate. The real question is which framework helps you discharge that duty, and which extra obligations the AI Act adds on top.
This article provides general information only and does not constitute legal or regulatory advice. Requirements may vary by jurisdiction and organisation type. Consult a qualified legal professional or compliance specialist for advice specific to your situation.
Which of the Three Binds You? The Scope Table
In plain terms: only the AI Act is law, and it bites by role, not by choice. The other two are voluntary tools, and only ISO 42001 ends in a certificate.
Get the NIS2 Article 21 Compliance Checklist
90+ assessment items mapped to CIR 2024/2690 — instant PDF, no payment.
| Question | EU AI Act | ISO/IEC 42001 | NIST AI RMF 1.0 |
|---|---|---|---|
| Legal nature | Binding regulation: Regulation (EU) 2024/1689 | International standard, voluntary | Voluntary US framework (NIST AI 100-1) |
| Who it applies to | Providers, deployers, importers and distributors of AI systems, by role | Any organisation that chooses to run an AI management system | Anyone; NIST calls it “non-sector-specific, and use-case agnostic” |
| Certificate | Conformity assessment for high-risk systems (a provider duty); none for deployers | Yes, third-party certification of the management system | None offered |
| Cost to access the text | Free | Paid standard, plus audit fees if you certify | Free |
| Incident reporting deadline | Article 73: 15 days; 2 days for serious disruption of critical infrastructure; 10 days for a death | None | None |
| Status, October 2026 | Prohibitions live since 2 Feb 2025; Article 50 transparency live since 2 Aug 2026; high-risk rules deferred to 2 Dec 2027 / 2 Aug 2028 | ISO/IEC 42001:2023 current; the AI Act’s own QMS standard, EN 18286:2026, published July 2026 | Version 1.0 (January 2023), currently being revised; draft profiles for cybersecurity and critical infrastructure in progress |
The deferral in the last row comes from Regulation (EU) 2026/1744, the Digital Omnibus on AI, which replaced Article 113’s high-risk date: Chapter III Sections 1 to 3 now apply from 2 December 2027 for Annex III systems and 2 August 2028 for Annex I systems. Older comparison articles still quote 2 August 2026. The EU cyber compliance deadline tracker keeps the NIS2, AI Act and CRA dates side by side.
The role test decides everything else. Article 3(3) makes you a provider if you develop an AI system, or have one developed, and place it on the market or put it into service “under its own name or trademark”. Article 3(4) makes you a deployer if you use an AI system “under its authority” outside personal activity. A hospital running a vendor’s triage model is a deployer. A software house selling that model is a provider. Most NIS2 entities sit firmly in the first group.
NIST AI RMF in Practice: 72 Outcomes, No Checklist, One Security Characteristic
In plain terms: the NIST AI RMF gives you a shared vocabulary for AI risk. It is strongest where NIS2 says nothing (bias, explainability, human oversight) and thinnest where NIS2 is most detailed (security controls and reporting).
NIST AI 100-1 organises AI risk work into four functions: GOVERN, MAP, MEASURE and MANAGE. We counted the core tables: 19 categories and 72 subcategories (GOVERN 19, MAP 18, MEASURE 22, MANAGE 13). NIST is explicit that these “do not constitute a checklist, nor are they necessarily an ordered set of steps.” GOVERN is cross-cutting, and its first subcategory, GOVERN 1.1, is the one an EU entity should read first: legal and regulatory requirements involving AI “are understood, managed, and documented.” In other words, the framework expects you to bring the AI Act and NIS2 to it. It won’t bring them to you.
The framework 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. Only one is about security, and for that one NIST points elsewhere: “Guidelines in the NIST Cybersecurity Framework and Risk Management Framework are among those which are applicable here.” That sentence is the key to using the AI RMF under NIS2. The cybersecurity half of NIST’s AI guidance lives in the CSF family, not in the AI RMF.
Three companion documents fill that gap, and all three matter more to a NIS2 entity than the core:
- The Cyber AI Profile. NIST IR 8596 applies CSF 2.0 outcomes to AI under three focus areas: securing AI system components, AI-enabled cyber defence, and thwarting AI-enabled attacks. It is still an initial preliminary draft (published 16 December 2025, comments closed 30 January 2026). If you already map NIS2 to CSF 2.0 (see our NIS2 vs NIST CSF 2.0 gap map), this is the document that will slot AI into that work.
- The Generative AI Profile. NIST AI 600-1 (July 2024) lists 12 risks unique to or made worse by generative AI. Two of them, Information Security and Value Chain and Component Integration, map naturally onto Article 21(2)(d) and (e). It is the most practical NIST text for a copilot rollout. Pair it with a generative AI acceptable use policy.
- The critical infrastructure profile. On 7 April 2026 NIST published a concept note for an AI RMF Profile on Trustworthy AI in Critical Infrastructure, covering AI across IT, OT and industrial control systems. It is a concept, not a draft yet, but energy, water and transport operators should watch it.
One caveat before you write “NIST AI RMF” into a policy. America’s AI Action Plan (July 2025) directs NIST to “revise the NIST AI Risk Management Framework to eliminate references to misinformation, Diversity, Equity, and Inclusion, and climate change,” and NIST’s AI RMF page confirms that version 1.0 “is being revised.” NIST’s page listed no revised draft as of early October 2026. In practice, cite “AI RMF 1.0” by version number. The bias and fairness material in 1.0 is the part most relevant to EU fundamental-rights expectations, and a version-pinned reference stops a US revision from quietly changing your internal baseline.
The Crosswalk Problem: NIST’s Bridges Point at Drafts
In plain terms: every vendor says the three frameworks “map” onto each other. The two mappings NIST itself lists were both built against draft texts, and neither one touches NIS2.
NIST’s crosswalk page opens with a caveat worth quoting in any audit file: inclusion “does not imply NIST endorsement of the resource the AI RMF is mapped to, nor does it imply that either resource comprehensively covers the contents of the other.” Then look at what is listed:
- The AI RMF to ISO/IEC 42001 crosswalk (listed with Microsoft as its provider) maps against ISO/IEC FDIS 42001, the final draft before publication. We parsed all 16 pages. Every one of the 72 subcategories maps to at least one ISO reference, and the mappings touch 38 distinct control-guidance items in Annex B.
- The only EU entry is a two-page table, marked “Draft for Comment” and dated January 2023, that relates the AI RMF’s trustworthiness characteristics to the proposed EU AI Act. It has no article numbers, no provider or deployer duties, and predates both the adopted Regulation and the Omnibus.
Two rows of the 42001 crosswalk show where the gap sits for a NIS2 entity. MEASURE 2.7 (AI system security and resilience) maps to data, roles, policy alignment, impact assessment and design documentation guidance. It maps to no dedicated security control, and ISO/IEC 27001 is not mentioned anywhere in the document. MANAGE 4.3 (incidents and errors) maps to management review inputs (clause 9.3.2) and information for interested parties. Nothing in it resembles a regulator deadline. So even with both frameworks in place, the two things NIS2 supervisors look at hardest, security measures and incident reporting, still sit with your ISMS. The ISO 27001 side of that story is covered in our IT security frameworks comparison.
Because no authoritative NIS2 mapping exists, here is the working version we use. It is labelled for what it is.
Practical mapping (interpretation, not legal equivalence). ISO references per the NIST-listed crosswalk; AI Act provisions verified against the Official Journal text.
| NIS2 Art. 21(2) measure | NIST AI RMF 1.0 | ISO/IEC 42001 (crosswalk) | EU AI Act hook | What still falls to NIS2 |
|---|---|---|---|---|
| (a) Risk analysis and information system security policies | GOVERN 1.1, MAP 4.1 | 4.1, 6.2, B.2.2 AI policy | Art. 9 risk management system (providers of high-risk AI) | AI systems in the Art. 21 risk register and asset inventory |
| (b) Incident handling | MANAGE 4.3 | 9.3.2, B.8.5, B.6.2.6 | Art. 26(5) deployer alerts provider; Art. 73 serious incidents | 24-hour early warning, 72-hour notification (Art. 23) |
| (d) Supply chain security | GOVERN 6.1, 6.2; MANAGE 3.1, 3.2 | B.10.2, B.10.3 Suppliers, B.4.4 | Art. 26(1): use per the provider’s instructions | Supplier security clauses and assessment (Art. 21(3)) |
| (e) Acquisition, development, maintenance, vulnerability handling | MEASURE 2.7 | B.7.2, B.6.2.3 (no security-specific control) | Art. 15(5): data poisoning, model poisoning, adversarial examples (providers) | Patching, hardening and vulnerability disclosure for AI components |
| (g) Cyber hygiene and training | GOVERN 2.2 | 7.2 Competence | Art. 4 AI literacy (as amended in 2026) | Security awareness covering AI-specific threats |
Article 15(5) is a useful shopping list even if you are only a deployer. It names the attack classes a high-risk AI system must resist: manipulation of training data (“data poisoning”), of pre-trained components (“model poisoning”), inputs “designed to cause the AI model to make a mistake (adversarial examples or model evasion)”, confidentiality attacks and model flaws. Put those four classes into your threat model for any AI system that touches an essential service. For products with digital elements, the Cyber Resilience Act offers a shortcut: under CRA Article 12, a high-risk AI product that meets the CRA’s essential cybersecurity requirements, and demonstrates this in its EU declaration of conformity, “shall be deemed to comply” with Article 15’s cybersecurity requirements, and the Omnibus wrote the matching presumption into AI Act Article 42(3). Ask AI vendors which route they use. See the CRA compliance guide for the vendor side.
Three Incident Clocks: 24 Hours, 2 Days, or Never
In plain terms: neither voluntary framework sets a reporting deadline. The two EU laws set different ones, and an AI failure at a critical infrastructure operator could eventually start both.
| Regime | Trigger | Deadline | Who reports, to whom |
|---|---|---|---|
| NIS2 Art. 23(4)(a)–(b) | Significant incident | Early warning within 24 hours; incident notification within 72 hours | Essential or important entity → CSIRT or competent authority |
| AI Act Art. 73(2) | Serious incident (general) | Immediately once a causal link is established; no later than 15 days after awareness | Provider of a high-risk system → market surveillance authority |
| AI Act Art. 73(3) | Widespread infringement, or “serious and irreversible disruption of the management or operation of critical infrastructure” (Art. 3(49)(b)) | Immediately; no later than 2 days | Provider → market surveillance authority |
| AI Act Art. 26(5) | Deployer identifies a serious incident | “Immediately inform first the provider”, then importer or distributor and authorities | Deployer → provider |
| NIST AI RMF MANAGE 4.3 / ISO/IEC 42001 | Incidents and errors | None set | Internal and “relevant AI actors” |
Consider an electricity distribution operator using a vendor’s AI load-forecasting system as a safety component in grid operation. That is an Annex III point 2 use case. If the model fails and causes a serious outage, the operator faces a NIS2 early warning within 24 hours today. Once the high-risk rules apply on 2 December 2027, the same event could also be an AI Act serious incident with a 2-day provider clock, and the operator’s Article 26(5) duty to alert the provider “immediately” feeds that clock. (Interpretation: whether a given outage meets both thresholds is a case-by-case assessment under national rules.) The Cloud Security Alliance notes that ISO/IEC 42001 “does not codify the Article 73 serious-incident reporting timelines”. The AI RMF doesn’t either. Write both triggers into one incident runbook, and require AI vendors by contract to deliver root-cause information fast enough for your 24-hour early warning.
Note: reporting portals, significance thresholds and national designations of AI market surveillance authorities vary by member state. Confirm with your national competent authority.
Penalties and Dates That Are Actually Live in October 2026
In plain terms: the AI Act fines that matter today hit prohibited practices and transparency failures. The high-risk deployer duties are 14 months away. NIS2 fines are already live through national law.
| Obligation | Applies from | Maximum administrative fine |
|---|---|---|
| AI Act Art. 5 prohibited practices | 2 Feb 2025 (new Art. 5(1)(ba)/(bb) from 2 Dec 2026) | Up to €35M or 7% of worldwide turnover, whichever is higher (Art. 99(3)) |
| AI Act Art. 50 transparency (e.g. deployers disclosing deep fakes) | 2 Aug 2026 | Up to €15M or 3% (Art. 99(4)(g)) |
| AI Act Art. 26 deployer duties for high-risk AI | 2 Dec 2027 (Annex III) / 2 Aug 2028 (Annex I) | Up to €15M or 3% (Art. 99(4)(e)) |
| AI Act Art. 4 AI literacy | 2 Feb 2025; text amended in 2026 to “take measures to support the development of AI literacy” | Not listed in Art. 99(4); penalties left to national rules under Art. 99(1) |
| NIS2 Art. 21 and 23 (essential entities) | National transposition law | Maximum of at least €10M or 2% (Art. 34(4)) |
| NIS2 Art. 21 and 23 (important entities) | National transposition law | Maximum of at least €7M or 1.4% (Art. 34(5)) |
| ISO/IEC 42001 / NIST AI RMF | Voluntary | No legal penalty |
For SMEs, Article 99(6) of the AI Act caps each fine at the lower of the two amounts rather than the higher. NIS2 figures may reach these levels subject to national law and supervisory discretion, and Article 20(1) makes management bodies approve the Article 21 measures and liable for infringements. AI systems inside that perimeter are a board matter whether or not the AI Act classifies them as high-risk. For the full overlap of the two regimes, see NIS2 and AI Act dual compliance.
Which One Should You Adopt First? A Decision Tree
In plain terms: answer four questions in order. The first “yes” tells you where your effort goes. This is a general framework, not a determination about any specific organisation.
- Do you develop AI systems and place them on the EU market, or put them into service, under your own name? If yes, you are a provider, and if any system is high-risk, the Article 17 quality management system is your core obligation from December 2027 or August 2028. The standard written for it is EN 18286:2026, which CEN-CENELEC describes as “the first harmonized European standard for the AI Act regulatory purposes”. Under Article 40(1), presumption of conformity attaches only once a standard’s reference is published in the Official Journal, and we found no such publication for EN 18286 as of early October 2026. ISO 42001 complements it but does not replace it.
- Do you use AI as a safety component in managing or operating critical digital infrastructure, road traffic, or the supply of water, gas, heating or electricity? That is Annex III point 2. Organisations in this position are typically deployers of high-risk AI, with Article 26 duties (use per instructions, competent human oversight, monitoring, log retention) from 2 December 2027. Start the system inventory now. The NIST critical infrastructure profile and the Cyber AI Profile are the most relevant NIST documents for this group.
- Do customers, tenders or your group policy demand a certificate? Of the three instruments, only ISO 42001 produces one. If you rely on a supplier’s certificate instead, read the scope. Microsoft’s own guidance on its Copilot certification states that customers remain “responsible, however, for engaging an assessor to evaluate the controls and processes within your own organization.”
- None of the above? This is where most NIS2 entities land: copilots, SaaS with AI features, AI in the security stack. A separate AI programme is rarely justified. Add AI systems to the asset inventory and risk register you already keep, use the AI RMF subcategories in the mapping table as review prompts, check your Article 50 and Article 4 position now, and put AI-specific questions into your supply chain security assessments.
Who Does What This Quarter
In plain terms: the same three instruments ask different things of the CISO, the compliance lead, the board and the owner of a smaller company.
| Role | Action (recommended practice) | Effort |
|---|---|---|
| CISO / IT security | Register every AI system as a network and information system; add the four Art. 15(5) attack classes to threat models; track the Cyber AI Profile draft against your CSF 2.0 mapping | Medium |
| Compliance / legal | Classify each AI system by AI Act role and risk tier; name your reference framework and version (“NIST AI RMF 1.0”) in policy; add Art. 26(5) and Art. 73 triggers to the incident runbook beside Art. 23 | Medium |
| Board / C-suite | Make sure the Art. 20 approval of Art. 21 measures explicitly covers AI systems; decide on ISO 42001 certification as a commercial question, not a compliance one | Low |
| SME owner | Skip certification unless a customer asks for it; keep a one-page AI use policy and ask AI vendors three questions: who is the provider, which AI Act tier, how fast will you tell us about an incident | Low |
The Bottom Line
For a NIS2 entity, “NIST AI RMF vs ISO 42001 vs the EU AI Act” comes down to two decisions. The AI Act decides your obligations by role, so the first job is classification, not adoption. The second decision, which voluntary framework to use, is smaller than vendors make it sound. The NIST AI RMF is a free reference that structures the trustworthiness work NIS2 never mentions. ISO 42001 is worth the audit fees when someone will pay you for the certificate. Neither replaces the security measures and 24-hour reporting NIS2 already requires of you.
Frequently Asked Questions
Is the NIST AI RMF mandatory for EU companies?
No. NIST describes the AI RMF as “intended to be voluntary,” and no EU law references it. NIS2 Article 21(1) refers to “relevant European and international standards” where applicable; the AI RMF is neither, so treat it as good practice that supports your Article 21 measures rather than as something NIS2 points to.
Does ISO 42001 certification give presumption of conformity with the AI Act?
No. Under Article 40(1), presumption attaches only to harmonised standards whose references are published in the Official Journal. ISO/IEC 42001 is not one of them. EN 18286:2026 is the European standard written for the Article 17 quality management system.
Does NIS2 require an AI governance framework?
No. NIS2 mentions artificial intelligence only in two recitals, and recitals are not binding. AI systems are still covered by Article 21 as network and information systems, so they belong in your existing risk management, supply chain and incident processes.
Is the NIST AI RMF still usable while it is being revised?
Yes. Version 1.0 remains the published framework. Reference it by version number so that a future revision doesn’t change your internal baseline without a deliberate decision.
Can one control set cover all three?
Partly. A single AI risk register and supplier process can feed AI RMF outcomes, ISO 42001 clauses and AI Act deployer duties. Mapping is not equivalence, though, and NIST’s own crosswalk page says no listed crosswalk implies that “either resource comprehensively covers the contents of the other.”
Sources
- European Parliament and Council — Directive (EU) 2022/2555 (NIS2), Articles 6, 20, 21, 23, 34; recitals 51 and 89. Official Journal of the European Union.
- European Parliament and Council — Regulation (EU) 2024/1689 (AI Act), Articles 3, 4, 9, 15, 26, 40, 42, 50, 73, 99, 113; Annex III. Official Journal of the European Union.
- European Parliament and Council — Regulation (EU) 2026/1744 (Digital Omnibus on AI), 8 July 2026, OJ 24 July 2026.
- European Parliament and Council — Regulation (EU) 2024/2847 (Cyber Resilience Act), Article 12.
- NIST — Artificial Intelligence Risk Management Framework (AI RMF 1.0), NIST AI 100-1, January 2023.
- NIST — AI Risk Management Framework programme page (revision status; critical infrastructure profile announcement).
- NIST — AI RMF: Generative Artificial Intelligence Profile, NIST AI 600-1, July 2024.
- NIST — IR 8596 Initial Preliminary Draft, Cybersecurity Framework Profile for Artificial Intelligence (Cyber AI Profile), 16 December 2025.
- NIST — Concept Note: AI RMF Profile on Trustworthy AI in Critical Infrastructure, April 2026.
- NIST Trustworthy and Responsible AI Resource Center — Crosswalks to the NIST AI RMF.
- NIST AI RMF to ISO/IEC FDIS 42001 AI Management System Crosswalk (provider: Microsoft, as listed by NIST).
- NIST — Crosswalk: AI RMF trustworthiness characteristics and the OECD Recommendation on AI, Proposed EU AI Act, EO 13960 and Blueprint for an AI Bill of Rights (Draft for Comment), January 2023.
- The White House — America’s AI Action Plan, July 2025.
- CEN-CENELEC — EN 18286 in the Spotlight: Supporting Compliance with the AI Act, July 2026.
- Cloud Security Alliance Labs — EU AI Act Compliance: prEN 18286 and ISO 42001, research note, April 2026.
- Microsoft Learn — ISO/IEC 42001:2023 Artificial Intelligence Management System Standards (compliance offering page).
Get the NIS2 Article 21 Compliance Checklist
90+ assessment items mapped to CIR 2024/2690 — instant PDF, no payment.
