NIS2 + EU AI Act Dual Compliance: The Annex III Sector Matrix That Shows Which Article 21 Controls Cover Both Regulations

Two EU regulations now govern how you design, deploy, and secure AI systems in critical infrastructure — and they use different vocabularies, different timelines, and different enforcement bodies. The compliance question most teams have not yet answered: which of your existing NIS2 Article 21 controls already satisfy EU AI Act requirements, and what new obligations remain?

This guide focuses on the intersection that matters most: organisations covered by NIS2 that deploy AI systems falling under EU AI Act Annex III. If you operate an energy grid using AI for stability control, a hospital using AI for patient triage, or a digital infrastructure provider using AI-driven anomaly detection, you sit at that intersection. Both regimes apply simultaneously — with different risk management requirements, different incident notification timelines, and a supply chain due diligence framework that now extends to your AI model provider.

Three angles competitors are not covering: the Annex III × NIS2 sector matrix that tells you exactly where both regulations collide for your organisation, the general-purpose AI (GPAI) model supply chain framework under NIS2 Article 21(2)(d), and adversarial AI as a distinct risk category that most NIS2 risk registers do not yet include.

Note on enforcement timelines: The Digital Omnibus agreement of 7 May 2026 postponed the Annex III substantive high-risk AI obligations from 2 August 2026 to 2 December 2027 [1]. GPAI provider obligations and Article 73 serious-incident reporting for high-risk AI systems already in use remain applicable from 2 August 2026. The analysis below covers both the immediate (GPAI + Art.73) and the approaching (Annex III core) obligations.

Who Faces Both Regimes: The Annex III × NIS2 Sector Matrix

Not every AI system deployed by a NIS2 entity is automatically subject to EU AI Act high-risk requirements. The trigger is whether the AI falls into one of the eight Annex III categories. Three of those categories create the highest intersection risk for NIS2-covered organisations.

Category 2 is the most direct: it 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” [2]. An energy grid operator using AI for load balancing or fault detection faces Annex III Category 2 — and because that operator is also an essential entity under NIS2 Annex I §1, both regulations apply in full. The AI Act governs the AI system itself; NIS2 governs the entity’s security posture.

The derogation in Article 6(2) matters [3]: a system listed in Annex III is not automatically high-risk if it performs only a narrow procedural task, improves the result of a previously completed human activity, detects deviations without replacing human decisions, or performs a preparatory task. However, the derogation is excluded where a system profiles natural persons — and for AI that takes autonomous protective actions (load shedding, fault isolation, emergency dispatch routing), the derogation does not apply.

Annex III Category	High-Risk AI Examples in Critical Infrastructure	NIS2 Annex I Sector	Entity Type
Cat.2 — Critical infrastructure safety components	Grid stability AI; water treatment anomaly detection; road traffic management	Energy (§1); Transport (§2); Water supply (§6); Wastewater (§7)	Essential
Cat.2 — Digital infrastructure safety components	AI-driven DDoS mitigation in cloud/CDN; network routing optimisation in IXPs	Digital infrastructure (§8); ICT service management (§9)	Essential
Cat.5 — Emergency dispatch priority	AI call classification for emergency services; patient triage routing	Health (§5); Public administration (§10)	Essential
Cat.4 — Employment and workforce management	AI-driven staff scheduling or performance evaluation in critical sectors	Health (§5); Energy (§1) — where HR continuity affects operations	Essential / Important
Cat.6 — Law enforcement risk assessment	Criminal risk scoring or suspect profiling AI used in public administration	Public administration (§10)	Essential
Cat.1 — Remote biometric identification	Biometric access control to critical facility perimeters (plant, data centre)	Energy (§1); Banking (§3); Digital infrastructure (§8)	Essential

Size threshold note: NIS2 uses 50 employees / €10M turnover for important entities and 250 / €50M for essential entities as general thresholds — but critical infrastructure operators are frequently designated Essential regardless of size under Art.3(1)(b)-(e). The EU AI Act applies to any Annex III deployer irrespective of entity size. The dual threshold rarely creates an exclusion in practice for NIS2-covered operators.

Organisations in NIS2 Annex II important sectors — manufacturing (§5), digital providers (§6), food production (§4) — face the intersection primarily through Category 4 (employment AI) and, for digital providers, Category 5 (credit-scoring, insurance risk). They face the same dual compliance logic as Annex I operators, but at Important entity supervision levels.

Five Article 21 Controls That Do Double Duty

