Last updated: 29 October 2026
Quick answer: A DORA exit strategy is the documented plan a financial entity keeps for every ICT service supporting a critical or important function, so it can leave that provider without business disruption or regulatory breach. Article 28(8) of DORA requires it, and Delegated Regulation (EU) 2024/1773 adds a documented, periodically reviewed and tested exit plan per contract.
Most financial entities spent 2025 building their register of information and renegotiating contracts. In 2026 supervisors are asking a harder question: if your cloud, core banking or payments provider failed tomorrow, could you actually leave? A DORA exit strategy is how you answer that with evidence rather than optimism.
This guide explains what the regulation requires, how the technical standards add detail, what a realistic exit plan contains, and how to test it.
What is a DORA exit strategy?
It is a documented approach for leaving an ICT third-party service provider safely, prepared in advance for each ICT service that supports a critical or important function. It covers why you might need to exit, where the service would go, and how you would move data and operations without harming clients or compliance.
Article 28(8) of the Digital Operational Resilience Act (Regulation (EU) 2022/2554) says financial entities “shall put in place exit strategies” for ICT services supporting critical or important functions. The strategy must let the entity exit contractual arrangements without disruption to its business activities, without limiting compliance with regulatory requirements, and without detriment to the continuity and quality of services provided to clients.
The same paragraph requires exit plans to be comprehensive, documented and sufficiently tested and reviewed periodically. It also expects you to identify alternative solutions and develop transition plans so you can remove the contracted services and transfer the relevant data securely to an alternative provider or back in-house.
DORA has applied since 17 January 2025, so these are live obligations. Remember that Article 28(1) keeps the financial entity fully responsible for compliance at all times, whatever it outsources.
Which scenarios must the exit strategy cover?
Article 28(8) lists the risks your strategy has to take into account. Delegated Regulation (EU) 2024/1773 then lists the scenarios the exit plan itself must handle.
| Source | Scenarios to plan for |
|---|---|
| DORA Art. 28(8) | Provider failure; deterioration of service quality; business disruption from inappropriate or failed provision of ICT services; material risks to the appropriate and continuous deployment of the service; termination of the contract under Art. 28(7) |
| DORA Art. 28(7) | Termination triggers: significant breach of laws, regulations or contract terms; circumstances identified in monitoring that could alter the service; evidenced weaknesses in the provider’s ICT risk management; and situations where the competent authority can no longer effectively supervise the entity because of the arrangement |
| RTS 2024/1773 Art. 10 | Unforeseen and persistent service interruptions; inappropriate or failed service delivery; unexpected termination of the contractual arrangement |
Common mistake: Writing one exit scenario, usually a planned, friendly migration at contract end. Supervisors expect you to plan for stressed exits too, such as a provider insolvency or a sudden termination, where you have far less time and much less cooperation.
What does the RTS on ICT third-party policy add?
Commission Delegated Regulation (EU) 2024/1773, adopted on 13 March 2024, sets the detailed content of the policy on ICT services supporting critical or important functions. Its Article 10 turns the exit strategy into a per-contract plan.
According to the published text of Delegated Regulation 2024/1773, the policy must contain requirements for a documented exit plan for each contractual arrangement, and for the periodic review and testing of that plan. The exit plan must be realistic, feasible, based on plausible scenarios and reasonable assumptions, and have a planned implementation schedule compatible with the exit and termination terms in the contract.
Two practical consequences follow:
- Contract and plan must match. If your contract gives 90 days’ notice but your plan needs nine months, the plan is not compatible with the termination terms.
- Assumptions must be defensible. A plan that assumes an alternative provider can onboard you in four weeks needs some evidence, such as market analysis or supplier conversations.
How do contracts support a DORA exit strategy?
Your exit strategy is only as strong as the contract behind it. Article 30 of DORA sets the minimum contractual provisions, and several of them exist specifically to make exit possible.
- Termination rights and minimum notice periods (Art. 30(2)(h)), in line with the expectations of competent and resolution authorities.
- Access, recovery and return of data in an easily accessible format if the provider becomes insolvent, is resolved, discontinues its business or the contract ends (Art. 30(2)(d)).
- Exit strategies, in particular a mandatory adequate transition period for services supporting critical or important functions (Art. 30(3)(f)). During that period the provider keeps delivering the service so you can migrate to another provider or in-house.
In practice: Define the transition period in months, not in vague terms such as “reasonable assistance”. Link it to the migration timeline in your exit plan, and specify the data formats, documentation and knowledge transfer the provider must deliver.
What should a DORA exit plan contain?
A good exit plan reads like a runbook that someone else could execute under pressure. Use this template for each ICT service supporting a critical or important function.
| Section | What to document |
|---|---|
| Service and function | ICT service, provider, contract reference, critical or important functions supported, link to the register of information entry |
| Triggers | Events that start the plan, mapped to the Art. 28(7) and 28(8) scenarios, and who can invoke it |
| Exit options | Named alternative providers, in-house reintegration, or a hybrid, with pros, cons and lead times |
| Data and assets | What data, configurations, code and keys must be retrieved, in which formats, and how deletion at the provider is confirmed |
| Transition timeline | Phased steps from trigger to full cut-over, aligned with notice and transition periods in the contract |
| Interim continuity | Workarounds, manual processes or contingency measures if the service stops before migration completes |
| Resources and budget | People, skills and funding needed, and who approves spend in a stressed exit |
| Communication | Internal escalation, clients, the competent authority and the provider |
| Testing and review | Test method, last test date, findings and next review date |
| Ownership | Accountable owner, approver and date of management approval |
Keeping these plans next to your vendor records and risk assessments makes them easier to maintain. Enactia’s AI-powered GRC platform links vendors, contracts, risks and DORA controls in one place, so a change to one provider shows up in its exit plan, risk entry and register data. To see how that works for your provider portfolio, start your 14-day free trial.
How does the register of information reflect exit planning?
The register of information asks you to record, for each ICT service, whether an exit plan exists and how replaceable the provider is. That means supervisors can see gaps in your exit planning directly from your register submission.
The EBA data model for the DORA register of information includes, in template B_07.01 on the assessment of ICT services, fields for:
- substitutability of the ICT third-party service provider, and the reason if it is hard or impossible to substitute;
- existence of an exit plan;
- possibility of reintegration of the contracted ICT service;
- impact of discontinuing the ICT services;
- whether alternative providers have been identified, and who they are.
Those answers must be consistent with your exit plans. If the register says an alternative provider exists but the exit plan names none, expect questions. Our DORA register of information guide covers the templates and data quality checks in more detail.
Does the CTPP oversight regime change your exit planning?
No. Direct oversight of critical ICT third-party providers by the European Supervisory Authorities adds scrutiny of those providers, but it does not remove your own obligations under Article 28.
On 18 November 2025 the ESAs designated the first critical ICT third-party providers under DORA. The designation criteria include the provider’s systemic importance, its role in supporting critical or important functions and the level of substitutability of its services.
The providers most likely to be designated are often the hardest to exit, such as large cloud platforms, so a credible exit strategy matters more, not less. Our article on why vendor risk is now an executive liability explains the governance side. For these services, a realistic plan may focus on multi-region or multi-provider architecture, portable data formats and a staged reduction of dependency, rather than an overnight switch.
How should you test a DORA exit plan?
Test in proportion to risk and complexity, and keep evidence of every test. DORA and the RTS require periodic testing and review but leave the method to you.
- Desk review: Check the plan against the current contract, register entry, architecture and team. Fix outdated contacts, formats and assumptions.
- Tabletop exercise: Walk a stressed scenario, such as provider insolvency, with business, IT, legal, procurement and risk. Time each decision.
- Data extraction test: Retrieve a representative data set in the contractual format and confirm you can load and use it elsewhere.
- Partial migration or failover: For the most critical services, move a workload or run a failover to an alternative environment.
- Lessons learned: Record findings, assign owners and dates, and update the plan and risk assessment.
Link test findings to your wider ICT risk management so that a failed data extraction test raises the residual risk of that provider rather than sitting in a separate spreadsheet.
DORA exit strategy checklist
- A list of every ICT service supporting a critical or important function, reconciled with the register of information.
- An exit strategy in your ICT third-party risk policy, approved by the management body.
- A documented exit plan per contractual arrangement covering the Art. 28(8) and RTS Art. 10 scenarios.
- Named alternative providers or an in-house option, with lead times.
- Contract clauses for termination rights, notice periods, data return and a defined transition period.
- Interim continuity measures if the service stops before migration completes.
- Test evidence and a review date for each plan.
- Consistent B_07.01 register answers on substitutability, exit plan, reintegration and alternatives.
A structured vendor and third-party risk management process keeps this checklist current across many providers.
Key takeaways
- Article 28(8) of DORA requires exit strategies for every ICT service supporting a critical or important function.
- Delegated Regulation 2024/1773 requires a documented, realistic exit plan per contract, reviewed and tested periodically.
- Contracts must support exit with termination rights, data return and a mandatory adequate transition period.
- Register of information answers on exit plans and substitutability must match your actual plans.
- CTPP oversight does not reduce your own exit planning duties, and hard-to-substitute providers need the most work.
Frequently asked questions
Is a DORA exit strategy required for every ICT provider?
No. Article 28(8) requires exit strategies for ICT services supporting critical or important functions. For other ICT services you still manage third-party risk under your wider policy, and many entities apply a lighter exit approach to them. The detailed per-contract exit plan in Delegated Regulation 2024/1773 applies to arrangements supporting critical or important functions.
What is the difference between an exit strategy and an exit plan?
The exit strategy is the entity-level approach in your ICT third-party risk policy: principles, scenarios, governance and testing expectations. The exit plan is the service-specific document for one contractual arrangement, with triggers, alternatives, data transfer steps, timelines, owners and test evidence. DORA requires both, and the plans must be consistent with the strategy.
How often should DORA exit plans be tested?
DORA and the RTS require periodic review and testing but do not set a fixed frequency. Base the cycle on criticality and change, for example reviewing plans at least yearly and after major contract, architecture or provider changes. Document the test method, date, findings and remediation so you can show supervisors the plan works in practice.
Can we exit to an in-house solution instead of another provider?
Yes. Article 28(8) expressly allows transferring services and data to alternative providers or reincorporating them in-house. If you choose reintegration, the plan must show that you have or can obtain the skills, infrastructure and budget in time, and the register of information should reflect the possibility of reintegration for that service.
What if no realistic alternative provider exists?
Document that honestly, including the reason, because the register of information asks why a provider is difficult or impossible to substitute. Then strengthen the other levers: contractual transition periods, portable data formats, multi-region or multi-provider designs, interim manual processes and closer monitoring. Your risk assessment should show the residual concentration risk the management body is accepting.
Making your exit strategy credible
A DORA exit strategy is not a document you write once to satisfy an auditor. It is proof that your organisation can survive losing a key provider. Start with the services supporting your most critical functions, align contracts and plans, test the riskiest assumptions, and keep your register of information consistent with what you find.
Enactia’s DORA compliance tools help you manage providers, exit plans, risks and register data together. To discuss your programme, contact us or book a demo or start your 14-day free trial.
This article is for general information and is not legal advice.
