Cloud exit planning under DORA has shifted from a contract appendix to a capability banks must prove. A DORA cloud exit strategy now has to show that a critical workload can actually leave its provider, not just describe how it might. The gap is wide. In February 2025, the ECB reported that 82% of critical functions outsourced by significant banks are hard or impossible to move to another provider. Of those, 95% are hard or impossible to bring back in-house.

What Must a DORA Cloud Exit Strategy Contain?

DORA Article 28(8) requires exit strategies for every ICT service supporting a critical or important function. That is a function whose failure would materially harm the firm’s finances, service continuity or regulatory compliance. The strategy must cover provider failure, deteriorating service quality, disruption from failed provision, risks to continuous deployment, and termination under Article 28(7). The firm must be able to leave without disrupting business, compliance or clients.

Two documents apply. The exit strategy sets policy at entity level. The exit plan works per contract: Delegated Regulation (EU) 2024/1773 requires one per arrangement, with plausible scenarios and a schedule matching the contract’s exit terms. DORA adds that plans must be “sufficiently tested and reviewed periodically.”

Why Is Cloud Exit Harder Than Other ICT Exits?

Cloud exit is harder because dependency deepens every year a workload runs on proprietary managed services. According to the ECB’s February 2025 outsourcing analysis, banks raised cloud spending by 13.5%, to roughly €57 million per significant institution. Half of critical external budget flows to just 30 providers. Contracts average four subcontractors, so you exit a chain, not a vendor.

Virtual machines move easily; managed databases, proprietary identity services and provider-held keys do not. On 18 November 2025, the European Supervisory Authorities (ESAs) designated 19 critical ICT third-party providers (CTPPs), including hyperscale clouds, for direct EU oversight. Designation does not dilute your duty: the financial entity remains fully responsible.

A Five-Step DORA Cloud Exit Template for ICT Providers

An ICT provider exit plan works when it is built per workload, from the data outward.

1. Scope from the register. Use the DORA register of information to link each critical function to its cloud services and subcontractors.
2. Separate planned and stressed exits. A stressed exit — insolvency, sanctions or a supervisory termination order — assumes no provider cooperation and needs its own runbook.
3. Name the destination. Choose an alternative provider, an EU-jurisdiction cloud or in-house reintegration. The ECB’s July 2025 cloud guide treats a list of qualified alternatives as good practice.
4. Write the runbook. Document milestones, tasks, skills, duration and cost, as the ECB Guide expects. Hold your own keys and define infrastructure as code.
5. Align the contract. Since 12 September 2025, the EU Data Act caps switching notice at two months and guarantees 30 days for data retrieval. The transitional period is 30 days, extendable to seven months only if technically unfeasible.

How Should You Test a DORA Exit Plan?

A DORA exit plan is tested when representative data has been moved and timed, not when a document is reviewed. DORA prescribes no single method; testing scales with the proportionality criteria in Article 4(2).

Three tiers build credible evidence. First, an annual management-body tabletop on a stressed exit. Second, component tests: export data in the agreed format, validate completeness, restore it elsewhere and rebuild infrastructure from code. Third, a partial live migration of one bounded workload.

Each test should log elapsed time against the contractual transition period, data-integrity results and remediation owners. The ECB Guide expects exit plans to be retested regularly, costed realistically and checked independently. A completed DORA exit plan template that has never moved real data is a desk exercise, not an exit test.

What Are the Common Pitfalls in DORA Exit Planning?

The most common failure is a plan written only for a cooperative provider. The second is ignoring the supply chain, which the ECB Guide brings into scope when third parties run on cloud infrastructure. The third is a timeline longer than the contract allows.

However, exit-readiness does not mean running every critical function hot on two clouds. That doubles cost and complexity, and DORA does not require it. Proportionality supports warm standby or rebuild-from-code for most workloads, reserving active multi-cloud for functions with near-zero downtime tolerance.