Five of NIS2’s ten mandatory measures map directly to EU AI Act deployer obligations — meaning evidence generated for NIS2 compliance can, with targeted extensions, satisfy the parallel AI Act requirement. The mapping is not one-to-one: each framework’s output document must stand independently for its own regulator. What the five controls share is control logic — the same governance process can generate both outputs without building two separate programmes from scratch.

1. Art.21(2)(a) risk analysis ↔ AI Act Art.9 risk management. NIS2 requires documented policies on risk analysis and information system security. The AI Act requires a “continuous iterative process” for identifying foreseeable risks to health, safety, or fundamental rights and assessing reasonably foreseeable misuse [4]. A single risk management procedure can generate both outputs — the NIS2 risk register (IT/OT threats, business impact) and an AI system risk log (accuracy degradation, fundamental rights exposure, adversarial attacks) — provided the procedure explicitly covers AI-specific threat vectors. Critically, these two output documents must address different audiences: the NIS2 risk register goes to your NCA and auditors; the AI Act risk log goes to market surveillance authorities. Do not cross-reference one as a substitute for the other.

2. Art.21(2)(d) supply chain security ↔ AI Act Art.26(1) + provider documentation. Supply chain security under NIS2 already requires assessing direct suppliers for security vulnerabilities and quality of cybersecurity practices [8]. When that supplier is an AI system provider, the Art.21(2)(d) assessment must extend to the provider’s AI documentation — including the technical documentation and training data summary GPAI providers are required to publish [10]. See Section 3 for the full GPAI due-diligence framework. Internal link: supply chain security under NIS2.

3. Art.21(2)(e) acquisition and development ↔ AI Act Art.15 cybersecurity. NIS2 Article 21(2)(e) covers security in network and information systems acquisition, development, and maintenance. The AI Act’s Article 15 requires high-risk AI to be resilient against data poisoning, model poisoning, adversarial examples, confidentiality attacks, and model flaws [5]. Your secure development policy (Art.21(2)(e)) should already cover input validation and change management — extending it to include the Art.15 threat taxonomy closes both requirements simultaneously. The shared control is input integrity: validate that data entering your AI pipeline meets the same standards as data entering your IT systems.

4. Art.21(2)(b) incident handling ↔ AI Act Art.26(5) + Art.73. NIS2 incident handling and the AI Act’s incident notification obligations share the same triggering event but operate on different timelines and different notification authorities. Your Art.21(2)(b) incident handling procedure must be extended to include a dual-authority notification step — see Section 5 for the full triage protocol.

5. Art.21(2)(i) access control and asset management ↔ AI Act Art.26(2) human oversight. The AI Act requires deployers to assign oversight of high-risk AI to a natural person who has “the necessary competence, authority and resources” [6]. Your HR security and access control documentation (Art.21(2)(i)) already defines role assignments — extending this documentation to name the AI oversight designee and their competency criteria satisfies the Art.26(2) obligation. The additional step: the oversight role must be empowered to halt the AI system, which must be reflected in your access control policy.

NIS2 Art.21(2) Control	EU AI Act Parallel	Shared Evidence Zone	Separate Documentation Required
(a) Risk analysis	Art.9 risk management system	Risk management procedure, risk register methodology	Separate Art.9 AI system risk log (different scope and audience)
(d) Supply chain security	Art.26(1) use per instructions + provider compliance	Supplier assessment process, supplier questionnaire	GPAI-specific fields: training provenance, model update notification
(e) Acquisition, dev & maintenance	Art.15 robustness and cybersecurity; Art.26(4) input data quality	Secure development policy, input validation controls	Art.15 AI-specific threat taxonomy in scope statement
(b) Incident handling	Art.26(5) incident notification to provider; Art.73 serious incident reporting	Incident classification procedure, severity tiers	Dual-authority notification: NCA/CSIRT (NIS2) + market surveillance authority (AI Act)
(i) Access control & asset management	Art.26(2) human oversight role	Role matrix, access control policy	AI oversight designee with explicit halt authority documented

GPAI Models as Article 21(2)(d) Suppliers: The Due Diligence Framework

When a NIS2-covered entity integrates a general-purpose AI model — GPT-series, Claude, Mistral, Llama — into its operations, that provider becomes a direct supplier under Article 21(2)(d). The supply chain security obligation applies immediately: you must assess “the vulnerabilities specific to each direct supplier and the overall quality of products and cybersecurity practices” of that supplier [8]. Most GPAI integrations predate any formal supplier assessment — this section gives you the framework to close that gap.

