What NIS2 Actually Requires From Your Infrastructure Platform When You Move Regulated Workloads to the Cloud

Key Points:

• NIS2 (EU Directive 2022/2555) does not prohibit running regulated workloads on a hyperscaler. It makes the entity, not the cloud provider, accountable for ten risk-management measures listed in Article 21: access control, encryption, logging, supply chain security, tested incident handling, and more.
• The shared responsibility model means the cloud provider covers the infrastructure layer, but the NIS2 obligations land on everything you configure above it: identity, network segmentation, audit trails, backup and recovery testing, and third-party dependency management. Your internal platform is where most of that is enforced or lost.
• Article 23 sets hard reporting clocks: an early warning to the national CSIRT within 24 hours of becoming aware of a significant incident, a full notification within 72 hours, and a final report within one month. A platform that cannot tell you who deployed what, when, and to which environment makes those deadlines unmeetable.
• Article 21(2)(d) extends obligations to your supply chain, which includes your CI/CD pipeline, container registries, IaC modules, and the SaaS control planes that touch production. Platforms that execute deployments from their own cloud account widen that supply chain; platforms that deploy into your account narrow it.
• Practically, NIS2 favours an architecture where the cloud account, data, encryption keys, and logs stay under your legal control, and the developer platform provides self-service on top of it. Qovery is built that way: it deploys into your own AWS, GCP, Azure, Scaleway, or existing Kubernetes cluster, so residency, audit trails, and key custody never leave your entity.

NIS2 does not say a word about which cloud you use. It says a great deal about what you must be able to prove.

That distinction is the whole article. Most of what you will read about NIS2 is either legal boilerplate with zero infrastructure detail, or vendor fear-marketing telling you the sky is falling unless you buy a "sovereign" box. Both miss the point. NIS2 is a risk-management and accountability regime. It names outcomes, not products, and the accountability sits with your entity, not with Amazon, Google, Microsoft, or Scaleway.

I run an infrastructure company. I spend my days with platform and DevOps leads who have just been told by their legal team that they are now an "essential" or "important" entity and need to be compliant. The useful version of this conversation is never "which cloud is allowed." It is "which Article 21 control does your platform enforce by default, and can you show the evidence." So let me translate the directive into platform controls you can implement this quarter.

A quick disclaimer before I do: I am an engineer, not your lawyer. Compliance is organisational and depends on your member state's transposition. A platform supplies evidence and enforces controls; it does not make you compliant on its own. I will say that once and move on.

What does NIS2 actually require, and who does it apply to?

NIS2 is Directive (EU) 2022/2555. Member states had to transpose it into national law by 17 October 2024, and the measures apply from 18 October 2024. It replaces the original 2016 NIS Directive and widens both the sectors in scope and the teeth behind it.

Who it applies to:

• Essential and important entities above the medium-size threshold (roughly 50+ staff or EUR 10M+ turnover), in the sectors listed in Annexes I and II.
• Those sectors explicitly include digital infrastructure, cloud computing service providers, data centre providers, managed service providers (MSPs), and managed security service providers (MSSPs). If you operate a platform, you may be in scope as a provider, on top of any obligations your customers carry.

What it requires breaks into three parts:

• Governance (Article 20). Management bodies must approve and oversee the cybersecurity risk-management measures, and member states must ensure those managers can be held liable. There is also a training obligation for management. This is the clause teams forget, and it is the one that puts a name on the accountability.
• Ten risk-management measures (Article 21(2)). Written to be read as outcomes. Paraphrasing the text at Article 21: (a) risk analysis and information system security policies; (b) incident handling; (c) business continuity, backup, disaster recovery, and crisis management; (d) supply chain security; (e) security in acquisition, development, and maintenance, including vulnerability handling and disclosure; (f) policies to assess the effectiveness of the measures; (g) basic cyber hygiene and training; (h) policies on cryptography and encryption; (i) human resources security, access control, and asset management; (j) multi-factor authentication, secured voice/video/text, and secured emergency communications.
• Incident reporting (Article 23). Hard deadlines, covered in its own section below.

