DORA exit strategy: From contract clause to tested plan
By Arturo Navarro · 27 October 2026
Most entities have a contract with a termination clause and a document called "exit plan". Few can answer the question that matters: if the ICT provider behind a critical function disappears tomorrow, how long does migration take, with which data and to where? Article 28(8) of DORA does not ask for the document. It asks for the capability.
What the exit-strategy rule requires
DORA (Digital Operational Resilience Act) is Regulation (EU) 2022/2554 on digital operational resilience for the financial sector. It requires EU banks, insurers and investment firms to withstand ICT disruptions and threats, respond to them and recover. It has applied since 17 January 2025.Read more → DORA (Regulation (EU) 2022/2554) requires in Article 28(8) exit strategies for ICT services supporting critical or important functions. Three features of the text set the bar:- Scenarios, not just termination. The strategy must cover provider failure, deterioration of service quality, business disruption from inappropriate or failed service provision, and termination under the circumstances of Article 28(7).
- Leave without breaking anything. The entity must be able to exit the arrangement without disrupting its business, without limiting compliance with regulatory requirements and without detriment to the continuity and quality of services to clients.
- Comprehensive, documented, tested and reviewed plans. The text requires identifying alternative solutions, preparing transition plans that allow the contracted functions and data to be removed and transferred securely and with integrity to another provider or brought back in-house, and having contingency measures.
The scope is deliberate: it applies to critical or important functions. For other providers, proportionality decides how much effort is warranted.
The contract is half the exit
An exit strategy without contractual leverage is an intention. Article 30 sets the clauses that support it, and three matter most here:
| Clause | What it secures |
|---|---|
| Art. 30(2)(d) | Access, recovery and return of personal and non-personal data in an easily accessible format if the provider fails, discontinues its business or the contract ends. |
| Art. 30(2)(h) | Termination rights and minimum notice periods. |
| Art. 30(3)(f) | For critical or important functions, exit strategies and a mandatory adequate transition period, during which the provider keeps delivering the service while the entity migrates to another provider or an in-house solution. |
The termination grounds of Article 28(7) complete the picture: significant breach by the provider, circumstances identified in third-party risk monitoring that may alter performance, proven weaknesses in its ICT risk management, and the competent authority being unable to supervise the entity effectively. Exit is not only an escape route after a failure: it is the right that supervision expects to exist.
The contractual policy pushes the requirement down to each arrangement
The implementing standards under Article 28(10) are in Commission Delegated Regulation (EU) 2024/1773, on the detailed content of the policy for contractual arrangements on ICT services supporting critical or important functions. Its Article 10 requires the policy to provide for a documented exit plan for each contractual arrangement, periodically reviewed and tested, covering persistent service interruptions, poor service delivery and unexpected termination, and that is realistic and feasible, with a timeline compatible with the exit and termination terms of the contract.
Two practical consequences. First: the plan is per arrangement, not a generic entity-wide document. Second: the plan timeline and the contractual notice period have to match; a plan that needs twelve months against a contract with three months' notice fails on paper before it fails in practice.
Why most plans do not survive a test
An exit plan usually fails in the same place: it assumes the hard part is the decision, when the hard part is execution.
- Data without portability. The contract promises return, but nobody has extracted a full dump in the agreed format or loaded it into another system.
- Invisible dependencies. The provider is wired into identity, networking, monitoring and data flows that the plan does not inventory. The register of information is the starting point: what is not mapped there will not make it into the plan.
- Nominal alternative. The plan names a second provider that was never assessed or sized, or in-house reintegration without capacity or staff.
- A plan without a test. Article 28(8) requires sufficiently tested plans. A joint read of the plan by IT, compliance and the business is not a test.
How to build a plan that can be executed
A useful plan looks more like a runbook than a policy:
- One plan per critical function and provider, derived from the register, with the service, data and interdependencies identified.
- An assessed alternative: second provider, change of delivery model or reintegration, with its cost, lead time and regulatory requirements, and an explicit decision on the first option.
- Portable data by design: open formats, tested export, and keys or secrets under the entity's control, not the provider's.
- A transition period sized with the contract, and a migration timeline with milestones and owners.
- Periodic testing: from the tabletop exercise to a real data extraction and restore at the destination. What has not been exercised is a hypothesis.
- Trigger-based review: a change of provider, subcontractors or function criticality reopens the plan, not only the annual calendar.
Portability is decided at design time, not at exit
Entities that leave a provider cleanly are those that decoupled identity, access and data from the start. A service whose access is governed by its own identity and policy, and not by the provider's network, changes hosting without redoing security. It is the logic of services without exposed ports.
Conclusion: Exit is demonstrated, not declared
The exit strategy is the hardest part of the third-party framework because it forces an entity to admit a dependency and rehearse its end. Article 28(8) and Article 10 of Delegated Regulation 2024/1773 converge on the same thing: a plan per arrangement, realistic, with a timeline compatible with the contract, and tested. The entity that treats it as an executable runbook turns concentration risk into a decision; the one that treats it as a document discovers its exit plan the day it needs it.
If you need to know where your ICT third-party framework stands, at BlueUP we work DORA operational resilience as architecture, not paperwork. Start by assessing your maturity with the DORA Calculator, review the frame in the practical DORA guide or let's talk about your case.
Which ICT provider could you not replace today?
We review with you one provider behind a critical function: which data and dependencies tie you to it, what the contract says about exit and what would be missing to execute the plan.
Related reading
- DORA register of information: Few pass first time — The third-party inventory every exit plan starts from.
- DORA 2026: a practical guide for financial institutions — The full third-party risk management frame.
- DORA for fintech and insurtech: A 90-day checklist — Where exit fits in a 90-day plan.
- TLPT under DORA: Spain's first testing cycle — Another obligation that is executed, not documented.