What Changes for Cloud Exit Planning in 2026–2027?

Cloud exit economics change on 12 January 2027, when the Data Act bans switching charges; until then, providers may charge only direct switching costs. Sequence planned migrations against that date.

The ESAs update the CTPP list annually, and supervisors will compare what registers claim about substitutability with what exit tests prove. Banks that test now will be ready when — not if — that evidence is requested.

How Does ASEE Approach Exit-Ready Cloud Operations?

Exit-readiness is an architecture decision made at onboarding, not a document drafted at renewal. Having supported financial institutions across 55+ countries and processed over 3 billion transactions annually, ASEE sees the exit clause from both sides of the contract.

The discipline: agree data export formats, key custody and infrastructure-as-code before go-live. ASEE Cloud operates within EU jurisdiction, giving banks in Central and South-Eastern Europe a regulated destination when an exit plan names one. The operational requirements of exit-ready regulated workloads are ones we understand at implementation level, not just in theory.

Frequently Asked Questions

What is a DORA cloud exit strategy?

A DORA cloud exit strategy is the entity-level policy, required by Article 28(8), for leaving any cloud service that supports a critical or important function. It must cover provider failure, service deterioration, disruption and termination, and let the firm exit without harming clients or compliance.

What is the difference between a DORA exit strategy and an exit plan?

The exit strategy is the entity-level policy; the exit plan is the runbook for one contract. Delegated Regulation (EU) 2024/1773 requires a documented exit plan for each arrangement, built on plausible scenarios and a schedule that fits the contract’s exit terms.

What should a DORA cloud exit template include?

A DORA cloud exit template should have one completed copy per contract that supports a critical or important function. Each copy records the register reference, exit triggers for planned and stressed scenarios, and the named destination. It also holds a runbook with milestones, tasks, skills, time and cost, plus data and key handover steps and a test log.

Is a DORA exit plan template enough for compliance?

No. A DORA exit plan template structures the documentation, but DORA requires exit plans to be tested and reviewed on a regular basis. The plan must also be realistic and feasible, with a schedule that fits the contract, so supervisors will look for test evidence, not just a completed form.

How often must a DORA exit plan be tested?

DORA requires exit plans to be tested and reviewed periodically but sets no fixed frequency. The ICT third-party policy must be reviewed at least once a year, so an annual test cycle, plus retesting after material changes, is a defensible baseline.

Does CTPP designation change a bank’s exit obligations?

No. Designation places the provider under direct ESA oversight, but the financial entity stays fully responsible for its own compliance. As a last resort, supervisors can require entities to suspend or terminate a non-compliant CTPP’s services, which makes a tested exit plan more important, not less.

Does DORA require a multi-cloud setup?

No. DORA requires a credible, tested route out, not parallel operation on two clouds. Proportionality under Article 4(2) allows warm standby, rebuild-from-code or in-house reintegration, depending on how much downtime a function can tolerate.

How does the EU Data Act support DORA exit plans?

The Data Act gives cloud customers enforceable switching rights. Providers must accept a switch on no more than two months’ notice, complete it within a 30-day transitional period and keep data retrievable for at least 30 days, with switching charges banned from 12 January 2027.

Sources

• EUR-Lex — Regulation (EU) 2022/2554 (DORA)
• Springlex — DORA Article 28: General principles (full text)
• Springlex — Delegated Regulation (EU) 2024/1773, Article 10: Exit and termination
• ECB Banking Supervision — Outsourcing trends in the banking sector (February 2025)
• Banque de France — ECB finalises Guide on outsourcing cloud services (July 2025)
• Jones Day — New ECB Guide on Outsourcing Cloud Services (November 2025)
• CMS — ECB issues new guidance on outsourcing cloud services
• Morgan Lewis — DORA: EU Regulators Announce List of Critical ICT Third-Party Providers (November 2025)
• Bundesnetzagentur — Data Act Factsheet: cloud switching