The EU AI Act creates a two-tier disclosure structure that feeds your Art.21(2)(d) due diligence. All GPAI providers must publish technical documentation, a copyright policy, and a training content summary [10]. This is the minimum evidence floor available for any NIS2 supplier assessment involving a commercially available GPAI model. For systemic-risk models — those trained with more than 10²&sup5; floating-point operations — providers must additionally conduct model evaluations, implement cybersecurity protections, report serious incidents to the Commission, and disclose energy consumption. Major systemic-risk models are listed on the EU AI Office registry.

For NIS2 deployers, a systemic-risk GPAI supplier creates a contractual obligation opportunity: you should require the provider to notify you as deployer when they submit an Art.73 serious-incident notification, since Art.73 explicitly names deployer awareness as a reporting trigger [7]. Your supplier security clauses should include this notification commitment.

The practical GPAI due-diligence framework breaks into three steps:

Step 1 — Classify the GPAI model. Systemic risk (>10²&sup5; FLOP) vs non-systemic. For systemic-risk models, the EU AI Office registry is your starting point. For non-systemic models — the majority of commercially available models — publicly available technical documentation and published training data summaries are your primary evidence sources for the Art.21(2)(d) assessment.

Step 2 — Extend your supplier security questionnaire. Your existing Art.21(2)(d) supplier questionnaire should add four GPAI-specific fields: (i) training data provenance and data governance documentation; (ii) model update and retraining notification procedure — when the provider updates or fine-tunes the model, does your deployed version change?; (iii) incident reporting commitment — will the provider notify you as deployer when they become aware of a serious incident involving the model?; (iv) sub-contracting disclosure — does the provider use third-party infrastructure for inference or fine-tuning?

Step 3 — Map each integration to affected Art.21 domains. A GPAI model used for access-control decisions touches Art.21(2)(i). A GPAI model used in incident triage touches Art.21(2)(b). A GPAI model used to draft security policies touches Art.21(2)(a). Each integration point needs a separate risk entry in your risk register naming the GPAI model as a distinct threat surface — and a separate Art.21(2)(d) supplier entry in your supplier directory. Combining all GPAI providers into a single “AI vendors” category does not satisfy the “vulnerabilities specific to each direct supplier” requirement [8]. Internal link: see NIS2 risk assessment methodology for proportionality guidance.

Adversarial AI: The New NIS2 Risk Category Nobody Is Registering

Article 21(2)(a) requires entities to maintain policies on risk analysis covering their exposure to threats across an all-hazards approach. Most NIS2 risk registers include phishing, ransomware, DDoS, and insider threats. Few yet include adversarial AI attacks — despite these being the threat vectors that directly target AI systems in your environment and constituting cybersecurity attacks under NIS2’s scope.

The EU AI Act’s Article 15 names the adversarial threat taxonomy explicitly [5]. Each category maps to specific NIS2 control obligations:

Data poisoning corrupts training datasets to degrade model accuracy or embed hidden behaviours. The Cloud Security Alliance classifies data poisoning as creating “digital sleeper agents” — models that behave correctly under normal conditions until triggered by an adversarially crafted input [11]. For a NIS2 entity that fine-tunes a model on internal operational data (customer transaction patterns, network traffic baselines, clinical records), data poisoning is simultaneously a supply chain threat (Art.21(2)(d) — who provided the base model and with what training data provenance?) and a development security issue (Art.21(2)(e) — what validation process governs fine-tuning data?). Your risk register entry should classify this as a Tier 1 asset risk where the affected AI system has operational control functions.

Prompt injection is the number one risk on OWASP’s Top 10 for LLM Applications 2025, present in over 73% of production AI deployments assessed [12]. Direct prompt injection manipulates model outputs through adversarially crafted user inputs; indirect prompt injection embeds malicious instructions in external content the AI processes — documents, emails, web pages the system retrieves autonomously. For a hospital using an LLM to triage patient severity, a successful indirect prompt injection that systematically deprioritises a class of patients creates not only patient safety harm but a likely NIS2 Art.23 incident: severe operational disruption to a health essential entity. Your Art.21(2)(b) incident handling procedure must classify prompt injection attacks as a distinct incident category with dedicated detection and response steps.

Model poisoning compromises pre-trained model components before integration — typically through compromised model weights in the supply chain. This creates Art.21(2)(d) obligations: your supplier security clauses must require notification if a provider discovers their model was manipulated post-training. Model poisoning is operationally silent until triggered, which is why conventional monitoring (anomaly detection on IT traffic) will not catch it. Behavioural consistency testing — comparing model outputs against a clean baseline on a fixed evaluation set — is the detective control.

