NIS2 and DORA for Cloud: Core EU Requirements for Providers and Customers

Two Frameworks, One Common Confusion: NIS2 vs. DORA in Plain English

Hello, reader.

Today we’re unpacking two acronyms that keep showing up in EU conversations about cloud and security: NIS2 and DORA. They’re often confused because both talk about risk management, incidents, processes, and “resilience.” But they’re different frameworks with different entry points.

NIS2 is a directive that sets a broad cybersecurity baseline for a wide range of critical and important sectors across the EU. The goal is to raise the minimum level of cyber risk management and incident readiness for organizations that matter to the economy and society.

DORA is a regulation focused specifically on the financial sector and digital operational resilience: how financial entities (and their key ICT providers) should withstand, respond to, and recover from IT disruptions and cyber incidents. DORA has a particularly strict focus on third-party risk management — including cloud providers.

Why do people mix them up? Because from the outside they sound similar: “cyber risk,” “controls,” “incident reporting,” “suppliers.” But if we simplify it into one clear distinction:

• NIS2 mostly answers: “You’re an organization in a critical/important sector. What cybersecurity measures must you implement, and how must you report significant incidents?”
  
• DORA answers: “You’re a financial entity (or a critical ICT provider to one). How do you ensure digital resilience, how do you test it, and how do you control dependencies on vendors and the cloud?”

And this is why “cloud” keeps ending up at the center of the conversation: for NIS2 it’s part of your infrastructure and supply chain, while for DORA it’s often one of the most critical dependencies — something you must document, control, and be able to work around quickly if things go wrong.

Next, we’ll move to the most practical part: who these frameworks apply to, what roles the provider and the customer take on, and why the same company can fall under different requirements depending on where it sits in the chain and which sector it serves.

Who It Applies To: Scope, Roles, and “What’s Your Place in This Story?”

Let’s start with NIS2. The logic here is fairly straightforward: the EU looks at an organization’s sector and its role in the economy, and then classifies it as either an essential entity or an important entity (in short: different levels of supervision and consequences).

In most cases, classification depends on sector and size (for example, medium and large organizations in the listed sectors), with exceptions and specific categories that may fall in scope through different criteria.

Why this matters for cloud specifically: NIS2 explicitly treats digital infrastructure as a key sector, and cloud services often end up in scope either directly (as part of digital infrastructure) or indirectly as a critical part of the supply chain for in-scope organizations.

A timing nuance: NIS2 is a directive, which means it’s implemented via national laws. The formal transposition deadline was October 17, 2024, but adoption timelines varied across member states — so in practice, requirements did not “switch on” uniformly everywhere.

DORA, however, is structured differently. It doesn’t try to cover “everything important” at once — it’s specifically about the digital operational resilience of the financial sector and ICT risk management, including risks from external ICT providers (which often includes cloud).

The timeline is simpler here: DORA applies from January 17, 2025.

The practical cloud takeaway is this: even if you’re “not a financial institution,” if you provide ICT services to the financial sector, DORA will affect you through customer requirements — contracts, risk controls, reporting, subcontractor terms, and so on.

If we put it all into one picture, the next step is to identify your role: you’re either a provider or a customer, a financial entity, or an ICT provider to the financial sector. To make this easy to see at a glance, here’s a short reference table below.

Once you’re clear on “who you are” in the story (provider, customer, financial entity, or an ICT provider to the financial sector), the rest gets easier. You can move from labels to substance: what controls and practices are actually expected — which cybersecurity and resilience building blocks show up, and where NIS2 and DORA overlap versus where they diverge.

The Core Requirements: Risk Management and Operational Resilience

NIS2: Baseline Cyber Risk Controls and Security Governance

If you strip away the legal language, NIS2 asks in-scope organizations for one simple thing: treat cyber risk management as an operational process, not as a scattered set of one-off controls. This is embedded in the directive’s risk-management measures: controls should be proportionate to risk, account for supplier dependencies, and be integrated into company governance — not kept in an isolated “IT corner.”

In practical terms, regulators typically expect to see these building blocks:

• Risk management policies and procedures. Clear rules for how specific risks are mitigated, who owns what, how decisions are made, and how they’re reviewed — usually including a risk register.
  
• Incident management. The ability to detect, respond, recover, and learn from incidents — not just “put out the fire,” but reduce the chance of repetition.
  
• Business continuity and recovery. Plans for disruption scenarios, backups, restore procedures, and “how we keep operating when something goes wrong.”
  
• Supply chain security. Managing vendor and contractor risk (including cloud) — because this is where “grey areas” of responsibility often appear.
  
• Secure development and operations. Security practices across the system lifecycle: patching, vulnerability management, and change control.
  
