DORA and Cloud Exit Strategies: What Financial Companies Must Document

Under Article 28(8) of the Digital Operational Resilience Act (DORA, Regulation (EU) 2022/2554) and Article 10 of Commission Delegated Regulation (EU) 2024/1773, financial entities in the European Union must maintain documented, realistic, and tested exit strategies for every cloud service supporting a critical or important business function. Applicable since January 17, 2025, DORA requires more than a high-level policy statement: companies must document concrete trigger events, verified alternative cloud providers or in-house options, technical data and application migration plans, transition timelines, and contractual termination clauses under Article 30(3)(f), and must review and test these plans periodically.

Key takeaways

Who is affected: Banks, payment institutions, e-money institutions, investment firms, crypto-asset service providers (CASPs), insurers, and other regulated financial entities using cloud services for critical or important functions.
Four mandatory exit scenarios: Under Article 28(8), your exit plan must address provider failure, deterioration of service quality, business disruption from inappropriate or failed service delivery, and material risks preventing the continued use of the service (including early contract termination).
Three layers of documentation: Regulators expect coherence across your ICT third-party policy and technical exit plans (Article 28(8) and RTS 2024/1773), your contractual clauses with the cloud provider (Article 30(3)(f)), and your Register of Information (Article 28(3) and ITS 2024/2956).
Testing is mandatory: Paper-only plans do not pass supervisory review. You must periodically review and test your exit plans to prove your team can migrate data and workloads within your stated recovery and transition windows.
Data Act alignment: Under Article 29 of the EU Data Act (Regulation (EU) 2023/2854), cloud switching charges (including data egress fees for switching) are capped at actual cost until January 12, 2027, and banned entirely from that date onward, removing a major financial barrier to testing and executing cloud exits.

Who needs a cloud exit strategy under DORA?

DORA applies to over 20 categories of regulated financial entities across the EU. For companies with 10 to 300 employees, this typically includes licensed fintechs, payment and electronic money institutions, investment firms, asset managers, insurtechs, and crypto-asset service providers regulated under MiCA.

Not every SaaS tool or cloud account requires a full exit strategy. The requirement under Article 28(8) applies specifically to ICT services supporting critical or important functions. DORA defines a critical or important function as one where a disruption would materially impair the financial performance of the entity, the soundness or continuity of its services and activities, or its ability to comply with regulatory obligations.

For most financial companies, production cloud infrastructure on AWS, Google Cloud, or Microsoft Azure hosts core transaction processing, customer portals, ledger databases, or compliance reporting systems. That places your primary cloud environment squarely inside the scope of Article 28(8).

There is a limited legal exemption: “microenterprises” (defined in DORA as financial entities employing fewer than 10 persons and having an annual turnover and/or annual balance sheet total that does not exceed EUR 2 million) are exempt from the formal requirement to put exit strategies in place under Article 28(8). Once a company crosses 10 employees or EUR 2 million in turnover, the full documentation and testing obligations apply.

What DORA and RTS 2024/1773 require you to document

DORA’s rules on exit strategies are split across the main regulation and its secondary technical standards:

DORA Article 28(8) establishes the core obligation to maintain comprehensive, documented, and tested exit strategies.
Commission Delegated Regulation (EU) 2024/1773 (Article 10) sets the Regulatory Technical Standards (RTS) specifying the exact contents of your exit plans.
DORA Article 30(3)(f) defines the exit and transition clauses that must exist in your cloud contract.
Commission Implementing Regulation (EU) 2024/2956 defines the Register of Information (RoI), where you must record substitutability and exit readiness fields for each critical contract.

During national supervisory reviews, authorities check whether these documents match. If your Register of Information claims your cloud provider is easily substitutable, your contract provides a 30-day notice period, and your engineering architecture relies heavily on proprietary cloud services that would take nine months to rewrite, an auditor will flag the contradiction.

1. Trigger events and exit scenarios

Under DORA Article 28(8) and Article 10 of RTS 2024/1773, your exit plan cannot only cover a planned, friendly non-renewal. You must explicitly document how you will handle stressed exits triggered by:

Unforeseen and persistent service interruptions (such as prolonged regional cloud outages or infrastructure instability).
Inappropriate or failed service delivery (such as persistent SLA breaches, security failures, or compliance violations by the provider).
Unexpected termination of the contractual arrangement (whether terminated by you for cause, by the cloud provider, or ordered by a financial supervisor under DORA’s oversight powers).
Provider failure (insolvency, business closure, or revocation of regulatory authorizations).

For each scenario, you must define measurable internal thresholds that trigger the exit process and specify which roles on your management body have the authority to invoke the plan.

