DORA Exit Strategies and Exit Plans: Article 28(8) Explained

What Article 28(8) requires

For ICT services supporting critical or important functions, DORA (Regulation (EU) 2022/2554) requires financial entities to put in place exit strategies (Article 28(8)). They must take into account risks such as the provider's failure, a deterioration in service quality, business disruption from inappropriate or failed provision, material risks to the continued deployment of the service, and termination in any of the cases listed in Article 28(7).

You must be able to exit without:

• disruption to your business activities;
• limiting compliance with regulatory requirements;
• detriment to the continuity and quality of services provided to clients.

Exit plans must be comprehensive, documented, sufficiently tested and reviewed periodically, in proportion to your size and risk profile. You must also identify alternative solutions and develop transition plans to remove the contracted services and data from the provider and transfer them securely and in full to another provider or back in-house, with contingency measures to keep the business running in the meantime.

What Delegated Regulation 2024/1773 adds

Commission Delegated Regulation (EU) 2024/1773 sets the content of your policy 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, with periodic review and testing. The plan must take into account:

• unforeseen and persistent service interruptions;
• inappropriate or failed service delivery;
• unexpected termination of the contract.

And it must be realistic, feasible, based on plausible scenarios and reasonable assumptions, with an implementation schedule compatible with the exit and termination terms in the contract.

The contract must make exit possible

See the full clause list in our DORA Article 30 contract checklist.

Writing an exit plan you could actually run

1. Scope: the service, the functions it supports, the data held, and the integrations that depend on it.
2. Triggers: the scenarios above, plus contractual triggers, each with who decides to activate the plan.
3. Target: the alternative provider or in-house option, why it is realistic, and any lead time to contract it.
4. Data: what is exported, in which format, how completeness and integrity are verified, and how the provider deletes its copies.
5. Steps and timeline: migration tasks with owners, aligned to the notice and transition periods in the contract.
6. Continuity measures: what keeps critical functions running during the switch, and how clients are informed if needed.
7. Costs and resources: people, budget and dual-running costs.
8. Testing and review: how and when you test it (a tabletop exercise, a data export test, a partial migration), and when you review it.

Keep the register consistent: the register of information records for each service supporting a critical or important function whether an exit plan exists, how substitutable the provider is, and whether the service could be reintegrated. See the register of information guide.

Start from a template. The Vendor Security Assessment Pack includes a vendor exit plan template, a security requirements addendum with a DORA Article 30 clause, a risk register and an onboarding checklist.

Sources

• Regulation (EU) 2022/2554 (DORA), Articles 28 and 30, EUR-Lex
• Commission Delegated Regulation (EU) 2024/1773: policy on ICT services supporting critical or important functions, EUR-Lex

Related tools