Does DORA apply to my cloud provider or to me?

To you directly if you are a financial entity in scope, and potentially to your provider through the oversight framework for critical ICT third parties. Your obligations, including the exit strategy and concentration-risk assessment, attach to you regardless of whether your provider is designated critical. You cannot delegate them to the provider.

What does DORA require in a cloud exit strategy?

A documented and tested plan to move an ICT service supporting a critical or important function to an alternative provider or back in-house, without operational disruption or a compliance breach. In practice that means known alternatives, a rehearsed migration path, and an architecture portable enough to actually execute, not just a policy document.

How is DORA different from NIS2?

DORA is a regulation aimed specifically at the financial sector and applies directly across the EU; NIS2 is a broader directive transposed differently by each member state. DORA goes deeper on financial resilience, with explicit rules on third-party contracts, concentration risk and tested exit strategies. A financial entity can be subject to both.

Financial-sector resilience regulation

DORA, your cloud provider and the exit-plan rule

DORA is the reason a European bank or insurer can no longer treat its cloud provider as someone else’s resilience problem. It regulates financial entities and, for the first time, the ICT providers they lean on, and it demands something most cloud contracts were never written to give: a tested plan to leave. This page covers who DORA binds, the third-party rules that reach your provider, and why reversibility became a legal requirement.

This is general information about DORA, not legal advice. For how it applies to your entity and functions, ask a qualified lawyer.

Who DORA binds, and how far it reaches

DORA (Regulation (EU) 2022/2554) applies across the EU from January 2025. As a regulation, not a directive, it applies directly, without waiting for national transposition, which is why it lands more uniformly than NIS2. It covers a broad list of financial entities: banks, insurers, investment firms, payment institutions, crypto-asset service providers, and more.

Its reach does not stop at financial firms. DORA also creates an oversight framework for ICT third-party service providers, and lets the European Supervisory Authorities designate some as "critical" (critical ICT third-party providers, or CTPPs). A large cloud provider serving much of the EU financial sector is a candidate for that designation, which brings it under direct EU oversight.

The third-party rules that reach your cloud contract

DORA’s ICT third-party risk chapter sets out what a contract with a provider like a hyperscaler must contain (Article 30). It requires clear service descriptions, data-location provisions, access and audit rights, assistance during incidents, and, notably, termination rights and exit strategies. Many standard cloud terms had to be renegotiated to meet this.

Financial entities must also keep a register of information on all ICT third-party arrangements, and report it to regulators. That register makes the dependency visible to a supervisor in a way it never was before. Your cloud relationship is now something an authority can inspect line by line.

Concentration risk: the regulator’s fear

DORA explicitly requires financial entities to assess ICT concentration risk (Article 29): the danger that too much of the sector depends on too few providers, so that one provider’s failure, or one jurisdiction’s action, cascades. A market where most banks run on two or three US hyperscalers is exactly the shape that worries supervisors.

This reframes provider diversity and provider substitutability as prudential concerns, not procurement preferences. If you cannot show a credible path off your primary provider, you are carrying concentration risk that DORA asks you to identify and manage.

The exit strategy is where reversibility becomes law

Article 28 requires financial entities to have exit strategies for ICT services supporting critical or important functions: documented, tested plans to move to an alternative provider or bring the function back in-house, without disrupting the business or breaching regulatory duties. An exit plan that has never been tested against reality does not satisfy the spirit of it.

This is the clause that turns reversibility from a nice-to-have into an obligation. A workload wired to one provider’s proprietary services, with no rehearsed way off, is hard to square with Article 28. Designing for portability, on infrastructure and interfaces you could actually leave, is how you make the exit plan real rather than a document.

What is still being worked out

The label "critical ICT third-party provider" is doing contested work. The criteria and the list of designated CTPPs are being worked out by the European Supervisory Authorities, and which cloud providers end up formally designated, and what oversight bites in practice, is still settling. Do not assume your provider is, or is not, a CTPP without checking the current designations.

There is also honest debate about how far an "exit strategy" must go. A documented plan, a tested plan, and a genuinely portable architecture are three different bars, and DORA’s language leaves room to argue about where the line sits for a given function. What is not arguable is that no plan at all fails; the direction of travel is toward tested and credible, not toward paper.

Common questions about DORA and cloud

Does DORA apply to my cloud provider or to me?: To you directly if you are a financial entity in scope, and potentially to your provider through the oversight framework for critical ICT third parties. Your obligations, including the exit strategy and concentration-risk assessment, attach to you regardless of whether your provider is designated critical. You cannot delegate them to the provider.
What does DORA require in a cloud exit strategy?: A documented and tested plan to move an ICT service supporting a critical or important function to an alternative provider or back in-house, without operational disruption or a compliance breach. In practice that means known alternatives, a rehearsed migration path, and an architecture portable enough to actually execute, not just a policy document.
How is DORA different from NIS2?: DORA is a regulation aimed specifically at the financial sector and applies directly across the EU; NIS2 is a broader directive transposed differently by each member state. DORA goes deeper on financial resilience, with explicit rules on third-party contracts, concentration risk and tested exit strategies. A financial entity can be subject to both.