ISO 42001 and the EU AI Act: NIS2 Mentions AI 3 Times, None Binding — Do You Need an AI Management System?

NIS2 does not require an AI management system. The EU AI Act does not require ISO/IEC 42001 either. Both statements survive contact with the primary texts, and the second one tends to surprise people who have been sold certification as a shortcut to AI Act readiness.

That leaves a business question rather than a compliance one. You are an essential or important entity, you have started running AI somewhere real — a copilot in the service desk, anomaly detection in the SOC, a scoring model in operations — and someone on the board has asked whether you need to certify. This guide answers that with the regulations’ own wording, the exact article numbers, and the July 2026 amendment that reset every deadline the existing advice was built on.

Does This Apply to You? Three Questions That Settle It

What you owe depends on whether you merely use AI or build and sell it. Most NIS2-regulated entities are users, and users have far less to do. Nothing in the table below is triggered by ISO 42001, and nothing in it is satisfied by ISO 42001.

Your situation	What actually binds you	From when
NIS2 entity using AI that is not high-risk (spam filtering, SOC anomaly detection, drafting assistants)	NIS2 Article 21 only. No AI Act high-risk duties at all.	Already in force
NIS2 entity deploying a high-risk AI system from Annex III (recruitment, credit scoring, worker management, critical-infrastructure safety)	NIS2 Article 21 plus AI Act Article 26 deployer duties	2 December 2027
NIS2 entity deploying high-risk AI that is a safety component of a product already regulated under Annex I	NIS2 Article 21 plus AI Act Article 26 deployer duties	2 August 2028
NIS2 entity that develops and places on the market its own high-risk AI system	NIS2 Article 21 plus the full provider set, including the Article 17 quality management system	2 December 2027 (Annex III) / 2 August 2028 (Annex I)
Any organisation whose AI generates synthetic audio, image, video or text, placed on the market before 2 August 2026	AI Act Article 50(2) marking duty	2 December 2026

One Annex III entry deserves a second look from this audience specifically. Area 2 covers “AI systems intended to be used as safety components in the management and operation of critical digital infrastructure, road traffic, or in the supply of water, gas, heating or electricity” [1]. If you are a NIS2 entity in energy, water or digital infrastructure and AI has crept into a safety-related control function, you reach Annex III scope through that door — not through anything NIS2 itself says.

The split that matters is deployer versus provider. Article 26 requires a deployer to use the system in accordance with its instructions for use, to assign human oversight to people with “the necessary competence, training and authority”, and — where the deployer controls the input data — to ensure that data is “relevant and sufficiently representative in view of the intended purpose” [1]. That is a handful of duties. Article 17, the provider’s quality management system, runs to thirteen lettered points [1]. If you buy your AI rather than build it, you are almost certainly in the first group, and the heavyweight obligation everyone writes about is not yours.

What NIS2 Actually Says About AI: Three Mentions, None of Them Binding

I counted. Working from the official Official Journal text of Directive (EU) 2022/2555 and splitting it at “HAVE ADOPTED THIS DIRECTIVE”, the phrase “artificial intelligence” appears three times in the whole directive — twice under recital 51, once under recital 89 — and zero times in the operative articles [3]. “Machine-learning” appears once, also in recital 89. The word “algorithm” does not appear at all.

Both recital mentions point the same way, and it is the opposite direction from governance. Recital 51 says Member States “should encourage the use of any innovative technology, including artificial intelligence, the use of which could improve the detection and prevention of cyberattacks”. Recital 89 says entities “should evaluate their own cybersecurity capabilities and, where appropriate, pursue the integration of cybersecurity enhancing technologies, such as artificial intelligence or machine-learning systems” [3]. NIS2 treats AI as a defensive tool you might adopt, not as a risk you must govern.

Recitals are interpretive aids. They explain why the legislature wrote what it wrote; they do not create obligations, and no supervisory authority can enforce one. When the only two places NIS2 names AI are recitals, and both are encouragements, the directive has said nothing an auditor can hold you to.