Adversarial perturbations cause misclassification through imperceptible input modifications. For critical infrastructure AI — an anomaly detection model in a power grid, a vision system monitoring a water treatment facility — adversarial perturbations that suppress genuine fault signals create incident exposure without generating a detectable attack signature. Your Art.21(2)(a) risk analysis should assess whether the AI system’s inputs are controllable by an adversary, and your Art.21(2)(e) secure development policy should specify adversarial testing (red-teaming) as a mandatory step before production deployment of any AI system with operational control functions.

The risk register entry format follows the existing Art.21(1) proportionality framework: threat likelihood × impact × current control effectiveness. For healthcare entities using AI triage: prompt injection rated high likelihood (proven in >73% of production deployments [12]), critical impact (patient safety + Art.23 reporting trigger), existing control effectiveness low if only standard access controls are in place — resulting risk rating is Critical, requiring dedicated detection controls before deployment.

Incident Notification — Running Two Clocks at Once

When an incident involves a high-risk AI system operated by a NIS2-covered entity, two notification obligations potentially trigger simultaneously — with different timelines, different authorities, and different trigger criteria. Understanding the interaction before an incident occurs is the only way to avoid a missed deadline under one or both frameworks.

NIS2 Article 23 requires an early warning within 24 hours of becoming aware of a significant incident — one causing or capable of causing severe operational disruption, financial loss, or significant harm [8]. The AI Act’s Article 73 requires providers (and deployers where applicable) to notify market surveillance authorities of serious incidents: within 15 days standard, 10 days where death may have occurred, 2 days for widespread infringement or serious and irreversible disruption of critical infrastructure [7]. The 2-day accelerated track applies precisely to the same events that trigger NIS2 Art.23 — which means the 24-hour NIS2 clock runs first.

Your incident handling policy must reflect this triage sequence. The practical dual-clock protocol:

1. Hours 0–1 (Detection): Determine whether the triggering event involves an AI system in scope. If yes, dual-reportable status is possible — assign a dedicated triage officer.
2. Hours 1–4 (Classification): Assess NIS2 significance (severe operational disruption, financial loss, or societal harm at threshold). Assess AI Act seriousness (harm to health, safety, fundamental rights, or critical infrastructure disruption per Art.3(49) definition).
3. Hours 4–24 (NIS2 Early Warning): Submit Art.23(4) early warning to your NCA/CSIRT. You may submit an incomplete initial notification — confirm AI system involvement and operational impact, even if root cause is unknown.
4. Hours 24–48 (AI Act accelerated track, if applicable): If the incident meets the Art.73(2)(a) critical infrastructure disruption threshold, submit initial notification to the relevant market surveillance authority. Partial reports are permitted [7].
5. Day 2–15 (AI Act standard track): For serious incidents not triggering the accelerated threshold, complete Art.73 notification within 15 days.
6. Day 30+ (NIS2 final report): Art.23 final report due within one month, with extension available in specific circumstances.

The deployer’s role in Art.73 is explicit: the notification obligation triggers when “the provider or, where applicable, the deployer, becomes aware” of the serious incident [7]. Your incident handling policy must name the market surveillance authority for your jurisdiction as a second reporting destination alongside your NCA/CSIRT. Internal link: see NIS2 Article 23 incident notification for the standard NIS2 reporting procedure your dual-clock protocol extends.

What Article 21 Cannot Cover: The AI-Act-Only Zone

Three EU AI Act obligations for Annex III deployers have no NIS2 equivalent and require standalone documentation that no Art.21 template substitutes for:

Fundamental Rights Impact Assessment (Art.27 FRIA). Required for public authorities, private entities providing public services, and deployers of Annex III §5(b)/(c) high-risk systems. The FRIA must document affected population groups, fundamental rights risks, human oversight measures, and mitigation steps. A GDPR Data Protection Impact Assessment (DPIA) partially overlaps but does not satisfy the FRIA requirement independently. Both documents are required where both GDPR and the AI Act apply.

Worker notification (Art.26(7)). Before deploying AI systems that monitor or evaluate employee performance at the workplace, deployers must inform workers and their representatives. This is a distinct transparency obligation with no NIS2 counterpart. It applies to many AI deployments in healthcare (AI performance monitoring for clinical staff) and manufacturing (AI-driven production efficiency monitoring of workers).

