DORA Article 28(8) requires financial entities to have exit strategies for ICT services that support critical or important functions. The plan must let the entity leave a provider without disrupting business, breaching regulation or harming service to clients, and must be documented, tested and reviewed. Contract terms in Article 30 are meant to make that possible.
What the article requires
Exit strategies must take into account risks at the provider, in particular failure, deteriorating service quality, business disruption from failed provision, and termination of the contract. Entities must be able to exit without:
- disruption to business activities;
- limiting compliance with regulatory requirements;
- detriment to the continuity and quality of services to clients.
Exit plans must be comprehensive, documented and, in line with proportionality, "sufficiently tested and reviewed periodically". Entities must identify alternative solutions and build transition plans to remove the services and data from the provider and securely and integrally transfer them to alternatives or back in-house. Contingency measures must keep the business running if an exit becomes necessary.
Triggers for termination
Article 28(7) says contracts must allow termination in cases including a significant breach of law or contract, circumstances found in monitoring that could alter performance, evidenced weaknesses in the provider's ICT risk management and data security, and cases where the competent authority can no longer effectively supervise the entity because of the arrangement.
What a useful exit plan contains
- Scope: the service, the function it supports, and why it is critical or important.
- Exit scenarios: planned (contract end), provider failure, forced termination, regulator instruction.
- Alternatives: other providers or in-house options, and what each would need.
- Data and configuration: what must be extracted, in what format, and how integrity is checked. Article 30 asks for return of data in an easily accessible format.
- Dependencies: integrations, identity, networking, and third parties that rely on the service.
- Timeline and roles: who does what, and a realistic duration.
- Transition period: the contract must provide for continued service while you move (Article 30(3)(f)).
- Test records: results of tabletop or partial migration tests.
Testing without a full migration
Full migrations are expensive. Useful partial tests include restoring a backup of your data into an alternative environment, exporting data in the agreed format and loading it elsewhere, and a tabletop covering a provider outage lasting several days. Record what failed and update the plan.
The software angle
Lock-in often hides in proprietary APIs, data formats and build tooling. Open standards, portable infrastructure definitions and documented configuration make exit cheaper. Your dependency inventory and SBOM show where you rely on a single provider's SDKs.
Safeguard's SBOM and dependency scanning and asset discovery can help map those technical dependencies. The exit decision and plan remain a business and risk function.
Quick check
Do exit strategies apply to every ICT provider?
Article 28(8) applies to ICT services supporting critical or important functions. Other arrangements follow the general proportionality principle.
Is a paper plan enough?
The text asks for plans that are "sufficiently tested and reviewed periodically", so some testing is expected.
Sources
Last reviewed: 19 October 2026.