The same holds one level down. Commission Implementing Regulation (EU) 2024/2690 is the binding technical rulebook that converts Article 21 into named controls for digital infrastructure and digital service entities. Across its full text, “artificial intelligence” appears zero times, “machine learning” zero, “AI system” zero [4]. The controls that do exist there are worth knowing — we have mapped them in 45 NIS2 technical controls every IT administrator must implement — but none is an AI clause.

So there is a practical test. If a consultant or certification body tells you NIS2 requires an AI management system, ask which article. There isn’t one.

What ISO 42001 Is, and What the European Commission Says It Is Not

ISO/IEC 42001, published in 2023, specifies requirements for establishing, implementing, maintaining and continually improving an Artificial Intelligence Management System — an AIMS. An AI management system is a set of interlocking organisational elements: policies, objectives, and the processes to reach them, covering the responsible development, provision or use of AI systems [9]. It follows the same Annex SL clause architecture as ISO 27001, which is why organisations that already run an ISMS find the shape familiar.

What it governs is the organisation. What the AI Act governs is the product [10]. That distinction is not a commentator’s opinion — it is the European Commission’s own reading. The Commission’s Joint Research Centre, in its policy brief on harmonised standards for the European AI Act, writes that existing international work “such as the ISO/IEC 42001 AI management system standard, while not aligned in objectives and approach with the AI Act, contain some relevant clauses at the technical and organizational levels” [5]. New AI quality-management standardisation, it adds, “should adopt a targeted focus on the specific risks addressed by the Regulation, as well as a product-centric view” [5].

Not aligned in objectives and approach. Some relevant clauses. An AIMS is a useful input to AI Act work and a poor substitute for it.

Why a 42001 Certificate Is Not an AI Act Shield

The AI Act has one mechanism for turning a standard into legal cover, and ISO 42001 does not go through it. Article 40(1) states that high-risk AI systems in conformity with harmonised standards “the references of which have been published in the Official Journal of the European Union in accordance with Regulation (EU) No 1025/2012 shall be presumed to be in conformity with the requirements set out in Section 2 of this Chapter” [1].

Two conditions do the work there, and both are strict: the standard must be a European harmonised standard developed under a Commission standardisation request, and its reference must actually be cited in the Official Journal. ISO 42001 is an international standard, not a harmonised European one, and it has not been cited [8].

What that costs you is the burden of proof. With a presumption of conformity, a market surveillance authority that thinks your system falls short has to demonstrate the shortfall. Without one, you demonstrate sufficiency yourself, requirement by requirement, from your own evidence. A certificate that does not move that burden is not a shield.

The standard being built to do that job is a different document. prEN 18286, the European quality-management standard for AI, is named by CEN and CENELEC as “one of the key deliverables supporting the future conformity-assessment framework under the AI Act” [6]. It is drafted to Article 17’s per-system logic rather than to organisational governance [7]. In October 2025, faced with repeated delays, CEN and CENELEC adopted exceptional acceleration measures — allowing direct publication of drafts without a separate Formal Vote after a positive Enquiry, and convening a small drafting group to finish six of the most delayed drafts — with the aim of having the standards available by Q4 2026 [6]. As a draft, prEN 18286 confers nothing yet; only an Official Journal citation would.

One nuance the certification debate usually skips: you never needed a standard. Article 17(1)(e) requires providers to document the technical specifications applied and, “where the relevant harmonised standards are not applied in full or do not cover all of the relevant requirements”, the means used to comply anyway [1]. Standards are the easy road, not the only one.

What Changed on 24 July 2026, and What Did Not

Most ISO 42001 cost and timeline guidance still on the web was written against an August 2026 deadline that no longer exists. Regulation (EU) 2026/1744, the Digital Omnibus on AI, was adopted on 8 July 2026 and published in the Official Journal on 24 July 2026. Its point (40) rewrites the third paragraph of AI Act Article 113 so that Chapter III, Sections 1, 2 and 3 now apply from “2 December 2027 as regards AI systems classified as high-risk pursuant to Article 6(2) and Annex III” and “2 August 2028 as regards AI systems classified as high-risk pursuant to Article 6(1) and Annex I” [2].