2. Alternative solutions and substitutability assessment

Article 29 of DORA requires you to assess ICT concentration risk and understand how easily a provider can be substituted. In your exit plan, you must identify concrete alternative solutions:

Moving to another third-party ICT provider (for example, migrating from a US hyperscaler to an EU cloud provider such as UpCloud, Scaleway, or OVHcloud).
Reintegrating the function in-house (rarely practical for small and mid-sized companies using public cloud infrastructure, but required to be evaluated).

You do not need to pay for duplicate idle servers running 24/7 on a second cloud unless your specific business continuity risk requires hot standby. However, your exit documentation must name the target provider(s), verify that they offer compatible compute, database, networking, and compliance capabilities, and confirm where data will be stored and processed in the EU.

Note on sovereignty and concentration risk: using a “sovereign” region from your existing provider (such as the AWS European Sovereign Cloud, which keeps data and operations in the EU but belongs to Amazon, a US company) does not satisfy an exit requirement from that same provider group, as DORA Article 29 explicitly requires entities to assess dependencies across connected providers within the same corporate group.

3. Technical migration and transition plan

Article 10 of RTS 2024/1773 states that exit plans must be “realistic, feasible, based on plausible scenarios and reasonable assumptions, and shall have a planned implementation schedule compatible with the exit and termination terms established in the contractual arrangements.”

For a cloud infrastructure exit, your technical documentation should include:

Complete asset and dependency inventory: Every virtual machine, Kubernetes cluster, managed database, object storage bucket, load balancer, firewall rule, DNS zone, and encryption key supporting the critical function.
Portability vs. lock-in mapping: A clear distinction between portable components (such as standard Linux VMs, Kubernetes manifests, PostgreSQL databases, and S3-compatible object storage) and proprietary services that require code changes (such as AWS DynamoDB, Google BigQuery, Azure Cosmos DB, or proprietary IAM and serverless workflows).
Data migration methodology: How databases will be replicated (for example, logical replication for PostgreSQL or MySQL), how object storage will be transferred and verified with checksums, how much bandwidth is required, and how data integrity and encryption will be maintained in transit.
Cutover and rollback procedures: The exact sequence for updating CI/CD pipelines, pausing writes during the final cutover window, switching DNS, verifying application health, and falling back to the original provider if checks fail during the transition.
Secure data deletion: How you will verify and document that all customer and financial data has been permanently erased from the outgoing cloud provider once the retention and rollback window closes.

4. Roles, budgets, and timelines

An auditor will check whether you have the people and money to execute the plan. Your documentation must define:

Internal responsibilities: Who leads the exit on the business, compliance, and engineering sides.
Resource and budget estimates: Estimated internal engineering hours, external migration tooling or consulting costs, parallel-run infrastructure costs during the transition month, and any early termination fees.
Data egress costs: Under Article 29 of the EU Data Act (Regulation (EU) 2023/2854), cloud providers may charge no more than their direct cost for switching-related data egress until January 12, 2027, and switching charges are banned entirely from January 12, 2027. Your budget assumptions should reflect this timeline.
Step-by-step schedule: A timeline showing how long it takes to provision the target environment, sync data, test applications, and cut over traffic, proving that the total duration fits inside your contractual notice and transition period.

5. Contractual clauses under Article 30(3)(f)

Your technical plan is only valid if your contract backs it up. For critical or important functions, DORA Article 30(3)(f) requires your cloud contract to include:

Clear termination rights and minimum notice periods (including termination scenarios requested by a competent authority).
Mandatory obligations for the cloud provider to assist you during an exit at no additional cost, or at a cost determined ex-ante in the contract.
A sufficiently long mandatory transition period during which the cloud provider must continue delivering services to reduce the risk of disruption while you migrate to another provider.
Provisions ensuring you can easily retrieve all your data in an accessible, machine-readable format.

Most major cloud providers offer a “DORA Financial Services Addendum” to cover Article 30 requirements. You must ensure this addendum is actually signed and referenced in your Register of Information, rather than assuming standard online terms of service cover you.

Practical checklist: DORA cloud exit documentation

Use the table below to verify that your cloud exit strategy covers the requirements of DORA and RTS 2024/1773 before a regulatory audit.

