EU / European Union / revised 28 Oct 2026

NIS2 and AI Infrastructure: Article 21 Measures for Inference

NIS2 is a cybersecurity directive, not a data residency law. It matters for AI inference because an LLM integrated into an essential service becomes part of that service's network and information systems, and the model provider and gateway become suppliers whose risk the entity must manage under Article 21.

Test a sovereign route Talk to a sovereign architect

Citation: Directive (EU) 2022/2555 (NIS2), Articles 20, 21, 23 and 34; Commission Implementing Regulation (EU) 2024/2690
Regulator: National competent authorities and CSIRTs designated by each Member State (for example BSI in Germany, ANSSI in France)
In force: 16 January 2023; Member State transposition deadline 17 October 2024
Maximum penalty: Essential entities: at least EUR 10 million or 2% of worldwide annual turnover; important entities: at least EUR 7 million or 1.4%, whichever is higher (Art. 34)

Statutory text

Scope: essential and important entities

NIS2 covers medium and large entities in the sectors listed in Annexes I and II, with some entities in scope regardless of size. Annex I includes energy, transport, banking, financial market infrastructure, health, drinking water, digital infrastructure (including cloud computing service providers, data centre service providers and trust service providers), ICT service management (managed service and managed security service providers), and public administration. Member States had to transpose the Directive by 17 October 2024 and apply the measures from 18 October 2024; several transposed late.

Article 21: cybersecurity risk-management measures

Article 21(1) requires appropriate and proportionate technical, operational and organisational measures based on an all-hazards approach. Article 21(2) lists the minimum measures, and Article 21(3) requires entities to take into account the vulnerabilities specific to each direct supplier and the overall quality of their products and secure development practices. Implementing Regulation (EU) 2024/2690 details the requirements for digital infrastructure and ICT service providers.

Risk analysis and information system security policies
Incident handling, business continuity, backup management and crisis management
Supply chain security, including security aspects of relationships with direct suppliers
Security in acquisition, development and maintenance, including vulnerability handling
Assessment of the effectiveness of measures, cyber hygiene and training
Cryptography and encryption policies, HR security, access control and asset management
Multi-factor authentication and secured communications where appropriate

Governance, reporting and fines

Article 20 requires management bodies to approve the risk-management measures, oversee their implementation, follow training, and makes them liable for infringements. Article 23 sets reporting for significant incidents: an early warning within 24 hours, an incident notification within 72 hours, and a final report within one month. Article 34 sets the fine ceilings, and national laws may add personal measures against managers of essential entities.

Technical requirements for the inference path

01
Treat the model provider as a direct supplier
An LLM endpoint in a clinical, grid or payment workflow is part of the service. Record it in the supplier register with its security posture, region, retention terms and incident contact, as Article 21(3) expects.
02
Continuity without jurisdiction drift
Business continuity requires failover, but uncontrolled failover to another continent may breach GDPR Chapter V or sector rules. Design pre-approved failover pairs inside the same jurisdiction and test them on a schedule.
03
Incident clocks start at the gateway
The 24-hour early warning runs from awareness. Gateway telemetry that flags provider outages, anomalous egress or policy-denial spikes gives the security team the facts they need to decide significance quickly.
04
Cryptography policy coverage
Extend the cryptography policy to inference traffic: TLS 1.3 to providers, certificate pinning or thumbprint recording, and signing keys for evidence stored in an HSM.
05
MFA and access control on the policy plane
Whoever can change a routing policy can redirect regulated traffic. Require SSO with MFA for policy edits, separate approvers from authors, and log every change.

Prescribed YTT Secunet routing rules

#	Rule	Legal rationale
01	Fail over only to pre-registered endpoints within the same jurisdiction; fail closed otherwise.	Satisfies continuity planning under Article 21(2)(c) without creating an unplanned transfer during an incident.
02	Record the upstream TLS certificate thumbprint for each request.	Supports the cryptography policy and lets incident responders detect interception or misrouting after the fact.
03	Emit a high-severity event when a provider's error rate or latency breaches the tenant threshold for five minutes.	Gives the incident team an early signal for the 24-hour early warning decision.
04	Reject requests to providers absent from the tenant's supplier register.	Makes supply chain security under Article 21(2)(d) enforceable at runtime rather than only in procurement.

Policy pack excerpt

eu-nis2-supply-chain

The rules above, written as Open Policy Agent Rego (v1 syntax). The gateway evaluates the pack in-process in every regional data plane before forwarding a request; YTT Secunet measures median evaluation under 3 ms in production.

Packs are versioned and signed. The version that decided each request is named in the residency receipt, so an auditor can match the decision to this exact text.

How the policy engine works

regoeu-nis2-supply-chain.rego

package yttsecunet.policies.eu_nis2_supply_chain

import rego.v1

default allow := false

allow if {
	supplier := data.tenant.supplier_register[input.route.provider_id]
	supplier.risk_assessed
	input.route.tls_version == "1.3"
	input.route.jurisdiction == input.request.jurisdiction
}

reasons contains "provider not in supplier register" if {
	not data.tenant.supplier_register[input.route.provider_id]
}

reasons contains "failover crosses jurisdiction" if {
	input.route.is_failover
	input.route.jurisdiction != input.request.jurisdiction
}

Audit checklist

Each item is verifiable against configuration, signed receipts or contract records. Tick through it with your DPO.

01The entity has confirmed whether it is essential or important under the national transposition law in each Member State where it operates.
02Every AI model provider and gateway appears in the supplier register with a dated risk assessment.
03Management has formally approved the risk-management measures covering AI systems (Art. 20).
04Failover pairs for inference endpoints are documented, kept within one jurisdiction and tested at least annually.
05The incident runbook maps AI provider outages and data exposure to the 24-hour, 72-hour and one-month reporting steps.
06Policy-plane access requires MFA and separates authors from approvers.
07Encryption policy covers inference traffic and evidence signing keys.

NIS2 Directive: frequently asked questions

Does NIS2 require EU hosting of AI models?

No. NIS2 has no localisation rule. It requires risk management of suppliers, and a regulator may question a design whose resilience depends on a single offshore endpoint, but the hosting location itself is not mandated.

Is an AI gateway provider itself in scope of NIS2?

Possibly, depending on size and whether it qualifies as a managed service provider or cloud computing service. Customers should assess it as a supplier either way.

How does NIS2 interact with DORA for banks?

DORA is the sector-specific act for financial entities and takes precedence where it applies. See the DORA guide for ICT third-party risk in banking AI.

Sovereign route ready

Stop risking 4% global turnover GDPR fines on AI inference.

Deploy sovereign, cryptographically proven AI routing in 15 minutes.

Schedule an architecture demo Start 14-day trial