The enforcement is real. Under Article 34, the maximum administrative fines are at least EUR 10,000,000 or 2% of total worldwide annual turnover (whichever is higher) for essential entities, and EUR 7,000,000 or 1.4% for important entities. Add possible temporary suspension of management functions.

One more thing to plant now: nowhere in those ten measures does it say "do not use a hyperscaler." It says assess the risk, manage it, and prove you did.

Does NIS2 forbid putting regulated workloads on AWS, Azure, GCP, or another hyperscaler?

No. There is no data-localisation mandate in NIS2 and no cloud-provider ban. What the directive requires is that you assess and manage the risk - including concentration risk and jurisdictional risk - and that you keep accountability for the Article 21 measures regardless of where the workload physically runs.

The confusion comes from stacking NIS2 on top of four other regimes that people treat as one blob. They are not:

• GDPR governs personal data and international transfers. It is about data, not operational resilience.
• DORA (Regulation (EU) 2022/2554) applies from 17 January 2025 and covers EU financial entities and their ICT third-party risk. It overlaps with NIS2 on supply chain and incident reporting but is a separate, sector-specific regulation that takes precedence for finance (lex specialis).
• EUCS, the EU Cloud Certification Scheme, is still unadopted at the time of writing. Its "sovereignty" requirements have been fought over for years and are not binding on you today.
• National schemes like France's SecNumCloud and Germany's C5 are where sovereignty actually bites - and they bite through sector-specific rules and public-sector procurement, not through NIS2 itself.

So where does sovereignty come from if not NIS2? From your sector regulator, your government customers, and your own board's risk appetite. NIS2 pushes you toward demonstrable recovery and, in practice, portability through its business-continuity and supply-chain clauses, but it does not tell you to leave AWS for a national cloud.

What auditors and CSIRTs actually ask for is evidence, not architecture diagrams: access logs, change records, a tested restore, documented third-party assessments. A hyperscaler is fully capable of hosting a compliant workload. Your configuration and your platform layer decide whether you are actually compliant. Worth remembering here that Gartner has long predicted that through 2025, 99% of cloud security failures would be the customer's fault, mostly misconfiguration. That is the NIS2 risk surface in one sentence.

Where does the cloud provider's responsibility stop and your platform's begin?

Under every hyperscaler's shared responsibility model, the provider secures the cloud and you secure what runs in it. AWS, Google Cloud, and Microsoft Azure all draw the same line: they own the hardware, hypervisor, managed control planes, and physical and regional resilience. You own identity, encryption configuration, network design, data, and - on compute you manage - the operating system and patching.

NIS2 Article 21 lands almost entirely on your side of that line. Here is the map.

The managed-Kubernetes trap deserves a callout. EKS, GKE, and AKS cover the control plane. You still own node patching, admission policy, RBAC, secrets handling, and - critically - cluster upgrades. The AWS EKS shared responsibility docs and the equivalent GKE and AKS pages all make this split explicit. A managed cluster is not a managed compliance posture.

The gap almost always sits in the deploy path: who can push to production, with what approval, and whether that action is recorded somewhere a regulator can read. Which is the framing for the rest of this piece. NIS2 compliance, at the platform layer, is mostly a question of what your platform enforces by default.

What NIS2 controls must the infrastructure platform itself enforce?

Seven platform-level capabilities turn Article 21 from a policy document into something you can evidence.