• Access control and baseline hygiene. Privilege management, account protection, secure communications — the basics that tend to fail first during real attacks.

In practice, many teams lean on ENISA’s official guidance and technical materials to translate high-level requirements into concrete controls and evidence — i.e., “what to implement” and “what to show” during audits or regulatory reviews.

DORA: The Five “Pillars” of Resilience — and What They Mean for ICT and Cloud

If NIS2 is primarily about raising the baseline level of cybersecurity governance across critical sectors, DORA looks at IT in a much more operational way: how a financial entity survives outages, attacks, and vendor failures while keeping the business running. The easiest way to understand DORA is through its main building blocks (often described as the “five pillars”):

• ICT risk management. Processes, roles, change control, protection, detection, and recovery — everything that turns IT into a managed risk rather than a lottery.

  EU Cloud Infrastructure You Control

  Run production workloads on dedicated resources across EU data centres. Transparent pricing, no hidden costs. Full control over compute, storage, and networking.

  Explore Infrastructure

  

  Predictable Virtual Machines for Production

  Dedicated vCPUs, consistent performance, no noisy neighbours. Deploy and scale VMs in minutes. Full root access, fixed pricing.

  View VM Plans

  

  Up to €22,000 to Migrate Your Workloads

  Cut OPEX when migrating to EU infrastructure. Get migration support, cost assessment, and infrastructure credits with no upfront commitment.

  Apply for Bonus

  

  Kubernetes with Full Control

  Deploy production-ready clusters with control over node configuration, storage, and networking. Predictable costs and direct access to infrastructure.

  Deploy Cluster

  
  
  
• Incident management and reporting. What counts as an incident, how it’s classified, and how/where it’s reported so regulators and the market get timely, consistent information.
  
• Digital operational resilience testing. Regular checks that you can actually withstand disruption — not just on paper, but through testing and exercises.
  
• ICT third-party risk management. Contracts, oversight, subcontractors, concentration risk, and exit planning — especially relevant for cloud.
  
• Information sharing. Mechanisms for sharing threat intelligence where appropriate and permitted, so the sector learns faster from attacks.

Now, what does this mean for cloud in practice?

For a financial entity (the customer), DORA usually collapses into two core expectations:

1. You must be able to demonstrate that you control ICT risk (including cloud) — not that you “just bought a service.”

2. You must manage cloud as a critical dependency: know which functions are hosted in the cloud, which providers are involved, where the failure points are, and how you would exit or work around the dependency if needed.

For a cloud/ICT provider, DORA often arrives indirectly through customer requirements — but in a very concrete form: stronger contractual terms, transparency obligations, audit support, subcontractor controls, and incident processes. And for some large providers, there’s an additional layer of direct supervision: DORA creates an EU-wide oversight framework for critical ICT third-party providers (CTPPs), with lead oversight performed by European supervisory authorities.

Split of Responsibility: What the Provider Must Ensure — and What the Customer Must Do

Neither NIS2 nor DORA is about “offloading security to the cloud.” The core idea is governance: you must understand who owns what — and be able to prove it. In cloud environments this usually boils down to a simple rule: the provider is responsible for the security and resilience of the platform, while the customer is responsible for the security and resilience of what they build on top of it.

To keep this practical, here’s a reference table that highlights where the provider’s responsibilities typically sit, where the customer’s begin, and where the “grey zones” most often appear:

The cloud can provide a strong foundation, but “ready-made security” doesn’t assemble itself. The clearer you draw the line between platform responsibility and your own configuration, the fewer surprises you’ll face in audits — and the more calmly your infrastructure will operate.

Contracts and Third-Party Risk: What to Lock Down in the Agreement and SLA

If NIS2 and DORA describe what must be achieved, the cloud contract is where you answer how it will be achieved — and what evidence proves it. Without solid contract language, compliance quickly turns into assumptions: “we thought it worked that way,” “they said it verbally,” “it should be in the SLA.”

In the EU context, the core idea is simple: cloud is part of your supply chain, which means provider risk becomes your risk. That’s why contracts should cover more than “99.9% availability” — they should also define control, transparency, and incident behavior.

What’s typically worth fixing in writing, in practical terms:

1) Responsibility boundaries and the service model. What the provider ensures at the platform level — and what remains the customer’s responsibility. It sounds obvious, but unclear boundaries are one of the most common reasons post-incident discussions collapse into blame.

2) SLA and SLO in concrete, usable terms. Not just an uptime percentage, but what’s included in the service scope, what counts as downtime, how minutes are calculated, which exclusions apply (maintenance windows, force majeure), what credits exist, and what they actually mean. A key nuance: service availability is not the same as your application availability, so it’s useful to spell out which components are covered by guarantees and which are not.

