DORA Exit Strategy: 6 Proven Steps for Article 28(8)

A DORA exit strategy is not a clause you add to a contract and forget. Article 28(8) requires the plan to be documented, tested, and capable of moving your data as well as your service — and Article 30(3)(f) puts a matching obligation on the supplier that has to be negotiated before signature.

Most firms have written a DORA exit strategy on paper. Far fewer could execute it, and the Regulation asks for the second thing.

Which suppliers need a DORA exit strategy

Article 28(8) applies to ICT services supporting critical or important functions. Not every supplier, and not every ICT service.

That makes your critical-or-important-function determinations the gate. Get them wrong and you either build exit plans you did not need or, more commonly, miss a provider whose loss would actually stop you trading. It is the same determination that drives the register of information, which is the practical reason to settle it once and reuse it.

Five triggers a DORA exit strategy must anticipate

Article 28(8) says the exit strategies shall take into account risks that may emerge at the level of ICT third-party service providers — in particular:

• a possible failure on their part;
• a deterioration of the quality of the ICT services provided;
• any business disruption due to inappropriate or failed provision;
• any material risk to the appropriate and continuous deployment of the service; and
• termination of the arrangement in any of the paragraph 7 circumstances.

Only one of those is insolvency. A DORA exit strategy built solely around “what if they go under” misses the four scenarios that are far more likely — most of all quality deterioration, which is a slow trigger nobody wants to pull.

The paragraph 7 termination rights are worth reading alongside it. Contracts must be terminable on significant breach of law, regulation or terms; on monitoring findings capable of altering the performance of the function; on evidenced weaknesses in the provider’s overall ICT risk management, particularly in how it ensures availability, authenticity, integrity and confidentiality of data; and where your competent authority can no longer effectively supervise you because of that arrangement.

The DORA exit strategy test is stricter than it looks

Article 28(8) requires financial entities to ensure they are able to exit without:

• (a) disruption to their business activities;
• (b) limiting compliance with regulatory requirements; and
• (c) detriment to the continuity and quality of services provided to clients.

Read (a) and (c) literally. A DORA exit strategy that involves a planned outage window, or degraded service while a migration completes, does not meet that standard. This is the sentence that turns an exit strategy from a legal document into an architecture requirement — because portability has to be designed in, not arranged afterwards.

And the plans must be comprehensive, documented and, in accordance with the proportionality criteria in Article 4(2), sufficiently tested and reviewed periodically. Tested. That word does the same work here as it does in the business continuity provisions.

A DORA exit strategy has to bring your data back

The obligation is explicit: identify alternative solutions and develop transition plans enabling you to remove the contracted ICT services and the relevant data from the provider and to securely and integrally transfer them to alternative providers or reincorporate them in-house.

Three words carry the weight. Securely — the transfer itself is a risk event. Integrally — the whole dataset, not the parts that happen to be exportable. And alternative solutions — identified in advance, because “we would run a procurement” is not an alternative solution.

This is where most exit plans fail on inspection. The service is portable; the data model is not. Bulk export produces something no other provider can ingest without a project, and the project takes longer than the transition period.

The DORA exit strategy has to be in the contract

Article 30(3)(f) is the half that cannot be fixed unilaterally. Contractual arrangements for ICT services supporting critical or important functions must include exit strategies, in particular the establishment of a mandatory adequate transition period:

• during which the provider will continue providing the functions or services, to reduce the risk of disruption or ensure effective resolution and restructuring; and
• allowing the financial entity to migrate to another provider or change to in-house solutions, consistent with the complexity of the service.

So the provider is contractually obliged to keep serving you while you leave. That is a negotiation, and it is much harder after signature than before — which makes exit a procurement requirement rather than a compliance afterthought.

“Consistent with the complexity of the service” is the phrase to argue with. A complex service needs a longer mandatory period, and the burden of showing what is adequate sits with you.

How to test a DORA exit strategy without executing it

Nobody migrates a core provider to prove they can. What is testable:

• Produce a full data extract and confirm an alternative provider or in-house system can actually ingest it.
• Walk the transition plan against the contractual transition period and check the elapsed time fits.
• Confirm the alternative solution still exists and remains commercially viable — vendors get acquired.
• Test the decision path: who declares quality deterioration serious enough to trigger exit, and on what evidence.
• Check the contingency measures Article 28(8) requires for maintaining business continuity while the trigger is live.

How the DORA exit strategy connects

Where to start

1. Settle the critical or important function determinations, because they scope everything else.
2. Negotiate the Article 30(3)(f) transition period before signature, and argue for length on complexity.
3. Name an alternative in the DORA exit strategy for each in-scope service, and revisit it annually.
4. Prove the data moves, in a format something else can ingest.
5. Design for exit without disruption, since (a) and (c) leave no room for a migration outage.
6. Test the plan and record the test, because Article 28(8) requires it and inspection will ask.

This guide reflects Regulation (EU) 2022/2554 as published on EUR-Lex, read at 16 August 2026. Regulatory technical standards add detail on contractual content — check the current position with your competent authority.

The DORA Toolkit provides 100+ editable templates covering the exit strategy and transition plans, the critical or important function determinations, the ICT third-party contractual requirements and the register of information.