Ask yourself one question about your most important ICT provider: if you had to leave them in twelve months, could you? If the honest answer is no, you do not have a provider. You have a dependency. Supervisors have a word for it: vendor captivity.
That is what Article 28(8) of DORA is about. It requires exit strategies for ICT services supporting critical or important functions. One year into supervision, "no credible exit" is becoming a standard inspection finding, and it usually surfaces right after the questions about subcontracting chains and concentration on the big cloud providers.
What Article 28(8) actually requires
The rule applies to every ICT service supporting a critical or important function. For those services you must have an exit strategy that covers the realistic ways a relationship ends badly:
- the provider fails
- service quality drops below what you can accept
- the service is disrupted or delivered wrongly
- the contract is terminated, by either side
The goal is stated plainly in the regulation: you must be able to leave without disrupting your business, without breaking regulatory compliance, and without hurting the continuity and quality of your services to clients.
And the plans themselves have qualities attached. They must be comprehensive, documented, sufficiently tested, and reviewed periodically. Each of those words is an inspection question waiting to happen.
Strategy and plan are two different documents
A useful way to structure the work: the exit strategy is the policy level. It says which services need plans, what triggers an exit, and who decides. The exit plan is per service. It is the runbook you would actually follow. A typical plan contains:
- Triggers. What starts the exit: insolvency signals, repeated SLA breaches, a failed remediation, a regulatory order, a terminated contract.
- Alternatives. Which providers or in-house options could take over, and how far you are from being able to use them. This is where the transferability assessment from your subcontracting due diligence pays off twice.
- Transition plan. Steps, roles and a realistic timeline for moving the service, including knowledge transfer and parallel running.
- Data. How you get your data out, in what format, how it is deleted at the old provider, and how the transfer is secured.
- Costs and resources. What an exit costs and who does the work. An exit plan nobody could staff is a document, not a plan.
The contract has to support all of this. Article 30(3)(f) requires transition assistance clauses for critical services: the provider must keep delivering during a transition period and help you move. If your contract lacks that clause, your exit plan rests on goodwill.
💡 A paper plan is not a tested plan. "Sufficiently tested" does not mean you must actually migrate. A desktop exercise works: put the team in a room, trigger the scenario, and walk the plan step by step. You will find the gaps in an afternoon, and the exercise itself is the evidence supervisors ask for. Put it in the annual review cycle and log it.
The concentration angle
Exit strategies are also how supervisors read your concentration risk. If three of your critical services sit on the same hyperscaler and all three exit plans say "migrate to another cloud" without naming one, you have not spread the risk. You have written the same wish three times. Realistic alternatives, named and assessed, are what separate an exit strategy from a disclaimer.
Building yours in four steps
- Scope. List ICT services supporting critical or important functions from your Register of Information. That list is the exact set of services needing a plan.
- Prioritise. Rank by how hard the exit would be: proprietary tech, data volume, chain length, contract terms. Hardest first.
- Write and fix. Draft the plan per service. Where the contract lacks transition assistance, queue it for remediation.
- Test and review. One desktop exercise per critical service, then a periodic review with an owner and a deadline.
How DORA GRC helps
In DORA GRC, exit strategies live where the rest of the provider picture lives. Each plan is linked to the service, the contract and the function it protects, so scope is never a guess. Review tasks with owners and deadlines keep the periodic testing and review requirement on track, and the 360° Intelligence Hub shows where concentration makes an exit plan urgent rather than theoretical.
Sources: Regulation (EU) 2022/2554 (DORA), Articles 28(8) and 30(3). Commission Delegated Regulation (EU) 2025/532 on subcontracting. ESAs joint guidance and NCA inspection themes on third-party risk, 2025 to 2026.