The DORA exit plan: What it must contain and why it must be tested

Part 2 of 7 of our DORA series for banks. After Part 1 put the basic logic of DORA into perspective, this part is about the concrete counter-check for every outsourcing arrangement: Can the bank actually leave a service provider without uncontrollably endangering a critical or important function?

Author: acceleraid Editorial Team

An exit plan is not a termination template

An exit plan is often confused with a contract clause or a migration list. According to DORA, it is neither. For ICT services supporting critical or important functions, Article 28(8) requires exit strategies. The wording is clear: "Exit plans shall be comprehensive, documented and, in accordance with the criteria set out in Article 4(2), sufficiently tested and regularly reviewed." The obligation includes alternative solutions and transition plans by which services and associated data can be safely and completely transferred to another provider or taken back internally. (EUR-Lex, Article 28 DORA)

The correct management question is therefore not: "Do we have an exit?" But rather: "Can the designated persons, under realistic conditions, migrate the function, the data, and the evidence of control within a reasonable transition period?" Only this question separates a verifiable plan from a document in the contract archive.

Which services fall into this core set of obligations is not determined by the product name. The decisive factor is whether the outsourcing supports a critical or important function. The assessment logic required for this is explored in depth in Part 7 of the series on critical and important banking functions. For every service classified in this way, the exit plan should already be available before go-live as part of the operational approval. (ECB, Cloud outsourcing guide)

The contract is the technical prerequisite for the exit

An exit can only work if the contract secures the necessary rights and information. Article 30(2) requires, among other things, details of service delivery and data processing locations, the return of data in an easily accessible format, and termination rights. For critical or important functions, paragraph 3 adds performance targets in the SLA, contingency plans, ongoing monitoring, as well as exit strategies with a binding appropriate transition period.

This results in a robust minimum content. A plan should name the supported function and its dependencies, describe data classes and export formats, assign roles and necessary expertise, and include milestones, cost assumptions, and success criteria. It also needs pre-defined triggers: such as serious breaches of contract, identified weaknesses in ICT risk management, or the obstruction of supervisory control. For such circumstances, DORA specifies termination obligations.

The technical supply chain must not disappear behind the main contract. Delegated Regulation (EU) 2025/532 requires an assessment of the nature of the services, locations, length and complexity of the subcontractor chain, data types, third-country involvement, concentration, and potential impairment of portability before contract conclusion. Access and audit rights must extend down to subcontractor level; material changes require effective consent, objection, or termination rights. (EUR-Lex, Delegated Regulation (EU) 2025/532)

Testing obligation: What supervision considers robust

DORA demands sufficient testing; it does not prescribe a rigid annual interval. However, the ECB Guide on cloud outsourcing concretizes supervisory expectations: exit plans should be reviewed and tested regularly, taking into account the proportionality principle. This is the benchmark against which an institution should demonstrate practical feasibility.

As a minimum level, the ECB names an in-depth desktop review by staff with sufficient cloud expertise. In doing so, data volume, application complexity, and the method of data transfer must be reviewed so that time estimates become robust. This is not a mere reading of documents: it is a structured plausibility check of whether the details regarding the exit match technically and organizationally.

This should be followed by a walkthrough. The persons involved go through tasks, dependencies, approvals, and communication paths, thereby showing that the plan does not depend on individual experts. For the most critical migration steps, the ECB considers periodic tests to be good practice; the feasibility of each plan should be verified independently of the persons who created it. (ECB, Cloud outsourcing guide: Testing of exit plans)

The EBF test typology helps to scale this effort appropriately. It distinguishes between table-top tests, walkthroughs, desktop exercises, and simulations; a simulation can include data extraction, transformation, and import. The paper does not demand a real migration for every SaaS case and evaluates real data operations there as disproportionate. For this very reason, a test design should justify precisely what is being tested, what is being simulated, and what open uncertainty remains. (EBF, Cloud exit strategy — testing of exit plans)

Data portability sets a rhythm, but does not replace a test

The Data Act provides important timeframes for certain cloud-switching scenarios. The maximum transition period is 30 calendar days, the maximum notice period is two months. In the event of technical impossibility, this must be notified within 14 working days; an alternative transition period may not exceed seven months. From January 12, 2027, switching charges may no longer be levied. (EUR-Lex, Regulation (EU) 2023/2854, Articles 25 and 29)

These deadlines do not automatically make portability easy. Article 30 of the Data Act requires open interfaces without charge as well as export in a structured, commonly used, and machine-readable format, but explicitly limits this through the protection of intellectual property and trade secrets. In addition, highly customized services and non-production versions are excluded from the scope of application, and data egress costs can be passed on in the case of parallel use. (EUR-Lex, Data Act Articles 30, 31 and 34)

For personal data, Article 20 of the GDPR supplements the right to a structured, commonly used, and machine-readable format as well as to direct transmission, provided this is technically feasible. For the DORA exit, this is useful, but not sufficient: it must also cover integrations, authorizations, operational knowledge, evidence, and the controlled cutover. (EUR-Lex, GDPR Article 20)

A playbook for a testable exit

A practical playbook connects law, architecture, and operations in six steps. First: clearly define the function and dependencies. Second: cross-reference the contract and subcontractor chain against data flows, locations, and audit rights. Third: choose a concrete target state — alternative provider or in-house operations — and verify its suitability. Fourth: plan the migration steps with responsible parties, data volumes, security controls, time, and cost assumptions. Fifth: conduct desktop reviews, walkthroughs, and risk-adjusted simulations. Sixth: evaluate results independently, close gaps, and update the plan.

Prioritization should be risk-based, not calendar-driven. Supervisory data shows how challenging the topic is: the share of outsourced critical functions that are difficult or impossible to substitute rose from 80 to 82 percent; 95 percent of these are considered difficult or impossible to reintegrate. (ECB, Cloud outsourcing and concentration risk)

Part 3 examines the resulting cloud dependency of European banks. Part 5 shows why a complete register of information is the prerequisite to make contracts and supply chains testable in the first place. The core remains: an exit plan is only credible when responsible parties, data, contracts, and transition steps come together in an exercise.

The DORA series at a glance

• Part 1: DORA for banks: What the EU regulation governs and how it works

• Part 2: The exit plan according to DORA: What it must contain and why it must be tested (this article)

• Part 3: Cloud dependency of European banks: How to get away from AWS, Microsoft, and Google if necessary

• Part 4: Exit option for customer engagement workloads: Securing CDP, personalization, and campaigns in a DORA-compliant manner

• Part 5: The DORA register of information: Why it is actually a data quality problem

• Part 6: AI providers as a new concentration risk: What DORA means for model dependencies

• Part 7: Critical or important? Risk levels from core banking to CRM, data lake, and CDP

Illustration: AI-generated. AI-supported content: In creating our articles, we use AI technologies and automated agents, including those from Microsoft, Google, OpenAI, Anthropic, and other providers. Topics, technical direction, and final approval rest with our team.