• Access control and MFA (Art. 21(2)(i) and (j)). Per-environment RBAC, no shared production credentials, SSO/SAML, enforced MFA, and joiner-mover-leaver changes reflected in the platform, not just the IdP. When someone leaves, their deploy access should die with their SSO account.
• Audit trail and accountability (Art. 20 and 21(2)(b)). An immutable record of who deployed which commit, to which environment, when, and approved by whom - with a defined retention period. Article 20 names a responsible manager; your audit trail is how that name gets evidence behind it.
• Environment segmentation (Art. 21(2)(a) and (e)). Separate accounts, clusters, or namespaces for prod and non-prod, network policy between them, and no production data in preview environments. Preview environments leaking real customer records is one of the most common quiet violations I see.
• Cryptography (Art. 21(2)(h)). Encryption at rest and in transit by default, customer-managed keys where it matters, and documented rotation and custody. If your key lives in a vendor's account, your key custody story is their story.
• Supply chain and secure development (Art. 21(2)(d) and (e)). Pinned base images, an SBOM, registry provenance, a CVE scanning gate before deploy, a patch SLA, and reviewed IaC.
• Business continuity (Art. 21(2)(c)). Automated backups of managed databases, restore drills with recorded RTO/RPO, a multi-AZ or multi-region topology, and documented failover. A backup you have never restored is a hope, not a control.
• Incident handling (Art. 21(2)(b)). Rollback in minutes, a clean correlation between a deployment and an incident, and on-call runbooks tied to the platform rather than to tribal memory.

One vulnerability-handling detail that trips teams up: Kubernetes minor versions get patch support for roughly 14 months (12 months standard plus about 2 months of maintenance), per the Kubernetes patch-release policy. Skip a year of upgrades and your cluster drifts out of support, which means out of CVE coverage, which means out of compliance with 21(2)(e). Upgrade cadence is not hygiene theatre; it is a dated requirement.

How do NIS2's 24-hour and 72-hour reporting deadlines change what your platform must log?

Article 23 sets the clock, and getting it wrong in a blog post would be embarrassing, so here it is precisely:

• Early warning within 24 hours of becoming aware of a significant incident, to your CSIRT or competent authority.
• Incident notification within 72 hours, including an initial assessment of severity and impact, and any indicators of compromise.
• Intermediate status updates on the CSIRT's request.
• A final report within one month of the incident notification.

A "significant incident" under Article 23(3) is one that has caused or is capable of causing severe operational disruption or financial loss, or has affected others with considerable material or non-material damage. Service providers may also owe notification to affected recipients under Article 23(2).

Now put that next to reality. IBM's 2025 Cost of a Data Breach report puts the average breach lifecycle at 241 days - about 181 days to identify and 60 to contain. NIS2 gives you 24 hours from awareness to first warning. You are not expected to have solved the incident in a day, but you are expected to describe it. That is only possible if your platform can answer three questions in minutes: what changed, who changed it, and what is the blast radius.

The common failure mode: logs live in five places - CI, the cloud audit log, the cluster, your APM, and your ticketing system - with no shared identifier tying them together. When the clock starts, nobody can rebuild the sequence inside 24 hours. What good looks like is a single view of every change to a regulated environment, exportable as evidence, with a deployment timeline, an environment inventory, a dependency list, named owners per service, and log retention long enough to reconstruct the event.

Is a SaaS developer platform a NIS2 supply chain risk - and how does BYOC change the answer?

Any vendor with credentials to your production environment becomes part of the supply chain you must assess under Article 21(2)(d). That is not hypothetical: Verizon's 2025 Data Breach Investigations Report found third-party involvement in 30% of breaches, double the prior year. So the decisive question for a developer platform is simple: does it run your workloads in its own cloud account, or deploy them into yours?

There are three models, and they have very different NIS2 consequences:

• Fully managed PaaS in the vendor's account. Operationally lovely. But you lose key custody, direct audit-log ownership, choice of region, the ability to produce evidence without filing a vendor ticket, and a clean exit path. The data plane is the vendor's.
• BYOC (bring your own cloud) - control plane at the vendor, data plane in your account. The cloud contract and any committed-use discounts stay in your entity's name. Data and logs stay in your account. Your IAM is the boundary. The regulator-facing evidence is yours.
• Self-hosted / your own Kubernetes. Everything in-house, at the cost of building and maintaining the platform yourself.

