NIS2 Directive: Compliance Architecture for EU Cloud 2026

Q: What is the NIS2 Directive and who must comply?

NIS2 (Directive (EU) 2022/2555) is the European Union's network-and-information-security law. It requires organisations in 18 covered sectors to implement baseline cyber-risk-management measures, report significant incidents within strict deadlines, and places personal accountability on senior management. It replaces the 2016 NIS Directive and widens scope dramatically. Who must comply: "essential" entities (energy, transport, banking, health, water, digital infrastructure, ICT service management, public administration) and "important" entities (postal, waste, chemicals, food, manufacturing, and digital providers such as marketplaces, search engines, and social platforms). The general threshold is medium-and-large organisations — roughly 50+ employees or €10M+ turnover — operating in a covered sector, though some entity types are in scope regardless of size. If you run SaaS, a cloud platform, a data centre, or managed services for EU customers, you should assume you are likely in scope and confirm against your member state's national transposition law.

Q: What is the difference between essential and important entities?

Both tiers must implement the same Article 21 security measures, but they differ in supervision and penalties. Essential entities (the higher-criticality sectors like energy, health, banking, and digital infrastructure) face proactive supervision — regulators can audit and inspect them at any time — and fines up to €10 million or 2% of global annual turnover, whichever is higher; their executives can also face temporary management bans. Important entities (sectors like manufacturing, food, waste, and most digital providers) face reactive supervision — regulators act after an incident or evidence of non-compliance — and fines up to €7 million or 1.4% of global turnover. In both tiers, senior management is personally accountable for approving and overseeing the cybersecurity measures. The practical takeaway is that the technical controls you must build are identical across tiers; only the enforcement intensity and maximum fine differ, so you should not under-invest just because you're classified as "important."

Q: What are the Article 21 baseline security measures?

NIS2 Article 21 lists ten minimum risk-management measures, written as outcomes rather than prescriptive controls: (1) risk analysis and information-security policies; (2) incident handling — detection, response, and reporting; (3) business continuity, including backup, disaster recovery, and crisis management; (4) supply-chain security covering vendors and dependencies; (5) security in network/information-system acquisition, development, and maintenance, including vulnerability handling; (6) policies to assess the effectiveness of measures; (7) basic cyber hygiene and security training; (8) cryptography and encryption; (9) human-resources security, access control, and asset management; and (10) multi-factor authentication and secured communications. Each maps directly onto cloud controls you can implement and evidence: IAM with SSO and enforced MFA, KMS encryption and a secrets manager, zero-trust network segmentation, a SIEM with an incident-response runbook, cross-region backups with tested RTO/RPO, an SBOM and vendor assessments, and a secure SDLC with SAST/DAST in CI. Like SOC 2, NIS2 is controls you implement and evidence, not a certificate you purchase.

Q: What are the NIS2 incident-reporting deadlines?

NIS2 imposes a staged reporting timeline for significant incidents that you must engineer for in advance. First, within 24 hours of becoming aware, you must submit an early warning to your national CSIRT or competent authority — this is the hardest deadline to meet and the one most programs miss. Second, within 72 hours, a fuller incident notification with an initial assessment of severity and impact. Third, on the authority's request, an intermediate status update. Finally, within one month, a final report covering root cause, severity, and mitigation. A "significant" incident is broadly one that causes serious operational disruption or financial loss, or that affects other parties. Because 24 hours is far too short for a manual scramble, you must pre-build the pipeline: SIEM detection feeding a severity-triage step, a pre-drafted notification template, and a clearly designated owner with authority to file. Automate alert-to-owner routing so the clock isn't consumed by internal escalation.

Q: How does NIS2 relate to GDPR, the EU AI Act, and DORA?

These EU regimes overlap heavily at the control layer, so you should map controls once and satisfy several frameworks rather than running parallel programs. NIS2 covers network and information security and operational resilience. GDPR covers personal-data protection and requires 72-hour breach notification. The EU AI Act governs high-risk AI systems and requires serious-incident reporting plus logging, risk management, and human oversight. DORA governs ICT resilience for the financial sector with its own major-incident reporting and resilience-testing requirements. The shared controls are substantial: encryption, access control, centralized immutable logging, incident response, business continuity and disaster recovery, and supply-chain security all appear in multiple regimes. A single well-built control — centralized tamper-evident logging with a tested IR runbook, for instance — is evidence for all four. The efficient strategy is to build the union of requirements into a governed cloud landing zone and then treat each regulation as an overlay that maps your existing controls to its specific language.

Q: What are the penalties for NIS2 non-compliance?

The penalties are deliberately set high enough to reach the boardroom. Essential entities face administrative fines of up to €10,000,000 or 2% of total worldwide annual turnover, whichever is higher. Important entities face up to €7,000,000 or 1.4% of total worldwide annual turnover. Beyond monetary fines, NIS2 introduces personal accountability for senior management: executives must approve and supervise the cybersecurity measures, can be held personally liable for failures, and — for essential entities — can be temporarily barred from holding management positions. Authorities also have supervisory powers including binding instructions, security audits, and orders to notify affected parties. The cost of compliance, by contrast, is mostly engineering time: an organisation that already operates a governed landing zone with IAM and MFA, encryption, centralized logging, tested backup/DR, and an incident-response runbook can usually treat NIS2 as a gap assessment, documentation, and reporting-pipeline exercise measured in weeks, not a platform rebuild.

Q: How do I build a NIS2-compliant cloud architecture?

Build the ten Article 21 measures into a governed multi-account landing zone rather than bolting them onto each application. The governance layer holds the risk register, the ISMS policies, and policy-as-code guardrails that reject non-compliant deployments at creation. The protection layer is IAM with SSO and enforced MFA under least privilege, KMS customer-managed keys with TLS 1.2+ and a secrets vault, and zero-trust network segmentation. The detect-and-respond layer is a SIEM (or GuardDuty/Security Hub) streaming to centralized immutable logs in a locked archive account, plus a tested incident-response runbook. The recovery layer is cross-region backup with regularly tested RTO and RPO. The supply-chain layer is an SBOM, vendor risk assessments, and a secure SDLC with SAST/DAST in the pipeline. Finally, wire the incident-reporting pipeline so detection flows automatically to a triage step, a notification template, and an accountable owner who can meet the 24-hour deadline. The control plane — preventive guardrails, immutable logs, a tested recovery path — is precisely the audit evidence a regulator and your now-personally-liable board will ask to see.

Q: My company is outside the EU — does NIS2 apply to us?

Possibly. NIS2 can reach non-EU organisations that provide covered services within the EU. Certain digital service providers that offer services in the Union but are not established there must designate a representative in a member state where they offer services, and they fall under that state's jurisdiction. More broadly, even if your entity isn't directly in scope, you may be pulled in through the supply-chain security requirement: EU essential and important entities must secure their vendors and dependencies, so your EU customers will increasingly require NIS2-aligned controls, incident-reporting cooperation, and contractual assurances from you regardless of where you're based — much as SOC 2 became a de facto requirement for selling to US enterprises. The pragmatic stance for a non-EU cloud or SaaS provider with EU customers is to implement the Article 21 baseline anyway, because your customers' compliance now depends on yours, and to confirm direct applicability and any representative-designation obligation against the relevant national transposition law.