3) Incidents and notifications. Even if you document the internal process elsewhere, the contract should specify: which events the provider must report, within what timelines, via which channels, what minimum information is provided, and how status updates are delivered. In regulated environments, “we found out a day later” can become not only a technical problem, but a legal one.

4) Audit rights and evidence. The practical question is: what can you show an auditor or regulator to prove the provider’s controls? That may include access to reports, attestations, control descriptions, and resilience testing outputs — in a format accepted in your industry. The key is making this a clear obligation, not “on request if possible.”

5) Subcontractors and the supply chain. For third-party risk management, you need visibility into who else is involved in service delivery (support, networks, data centers, etc.) and how the provider governs those dependencies. This often includes notification requirements for material changes and rules for subcontractor engagement.

6) Data and geography (where applicable). Where data is processed and stored, what placement options exist, how migration works, what constraints apply, and what control mechanisms are available. You don’t need “rack-level” detail — but you do need clarity on what you’re buying: one region vs. multiple regions, the ability to choose placement, and how that’s reflected contractually.

7) Exit planning. This is one of the most underestimated items — until it’s suddenly urgent. Under DORA and general risk management logic, you need a predefined path for how you leave: how you export data, timelines, formats, limitations, and deletion obligations after migration. Without that, “exit” turns into a months-long project under pressure.

A strong NIS2/DORA-aligned contract isn’t just a thick PDF. It’s a document that makes risk governable: it defines boundaries, specifies evidence, sets incident rules, and pre-plans the unpleasant scenario — what happens if you need to separate from a provider quickly.

Incidents and Reporting: What Counts as an Incident — and How to Build Notifications

In everyday life, an incident is simply “something broke.” In a regulated environment, an incident is also a question of time: when you learned about it, how you assessed impact, and how quickly you reported. Both NIS2 and DORA emphasize that you can’t “keep incidents internal until we figure it out.” You need a process that still works under pressure and uncertainty.

The first thing to understand: this is not about every monitoring alert. Regulators care about significant (material) incidents — events that impact availability, integrity, confidentiality, or service resilience, and that can have meaningful consequences for customers, the market, or even society. How “significance” is defined depends on the legal/regulatory framework and your internal criteria, but the practical logic is usually consistent: look at scope, duration, criticality of impacted functions, and potential harm.

That leads to the core process goal: make sure that during an incident, the team doesn’t waste time arguing “is this significant yet?” — but follows predefined rules.

In practice, a workable approach is usually built around three steps.

Step 1: Detection and initial classification.
You need a mechanism that answers quickly: what happened, and how likely is it that this qualifies as “significant”? Define triggers in advance — for example: widespread errors in a critical service, prolonged downtime, data exposure, account compromise, or disruption of a critical business process (payments, settlement, access to key systems).

Step 2: Trigger the notification chain.
Who decides “this is an incident”? Who owns external communications? Who contacts the provider? Who maintains the timeline? In a healthy process, these roles are assigned ahead of time. Because during an incident, people are busy firefighting — and if you also have to invent the process on the spot, you lose on time.

Step 3: Reporting and evidence.
Regulatory expectations are fact-driven: when it started, when it was detected, what systems were affected, what actions were taken, how recovery proceeded, and how recurrence will be prevented. That’s why you need an incident timeline and a minimum evidence set you can collect even in a high-stress situation.

There’s also a cloud-specific nuance: part of the information lives with the provider. So your incident process must include a bridge to contractual obligations: how quickly the provider supplies event data, through which channels, and who on your side knows how to request and interpret it. Otherwise you end up depending on luck: “did we reach the right support person?”

A good notification process isn’t bureaucracy. It’s a way to win the most expensive resource in an incident: time. And time often determines whether this is “an unpleasant outage” — or a story with serious consequences.

At this point the picture is almost complete. Once you understand how NIS2 and DORA differ, know your role, grasp the substance of the requirements, anchor responsibilities in contracts, and build an incident process, these regulatory frameworks stop feeling scary. In the conclusion, we’ll compress it into one simple idea: what matters for cloud in the EU — and how to approach it without panic.

Conclusion

NIS2 and DORA often sound like “two scary security acronyms,” but at their core they push the same idea: cyber risk and resilience must be governable and provable — especially when you depend on cloud and external suppliers.

If we reduce it to a simple picture: first, identify which framework applies to you and what role you play (provider, customer, financial entity, or an ICT provider to the financial sector). Next, translate legal language into operational reality: risk management, resilience, and supply-chain control. Then lock responsibility boundaries and obligations into contracts and SLAs so you’re not debating “who was supposed to do what” in the middle of an incident. And finally, build incident and notification processes so that in a critical moment you don’t lose time to arguments and improvisation.

Thanks for reading!