Let me be fair here, because this is where vendor content usually gets dishonest. Heroku, Vercel, and Render are genuinely good products. Thousands of teams ship on them happily. The only issue for a regulated workload is that the data plane lives in the provider's account, which pulls that provider squarely into your supply-chain assessment and limits the evidence you can produce yourself. Northflank and Porter deserve credit for also offering BYOC. Humanitec, Backstage, and raw Terraform plus Argo CD keep everything in-house, which is the strongest residency story and the heaviest maintenance bill.

Due diligence questions to ask any platform vendor, regardless of model: ISO 27001 or SOC 2 scope, subprocessor list, data residency, exactly what permissions they request inside your account, a breach-notification SLA that aligns with your 24-hour clock, and a documented exit and data-portability path.

This is where Qovery fits, stated plainly. Qovery deploys into your own AWS, GCP, Azure, Scaleway, or existing Kubernetes cluster. Per-environment RBAC, managed cluster upgrades, and databases backed by the cloud provider's own managed services (RDS, Cloud SQL, and the like). Because it is BYOC, the data plane, the encryption keys, and the cloud audit logs never leave the regulated entity. You get the self-service of a PaaS and you keep running Kubernetes without managing it directly, often without a dedicated DevOps engineer, while the custody that NIS2 cares about stays in your account. Qovery is the control plane you assess as a third party; your data is not.

What is a practical NIS2 readiness checklist for a platform team?

Work it in four passes and you can get a regulated workload onto a hyperscaler with a defensible posture in a quarter, not a year.

• Scope. Confirm whether you are an essential or important entity under your member state's transposition, register with the national authority where required, and list your in-scope services.
• Evidence. Enumerate every system that can change production, confirm audit-log retention, assign a named owner per service, and build the one-page change timeline you would hand a CSIRT.
• Controls. Enforce SSO plus MFA, remove standing production access, segment environments, enable customer-managed keys, gate deploys on CVE scanning, and define an upgrade cadence for clusters and node images.
• Drills. Run a restore test and record RTO/RPO, run a tabletop for the 24h/72h notification, test rollback, and document the result. Article 21(2)(f) literally requires you to assess effectiveness, so the drill record is itself a control.
• Supply chain. Build a third-party register covering CI, registry, platform vendor, and observability, each with a contractual breach-notification window.
• Governance. Get the management body to formally approve the measures and complete the Article 20(2) training. This is the clause most teams skip, and it is the one an auditor checks first because it is the easiest to verify.

