NIS2 and AI systems compliance for critical infrastructure

NIS2 (Directive (EU) 2022/2555) is a cybersecurity directive, not a regulation, which means it had to be transposed into national law by 17 October 2024. It covers 18 sectors split between Annex I (essential entities: energy, transport, banking, financial market infrastructure, health, drinking water, waste water, digital infrastructure, ICT service management, public administration, space) and Annex II (important entities: postal and courier, waste management, chemicals, food, manufacturing, digital providers, research). The size threshold for inclusion is 50 employees and EUR 10 million turnover, with mandatory inclusion regardless of size for several sub-sectors [1].

The headline differences from the original 2016 NIS Directive: dramatically wider scope (18 sectors vs 7), explicit supply-chain and third-party security requirements, harmonised incident-notification timelines, management-body accountability with personal liability for breaches, and a uniform framework of administrative fines (up to EUR 10 million or 2% of worldwide turnover for essential entities).

For the purposes of AI deployment, the key shift is that supply-chain risk-management is now an explicit Article 21 obligation, not a soft expectation. Any AI vendor or model provider whose service is used in production by a NIS2 entity is part of that entity's regulated supply chain.

Article 21(2) lists the ten cybersecurity risk-management measures that essential and important entities must implement. They are: (a) policies on risk analysis and information system security; (b) incident handling; (c) business continuity and crisis management including backup and disaster recovery; (d) supply-chain security including vulnerabilities and security of relationships with direct suppliers; (e) security in network and information systems acquisition, development and maintenance; (f) policies and procedures to assess effectiveness of risk-management measures; (g) basic cyber hygiene practices and training; (h) cryptography and encryption policies; (i) human resources security, access control and asset management; (j) multi-factor authentication, secured voice/video/text and emergency communications.

For AI systems, measure (e) on secure development and (d) on supply-chain security do most of the work. Secure development means the AI lifecycle (data sourcing, training, validation, deployment, monitoring) has to be governed by documented security controls. Supply-chain security means an entity using a third-party model provider, hosted inference platform or AI consultancy must perform vendor due diligence, capture the dependency in its risk register and treat the upstream provider as part of its threat surface.

ENISA has published successive iterations of its threat landscape and AI cybersecurity guidance, and the 2023 "Multilayer Framework for Good Cybersecurity Practices for AI" provides a practical template for mapping NIS2 measures onto AI deployments [2].

Article 23 sets a three-stage incident notification timeline. An "early warning" must be submitted to the CSIRT or competent authority within 24 hours of becoming aware of a significant incident. An "incident notification" with an initial assessment must follow within 72 hours. A "final report" with root-cause analysis, mitigation measures and cross-border impact must be filed within one month. Significant intermediate updates are permitted between stages.

An incident is "significant" when it has caused or is capable of causing severe operational disruption or financial losses, or when it has affected or is capable of affecting other natural or legal persons by causing material or non-material damage. AI failures - a model serving incorrect outputs at scale, a training-data poisoning event affecting decisions in production, a prompt-injection vulnerability that exfiltrates customer data - fall squarely inside this definition when they affect a service in scope.

The implementing regulation on significance criteria, adopted in 2024, refines the thresholds for digital infrastructure and ICT service management entities specifically. Buyers of AI services should require incident-cooperation clauses in vendor contracts that flow through the same 24/72-hour rhythm, since the entity remains responsible for meeting the deadline regardless of where in the supply chain the incident originated.

Member states had until 17 October 2024 to transpose NIS2. By the deadline, only a minority of member states had completed transposition; the European Commission opened infringement proceedings against the majority. Belgium, Italy, Hungary, Croatia, Slovakia and Lithuania were among the early movers. Germany, France, Spain, the Netherlands and Poland completed transposition in waves through late 2024 and the first half of 2025 [3].

National transposition matters because NIS2 is a directive, not a regulation: the operative obligations live in the national implementing law, and member states had discretion on certain elements (size thresholds for sub-sectors, fines structure, supervisory authority assignment, sector-specific guidance). Multinational essential entities therefore face a matrix of slightly differing rules across the member states where they operate, and AI vendors selling cross-border have to map their contracts to the strictest member-state regime in scope.

The Cooperation Group of national NIS authorities, supported by ENISA, publishes guidance to harmonise interpretation. The 2024 Cooperation Group reference document on supply-chain security is the key cross-reference for AI vendor onboarding, since it explicitly addresses third-party software and AI components.

NIS2 is the horizontal cybersecurity baseline. DORA is lex specialis for the financial sector and overrides NIS2 on the same matters under DORA Article 1(2). The EU AI Act (Regulation 2024/1689) governs AI-specific properties (risk classification, training data, transparency, human oversight, accuracy under Article 15). The Cyber Resilience Act (Regulation 2024/2847) governs the security of products with digital elements placed on the market, including AI components shipped as products [5].

For an essential entity using a high-risk AI system, the practical stack is: NIS2 governs the entity-level cybersecurity programme; AI Act Article 15 imposes accuracy, robustness and cybersecurity obligations on the AI system itself; CRA imposes essential cybersecurity requirements on the AI product as placed on the market. The three regimes were drafted to be complementary, but they generate parallel documentation streams that mature compliance programmes consolidate into a single evidence base.

Impetora's TRACE methodology is built around AI systems that have to survive cybersecurity audits in regulated infrastructure. Trust covers the policy and contractual layer including supply-chain disclosure, sub-processor controls and incident-cooperation clauses that match the 24/72-hour rhythm. Readiness covers the workflow and data audit that becomes the input to the entity's NIS2 risk register. Architecture covers production-grade design with logging, monitoring, encryption, access control and recoverability that map directly onto Article 21's ten measures. Citations and Evidence covers the audit-trail layer that supervisory authorities and CSIRTs can request post-incident.

The practical path for a NIS2-bound engagement: scope the AI system against the entity's existing cybersecurity policy, document the supply chain explicitly (model provider, hosting, sub-processors), align the secure-development lifecycle with measure (e), and structure runbooks that meet Article 23 notification windows.