Chapter III Section 3 spans Articles 16 to 27. Both the provider’s Article 17 quality management system and the deployer’s Article 26 duties sit inside it [1]. The deferral therefore covers the entire obligation set that an AI management system is usually pitched against.

Obligation	Status after Regulation (EU) 2026/1744
High-risk requirements and provider/deployer duties, Annex III route	Moved to 2 December 2027
High-risk requirements and provider/deployer duties, Annex I route	Moved to 2 August 2028
New Article 5 prohibitions added by the Omnibus	Apply from 2 December 2026
Article 50(2) synthetic-content marking, for systems on the market before 2 August 2026	Apply from 2 December 2026 (new Article 111(4))
High-risk systems intended for use by public authorities, already on the market	Comply by 2 August 2030
All NIS2 obligations	Unchanged — fully applicable now

The recitals give the reason, and it is an unusually candid one: “the delayed availability of standards, common specifications, and alternative guidance and the delayed establishment of national competent authorities” jeopardised effective application and risked a significant increase in implementation costs [2]. In other words, the legislature deferred the deadline partly because the standards were not ready. Buying a certificate against a standard that is not the one being written is a strange response to that news.

The last row of that table is the one to take to the board. Nothing about NIS2 moved. If you want the sector-by-sector view of where the two regimes actually overlap, our NIS2 and EU AI Act dual compliance Annex III matrix sets it out.

Where AI Actually Lands Inside NIS2 Article 21

Here is the part that does apply today, and it applies whether or not you ever certify anything. An AI system you operate is a network and information system. Article 21(1) obliges essential and important entities to take “appropriate and proportionate technical, operational and organisational measures” on an all-hazards basis, “taking into account the state-of-the-art and, where applicable, relevant European and international standards, as well as the cost of implementation” [3]. That is a risk-based duty, not a checklist, which is precisely why it reaches AI without ever naming it.

So the work is not a new management system. It is extending the ten measures in Article 21(2) to a new class of asset. For CISOs and IT security managers, the gap analysis looks like this.

Article 21(2) measure	What changes when the asset is an AI system	Effort
(a) Risk analysis and information system security policies	Register models as assets with their own failure modes: drift, prompt injection, training-data poisoning, unsafe output. These do not appear in a conventional threat model.	Medium
(b) Incident handling	Little change in process. Decide in advance which AI failures count as incidents affecting service continuity, and who declares them.	Low
(d) Supply chain security	Your model vendor is a direct supplier. Article 21(3) requires you to take into account each supplier’s vulnerabilities and “their secure development procedures” — which for a general-purpose model provider is a hard question to answer.	Medium
(e) Acquisition, development and maintenance, including vulnerability handling	The heaviest item. Retraining and model updates are changes; most change-control processes have no gate for “the vendor silently updated the model”.	High
(g) Cyber hygiene and training	Rules on what data staff may put into a copilot, taught the same way phishing awareness is taught.	Low
(i) HR security, access control and asset management	Weights, prompts, fine-tuning data and API keys need a named owner and access control like any other asset.	Low

Note what this is not. NIS2 has no AI-specific requirement, so none of the rows above is an AI clause — each is an existing obligation meeting a new asset type, which is what a risk-based, all-hazards duty is designed to do. Our guide to NIS2 and the EU AI Act dual obligations goes deeper on the measure-by-measure overlap.

Three Honest Reasons to Certify, and One Bad One

Certification is a business decision with three legitimate drivers. Mixing them together is what produces the wrong answer.

Regulatory. Weak, for now. ISO 42001 is not harmonised, confers no presumption of conformity, is not what Article 17 is being standardised against, and is not mentioned anywhere in NIS2. If regulatory pressure is your only driver, the honest recommendation is to wait for prEN 18286 and spend the interval on evidence rather than on certificates.