Log retention (Art.26(6)). High-risk AI deployers must retain automatically generated logs for at least six months “where it is within their control to do so” [6]. NIS2 does not specify a minimum log retention period tied to AI system audit trails. Your NIS2 logging policy likely specifies 12 months or more for cybersecurity monitoring logs, which satisfies the AI Act floor — but the documentation purpose must be explicit: AI system audit trail logs (AI Act) and security event logs (NIS2) serve different regulatory purposes and must be labelled accordingly in your log management policy.

Frequently Asked Questions

Does the EU AI Act replace or supersede NIS2 compliance for AI systems in critical infrastructure?
No. The two frameworks apply independently to their respective subject matter. DORA is the only regulation currently listed as lex specialis displacing NIS2 for specific financial-sector entities. For Annex III AI systems operated by NIS2-covered entities, both regimes apply in full — you cannot substitute one framework’s compliance documentation for the other’s.

If our GPAI model provider already holds ISO 27001, does that satisfy the Art.21(2)(d) supplier assessment?
An ISO 27001 certificate is one evidence input to your supplier assessment — not a complete substitute. Article 21(2)(d) requires assessment of “the overall quality of products and cybersecurity practices,” which includes the provider’s incident notification commitments, sub-contracting disclosure, and AI-specific risks that ISO 27001 scope does not necessarily cover [8]. Request the GPAI technical documentation and training data summary as primary evidence alongside any certification.

When do the core Annex III obligations (Art.9-17 providers, Art.26 deployers) actually take effect following the Digital Omnibus delay?
The Digital Omnibus agreement moved the Annex III substantive obligations to 2 December 2027 — a 16-month extension from the original August 2026 date [1]. GPAI provider obligations and Art.73 serious-incident reporting remain applicable from 2 August 2026 for AI systems already in use. The delay applies to the Annex III core requirements but not to incident notification obligations once a system is deployed.

Does a NIS2 Art.23 early warning satisfy the Art.73 AI Act notification obligation?
No. The two notifications go to different authorities — your NCA/CSIRT (NIS2) and the relevant national market surveillance authority (AI Act). A single submission to one does not discharge the obligation to the other. Your incident handling procedure must name both authorities and include both template notifications.

Conclusion

NIS2 Article 21 and EU AI Act Annex III compliance converge at five control points — risk analysis, supply chain security, secure development, incident handling, and access control. Your existing NIS2 control set is the strongest foundation available for dual compliance, but it requires three specific extensions: a GPAI supplier due diligence protocol covering training provenance and incident notification commitments, adversarial AI risk register entries for data poisoning, prompt injection, model poisoning, and adversarial perturbations, and a dual-clock incident notification procedure naming both the NCA/CSIRT and market surveillance authority. The AI-Act-only zone — the FRIA, worker notification, and AI log retention purpose-labelling — requires standalone documentation that no Art.21 template can substitute for. Starting from your NIS2 control set is correct; assuming it covers the full picture is where most dual compliance programmes fail.

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. Travers Smith: EU agrees to delay key AI Act compliance deadlines — Digital Omnibus postponement to 2 December 2027
2. EU AI Act: Annex III High-Risk AI Systems — eight categories including Cat.2 critical infrastructure safety components
3. EU AI Act: Article 6 — Classification Rules — Annex III auto high-risk, four derogations
4. EU AI Act: Article 9 — Risk Management System — continuous iterative process, lifecycle scope
5. EU AI Act: Article 15 — Accuracy, Robustness and Cybersecurity — data poisoning, model poisoning, adversarial examples
6. EU AI Act: Article 26 — Deployer Obligations — human oversight, log retention, worker notification
7. EU AI Act: Article 73 — Reporting of Serious Incidents — 15/10/2-day timelines, deployer awareness trigger
8. NIS2 Directive, Article 21: Cybersecurity risk-management measures — ten mandatory measures, proportionality standard
9. EUR-Lex: Directive (EU) 2022/2555 — NIS2 primary text including Annex I/II sector definitions
10. European Commission: General-Purpose AI Obligations Under the AI Act — GPAI transparency requirements, systemic risk threshold
11. Cloud Security Alliance: AI Security Threats: Prompt Injection & Model Poisoning
12. OWASP Gen AI Security Project: LLM01:2025 Prompt Injection — #1 LLM risk, >73% of deployments
13. ENISA: NIS2 Technical Implementation Guidance — June 2025, Art.21 evidence examples