On transposition timing, do not trust a blog over your national authority: as of late 2026, the picture is still uneven. The European Commission referred Ireland, Spain, France, and the Netherlands to the Court of Justice in July 2026 for failing to notify full transposition, and several states only finished recently (Germany's law took effect in October 2026). Check the Commission's NIS2 transposition page for your country's current status rather than assuming the directive's dates map cleanly onto national law.

How do I set this up from Claude Code or Cursor?

If you work from a coding agent, you can scaffold compliant-by-default environments without clicking through a console. Install the Qovery Agent Skills once and your agent can create environments, deployments, and preview environments in your own cloud account, then ask for approval before anything is applied. A human stays in the loop for every production change, which is exactly the shape Article 20 accountability wants.

Install the skills globally for any compatible agent (Claude Code, Cursor, Codex, OpenCode, Gemini CLI):

curl -fsSL https://skill.qovery.com/install.sh | bash

Scope the install to a single repository instead:

curl -fsSL https://skill.qovery.com/install.sh | bash -s -- --project

Add the Qovery MCP Server to Claude Code with OAuth, read-only by default - useful when you only want the agent to inspect existing environments and audit state:

claude mcp add --transport http qovery https://mcp.qovery.com/mcp --callback-port 4242

Enable write access only when you deliberately want the agent to change things, and only after enabling write access in the Qovery Console:

claude mcp add --transport http qovery "https://mcp.qovery.com/mcp?read_write=true" --callback-port 4242

The skills (qovery-onboard, qovery-deploy, qovery-troubleshoot, qovery-optimize, qovery-speedup, qovery-preview, qovery-terraform) handle deployment; the MCP Server operates what already exists. Then you ask in plain language, for example: "deploy this service to my Azure account with Qovery, production environment, EU region."

The compliance-relevant part: the agent proposes, the platform records, and a human approves. Every applied change still lands in the Qovery audit trail and in your own cloud account's audit log. The agent does not become a hole in your evidence chain. Start at the AI agent quickstart and the Claude Code integration page.

What does NIS2 compliance require for infrastructure platforms when regulated workloads move to a hyperscaler cloud?

NIS2 requires that the entity, not the cloud provider, enforces and can evidence the ten Article 21 risk-management measures: access control and MFA, encryption, incident handling, business continuity, supply-chain security, secure development, and effectiveness testing. For an infrastructure platform that means per-environment RBAC, enforced SSO and MFA, an immutable deployment audit trail, environment segmentation, customer-managed encryption keys, a CVE scanning gate, tested backups, and a defined cluster upgrade cadence. The hyperscaler secures the cloud; your platform and configuration secure what runs in it.

Does NIS2 require data to stay in the EU or on a sovereign cloud?

No. NIS2 contains no data-localisation mandate and no sovereign-cloud requirement. It requires you to assess and manage risk, including concentration and jurisdictional risk, and to keep accountability for the Article 21 measures wherever the workload runs. Sovereignty requirements come from separate regimes such as France's SecNumCloud, Germany's C5, the still-unadopted EUCS scheme, and sector-specific or public-sector procurement rules, not from NIS2 itself.

What are the NIS2 incident reporting deadlines, exactly?

Under Article 23, you must send an early warning within 24 hours of becoming aware of a significant incident, a full incident notification within 72 hours including an initial severity and impact assessment, intermediate updates if the CSIRT requests them, and a final report within one month of the notification. Service providers may also have to notify affected recipients.

Is using a SaaS developer platform a NIS2 supply chain risk?

Any vendor with credentials to your production environment is part of the supply chain you must assess under Article 21(2)(d). The level of risk depends on the model: a vendor-hosted PaaS runs your workloads in the vendor's account, so the data plane, keys, and audit logs sit with them. A BYOC platform deploys into your own cloud account, so the data stays under your control and only the control plane needs third-party assessment. Self-built platforms have no vendor to assess but carry the full maintenance burden.

What are the penalties for NIS2 non-compliance?

Under Article 34, essential entities face maximum administrative fines of at least EUR 10,000,000 or 2% of total worldwide annual turnover, whichever is higher. Important entities face at least EUR 7,000,000 or 1.4%. Member states can also impose temporary suspension of management functions, and Article 20 allows holding management bodies personally liable.

How is NIS2 different from DORA and GDPR for cloud infrastructure?

GDPR governs personal data and its transfer. DORA (Regulation (EU) 2022/2554, applicable from 17 January 2025) governs operational resilience and ICT third-party risk specifically for EU financial entities and takes precedence for them. NIS2 is the broad cybersecurity-risk and incident-reporting regime across many sectors. They overlap on supply chain and incident handling, but only DORA is finance-specific, only GDPR is about personal data, and none of the three mandates a particular cloud or location.

Compliance work is evidence work. The regulator does not want your architecture diagram; they want to know what changed, who changed it, and what it touched, and they want it inside a day. The platform that already records every deployment, scopes who can touch production, and keeps your keys and logs in your own account is the one that makes the 24-hour clock survivable. Build the evidence trail before the incident, because you cannot build it after.