Documentation Area	Regulatory Basis	Specific Evidence Required	Owner
Criticality & Scope	DORA Art. 28(1)–(3); ITS 2024/2956	Mapping of business functions to cloud accounts and services in the Register of Information (RoI).	Risk / Compliance
Exit Policy & Triggers	DORA Art. 28(8); RTS 2024/1773 Art. 10	Documented exit triggers (outage, SLA breach, provider failure, termination) and board/management sign-off process.	CRO / Compliance
Substitutability & Target	DORA Art. 29; ITS 2024/2956	Assessment of provider lock-in, concentration risk, and named alternative cloud provider(s) with EU data residency.	CTO / Architecture
Technical Runbook	RTS 2024/1773 Art. 10	Infrastructure-as-Code (Terraform/OpenTofu) inventory, database replication plan, CI/CD update steps, DNS cutover, and rollback plan.	DevOps / Engineering
Timeline & Budget	RTS 2024/1773 Art. 10	Realistic migration schedule (in days/weeks), estimated parallel cloud costs, and engineering staffing plan.	CFO / Engineering Lead
Contractual Alignment	DORA Art. 30(3)(f); RTS 2024/1773 Art. 8	Signed DORA addendum with mandatory transition period, fixed exit assistance costs, and data retrieval rights.	Legal / Procurement
Review & Test Log	DORA Art. 28(8); RTS 2024/1773 Art. 10	Dated records of periodic plan reviews, tabletop exercises, or technical migration tests, plus remediation of any gaps found.	CTO / Risk

How to test your cloud exit plan without breaking production

Both DORA Article 28(8) and Article 10 of RTS 2024/1773 require that exit plans be “sufficiently tested” and “periodically reviewed”. The regulation applies the principle of proportionality: a 30-person payment institution is not expected to shut down live production traffic to run a multi-million-euro full cutover every year, but a tabletop discussion with no technical verification is rarely enough for critical cloud workloads.

A practical, proportionate testing approach for small and mid-sized financial companies includes three steps:

Maintain Infrastructure as Code (IaC): Keep your network, compute, firewall, and database configurations defined in Terraform or OpenTofu. Audit your codebase twice a year to document any newly introduced proprietary cloud services that would block a clean exit.
Run a dry-run environment build: Once a year, provision a non-production copy of your core infrastructure on your designated alternative EU cloud provider. Deploy your application containers or VMs using your existing CI/CD pipeline to verify that your software builds and starts outside your primary cloud.
Test data restoration and replication: Restore an anonymized snapshot of your production database and a sample of object storage to the alternative cloud environment. Measure the actual data transfer speed, check data integrity, and use those real numbers to update the transition timeline in your exit documentation.

Document the date of the test, the participants, the measured transfer and setup times, any blockers discovered, and the tickets created to fix them. That test report is the exact evidence supervisors ask to see.

Frequently asked questions

Does deploying across multiple AWS or Azure regions count as a DORA exit strategy?

No. Multi-region deployment within the same cloud provider is a business continuity and disaster recovery measure (covered under DORA Article 11), not an exit strategy under Article 28(8). An exit strategy specifically addresses what happens when the provider itself fails, breaches its contract, loses regulatory approval, or must be replaced entirely.

How often must we review and test our cloud exit strategy?

Neither DORA Article 28(8) nor Article 10 of RTS 2024/1773 sets a rigid calendar interval, requiring instead “periodic” review and testing proportionate to the criticality of the service. However, an annual review—and an immediate update whenever you make material changes to your cloud architecture or contract—is the standard practice expected by national supervisors and aligns with the annual ICT risk review cycles in DORA.

What if our cloud architecture uses proprietary services like DynamoDB or BigQuery?

Using proprietary cloud services is not banned under DORA, but you must be honest about it in your documentation. In your Register of Information and Article 29 concentration risk assessment, you must record the lower substitutability and higher migration complexity. Your exit plan must include the time, budget, and engineering steps required to refactor the application to an open alternative (such as PostgreSQL or ClickHouse), and your contractual transition period must be long enough to cover that refactoring work.

Can our cloud provider charge us fees to move our data out during an exit?

Under DORA Article 30(3)(f), any assistance fees from the provider during termination must be either free or clearly set in advance in your contract. Furthermore, under Article 29 of the EU Data Act (Regulation (EU) 2023/2854), cloud switching charges—including data egress fees for switching to another provider—cannot exceed the provider’s direct cost until January 12, 2027, and are completely prohibited starting January 12, 2027.

How MoveInfra can help

Whether you need to document and test a realistic cloud exit plan for DORA compliance or actually execute a migration away from AWS, Google Cloud, Azure, or DigitalOcean, MoveInfra handles the technical work. We analyze your current setup, rebuild your environment as clean Terraform code on an EU-owned cloud (such as UpCloud, Scaleway, Hetzner, or OVHcloud), sync your databases and object storage, and guide your team through a controlled cutover with a 30-day rollback window. Because you keep the generated Terraform code and architecture inventory, your engineering and compliance teams get concrete, tested evidence for your DORA exit documentation.