What is NIS2 and what does it require from infrastructure teams?
NIS2, Directive (EU) 2022/2555, is the EU law that sets cybersecurity obligations for medium and large organizations in 18 sectors, including cloud computing, data centres and managed IT services. It requires ten groups of risk management measures, an early warning to the authorities within 24 hours of a significant incident, and accountable management, with fines of up to EUR 10 million or 2% of worldwide turnover. Member states had to transpose it by 17 October 2024; Germany’s implementing law has applied since 6 December 2025.
Who is in scope
NIS2 covers entities in 11 sectors of high criticality (Annex I) and 7 other critical sectors (Annex II). In general it applies to medium-sized and large enterprises, meaning 50 or more employees or more than EUR 10 million in annual turnover and balance sheet. Some providers, such as DNS service providers, top-level domain registries and trust service providers, are covered regardless of size.
For infrastructure teams, two Annex I sectors matter most:
- Digital infrastructure: cloud computing service providers, data centre service providers, content delivery networks, internet exchange points, DNS and trust services.
- ICT service management (business to business): managed service providers and managed security service providers.
Entities are either essential or important:
| Essential entities | Important entities | |
|---|---|---|
| Typical profile | Large enterprises in Annex I sectors, plus some providers regardless of size | Other in-scope entities in Annex I and II sectors |
| Supervision | Proactive: audits and inspections without a prior incident | Reactive: after evidence of non-compliance |
| Maximum fine (Art. 34) | EUR 10 million or 2% of total worldwide annual turnover, whichever is higher | EUR 7 million or 1.4% of total worldwide annual turnover, whichever is higher |
Article 20 makes management bodies approve the risk management measures, oversee their implementation and take cybersecurity training. They can be held liable for infringements.
What Article 21 means for platform work
Article 21(2) lists the measures every entity must take. Translated into platform engineering terms:
| Article 21(2) measure | Typical platform work |
|---|---|
| (a) Risk analysis and security policies | Threat models for clusters, documented security baselines |
| (b) Incident handling | Alerting, on-call, runbooks, audit logs that survive an incident |
| (c) Business continuity, backups, disaster recovery | Tested restores of etcd, databases and volumes; a second region or provider |
| (d) Supply chain security | Risk assessment of cloud, Kubernetes and SaaS providers; image provenance and signing |
| (e) Security in acquisition, development and maintenance, including vulnerability handling | Image scanning, patch windows, Kubernetes version upgrades |
| (f) Assessing effectiveness of measures | Policy-as-code checks, penetration tests, internal audits |
| (g) Cyber hygiene and training | Hardened defaults, training for engineers with production access |
| (h) Cryptography and encryption | TLS everywhere, encryption at rest, key management |
| (i) Human resources security, access control, asset management | RBAC, joiner and leaver processes, inventory of clusters and nodes |
| (j) Multi-factor authentication and secured communications | MFA and SSO for consoles, the Kubernetes API and emergency channels |
For cloud, data centre and managed service providers themselves, Commission Implementing Regulation (EU) 2024/2690 sets out these measures in technical detail and defines when an incident counts as significant. Access control in Kubernetes is covered in what is Kubernetes RBAC, and continuity across regions in how to make Kubernetes highly available across clusters.
Incident reporting deadlines
Article 23 sets a staged timeline for significant incidents:
- Within 24 hours of becoming aware: an early warning to the CSIRT or competent authority, saying whether the incident may be caused by unlawful or malicious acts or have a cross-border impact.
- Within 72 hours: an incident notification with an initial assessment of severity and impact, and indicators of compromise where available.
- On request: intermediate status reports.
- Within one month of the notification: a final report with the root cause and mitigation measures applied.
Meeting the 24-hour deadline depends on infrastructure that detects incidents and keeps logs your team can actually read, including logs from providers.
Does NIS2 require EU data residency?
No. NIS2 does not specify where data must be stored or which providers you may use. It does require you to assess supply chain risk: Article 21(3) asks entities to take into account the vulnerabilities specific to each direct supplier and service provider, and the overall quality of their products and cybersecurity practices. Some organizations conclude from that assessment that a provider subject to foreign law, or one they cannot audit, is a risk they want to reduce. That is a result of the risk assessment, not a rule in the directive. The jurisdiction question is covered in does the US CLOUD Act apply to data stored in the EU.
NIS2 implementation in German law
Germany transposed NIS2 with the Gesetz zur Umsetzung der NIS-2-Richtlinie (BGBl. 2025 I Nr. 301), known in its draft stage as NIS2UmsuCG. It was published on 5 December 2025, took effect on 6 December 2025 and largely rewrites the BSI Act (BSIG). The German terms are “besonders wichtige Einrichtungen” for essential entities and “wichtige Einrichtungen” for important ones.
Entities in scope must register with the BSI. The BSI states that the statutory registration deadline has passed and that entities not yet registered must do so immediately, through the BSI portal with an ELSTER organisation certificate.
The KRITIS-Dachgesetz is a separate law. It implements the Critical Entities Resilience Directive (EU) 2022/2557 and covers the physical resilience of critical facilities, such as protection against natural hazards, sabotage and terrorist attacks, rather than IT security. It was published as BGBl. 2026 I Nr. 66 on 16 March 2026 and took effect on 17 March 2026. Operators of critical facilities often fall under both laws.
C5 attestations are one common way to document the security of cloud suppliers in a German NIS2 risk assessment; see what is BSI C5.
Cloudfleet’s supplier information
Cloudfleet notifies customers of a personal data breach affecting their data within 24 hours, protects all staff accounts with multi-factor authentication, and writes administrative actions to append-only storage, as described in Security and data protection. On Enterprise clusters, the Kubernetes audit logs are delivered to your own infrastructure, and the shared responsibility model sets out which controls Cloudfleet runs and which remain yours.