Commercial. Often the real reason. If you sell AI-enabled services into regulated buyers, a certificate answers supplier questionnaires quickly and credibly. This is already visible in the market: Microsoft holds ISO 42001 certification across a named scope including GitHub Copilot, Microsoft 365 Copilot and Microsoft Foundry [9]. Note the limit Microsoft itself states — you are still “responsible for engaging an assessor to evaluate the controls and processes within your own organization” [9]. A supplier’s certificate is evidence for your supply-chain file under Article 21(2)(d); it does not transfer to you.

Internal control. Real if you are scaling fast. If AI is spreading across the business with no owner for model risk, ISO 42001 hands you a governance skeleton instead of inventing one — an AI policy, impact assessments, lifecycle controls, a review cadence. Organisations already certified to ISO 27001 inherit most of the surrounding machinery.

The bad reason: “NIS2 requires it.” It does not, in any article, in any implementing regulation. Any business case resting on that sentence is resting on nothing.

Role	What to do about ISO 42001 now
Compliance officer	Classify each AI system as deployer-side or provider-side, and against Annex III / Annex I. That classification, not a certificate, determines whether 2 December 2027 or 2 August 2028 is your date.
CISO / IT security manager	Extend the Article 21(2) measures to AI assets using the table above. This is due now, independent of any AI Act deadline.
Board / C-suite	Do not fund a certification programme on regulatory grounds alone. Fund it if procurement is losing deals without it, or if AI risk currently has no owner.
SME owner	If you only use AI tools rather than build them, you almost certainly need no AIMS. Document which tools you use, what data goes into them, and who is accountable.

Frequently Asked Questions

Does NIS2 require ISO 42001 certification?
No. NIS2 contains no AI management requirement. The directive mentions artificial intelligence three times, all in non-binding recitals, and Commission Implementing Regulation (EU) 2024/2690 does not mention it at all [3][4].

Will ISO 42001 give me a presumption of conformity under the AI Act?
Not as things stand. Article 40(1) grants that presumption only to harmonised standards whose references are published in the Official Journal, and ISO 42001 is not among them [1][8].

Has the AI Act high-risk deadline really moved?
Yes. Regulation (EU) 2026/1744 amended Article 113 so that Chapter III Sections 1 to 3 apply from 2 December 2027 for Annex III high-risk systems and 2 August 2028 for Annex I ones [2]. Article 5 prohibitions and the GPAI rules were not deferred.

Is ISO 42001 useless for AI Act preparation, then?
No, but it is an input rather than an answer. The JRC’s own assessment is that it is “not aligned in objectives and approach with the AI Act” while containing “some relevant clauses at the technical and organizational levels” [5]. Its lifecycle and impact-assessment clauses map onto real Article 17 topics; its organisational framing does not produce per-system technical files.

We already hold ISO 27001. Does that help?
Considerably, for both regimes. ISO 27001 carries most of the Article 21(2) machinery and the Annex SL structure that ISO 42001 reuses, which is why certified organisations report materially shorter AIMS implementations. It does not, however, address model-specific risks such as drift or training-data integrity.

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.

Sources

1. Regulation (EU) 2024/1689 (EU AI Act) — Articles 6, 15, 17, 26, 40, 113 — EUR-Lex
2. Regulation (EU) 2026/1744 (Digital Omnibus on AI), 8 July 2026 — EUR-Lex (linked above)
3. Directive (EU) 2022/2555 (NIS2) — Article 21, recitals 51 and 89 — EUR-Lex
4. Commission Implementing Regulation (EU) 2024/2690 — EUR-Lex
5. Harmonised Standards for the European AI Act, JRC139430 — European Commission Joint Research Centre (linked above)
6. Update on CEN and CENELEC’s Decision to Accelerate the Development of Standards for Artificial Intelligence — CEN-CENELEC (linked above)
7. EU AI Act Compliance: prEN 18286 and ISO 42001 — Cloud Security Alliance
8. Presumption of Conformity: Why ISO 42001 Isn’t Your AI Act Legal Shield Yet — ISMS.online
9. ISO/IEC 42001:2023 Artificial Intelligence Management System Standards — Microsoft Learn
10. Your ISO 42001 Certification Won’t Make Your AI System Compliant — Modulos