DORA exit strategies: what the rules require

What DORA exit strategies and exit plans require from financial entities

Article 28(8) of DORA requires a financial entity to have documented and tested exit strategies and transition plans for every ICT service that supports a critical or important function, and Article 30(3) requires the contract for those services to include an exit strategy with a mandatory, adequate transition period. If your organization depends on a provider for such a service, you must be able to show a supervisor how you would leave that provider and that the plan has been tested. The exit plan belongs to the financial entity. The management body should approve it, business units should set the transition needs, and risk and continuity owners should keep it current. An implementation partner can prepare the systems, runbooks, data inventories and test evidence that support the plan, but a partner cannot decide whether the plan is adequate. That judgment belongs to the competent authority during supervision, or to an independent assessor where one is engaged. The regulation text is available in Article 28 of DORA.

Three factors change how much work the plan needs. The first is the classification of the service: whether it supports a critical or important function decides if the full Article 28(8) and Article 30(3) requirements apply, so the function assessment must come before the exit design. The second is substitutability. A service that another vendor, or an in-house system you already operate, can replace needs a shorter and simpler transition than a proprietary platform that stores your data in a format only that vendor can read. Self-hosted open-source components often lower this barrier because data and configuration stay in your environment, but the replacement path still has to be exercised. The third is the contract. Termination rights under Article 28(7), data return on termination, incident and cooperation duties that continue during exit, and a transition period long enough to finish the migration all need to be in place. A plan cannot compensate for a contract that omits them.

Before commissioning work, confirm four things in writing: which ICT services in your register support critical or important functions, which of those providers you could replace within a period your business can tolerate, whether each contract gives you the termination and data return rights the regulation expects, and who signs off the test results. A partner can scope a fixed set of deliverables around those answers, such as exit runbooks, data migration tests and a continuity exercise that considers provider failure. Ask any quote to state what each deliverable is, what evidence it produces, and what stays with the organization, including legal review of contracts and negotiation with providers. Because an assessor will test the plan against your actual services, build it from your own register and dependency map, not from a generic template.

Which contract clauses DORA expects so an exit is possible

An exit from an ICT provider is only workable if the contract allows it. The clauses below map to the articles that shape termination, data return, transition, access and cooperation, and each card lists what the clause must let the entity do on exit and what to check in the draft.

Termination rights

Article 28(7) expects the contract to let the entity terminate for significant breaches, for circumstances that could alter performance, for evidenced weaknesses in the provider's ICT risk management, and where conditions prevent effective supervision. Check that each trigger appears as a named termination right with a notice period, not only as a general clause on breach. Confirm that the entity can act on these triggers without waiting for a cure period that runs past the point where continued use is unsafe.

Data return on exit or insolvency

Article 30(2) requires the contract to cover data protection and the return of data when the contract ends or the provider becomes insolvent. On exit, the entity must be able to retrieve its data in a usable form and within a defined window. Check the format and completeness of the return, who bears the cost, what happens to backups and subcontractor copies, and whether deletion is certified after return.

Mandatory transition period

Article 30(3) requires exit strategies with a mandatory adequate transition period for services supporting critical or important functions. The transition period must be long enough to move the function to another provider or in-house. Check that the contract states the period, that it can be extended if the replacement is not ready, and that the provider must keep the service running at agreed levels during that time.

Documented exit strategy

Article 30(3) also requires an exit strategy written into the arrangement, which Article 28(8) pairs with tested transition plans. The contract should oblige the provider to support the plan, including exporting configurations, supplying documentation and naming personnel for handover. Check that the exit strategy is attached or referenced, reviewed when the service changes, and linked to the continuity tests the entity runs.

Unrestricted access, inspection and audit

Article 30(3) requires unrestricted access, inspection and audit rights for the entity and its competent authority. These rights matter on exit because the entity needs evidence that data was returned and deleted and that the service was run correctly until the end. Check that the rights extend to subcontractors, that they are not limited to annual reviews, and that they survive termination for a defined period.

Incident assistance and cooperation

Article 30(2) requires incident assistance at no cost or at a pre-agreed cost, and cooperation with competent authorities. During an exit, incidents often happen as data moves, so the entity needs support for reporting and recovery. Check that assistance continues until the transition ends, that costs are fixed in advance, and that the provider must cooperate with authorities after termination where the regulator requests it.

Which ICT services need a documented, tested exit plan

The exit plan duty follows the classification of the function, not the size of the contract. Article 28(8) of DORA requires documented, tested exit strategies and transition plans for ICT services that support critical or important functions. A small contract with a niche provider can therefore need a full exit plan, while a large, widely used service that supports nothing critical may not. The first step is the critical or important functions decision, which should be made and recorded before anyone drafts an exit plan. Use the function assessment to list every ICT service that supports each critical or important function, including services that sit underneath the function, such as identity, logging, backup and hosting. Confirm with your own legal and risk teams how the classification has been documented in your policy, because that record is what an assessor will check first.

Size is a poor guide for a second reason. A single provider often supports several functions, and a single function often depends on several providers. An operator running a self-hosted platform through one support provider may find that provider underpins payments, customer onboarding and regulatory reporting at once. In that case the exit plan has to cover each service that supports each function, not only the headline contract. Map provider to function to service in the register of information, and check that the register and the exit plans describe the same relationships. Where a provider holds data or components for several functions, plan the exit as one exercise with several transition streams, so that the sequencing of data return and replacement does not break a function that is still running.

Classification also sets what the policy and the register must show. Services that support critical or important functions carry the strongest contract requirements, the tested exit strategy and the transition period expected under the contract terms. The register should identify which entries are linked to such functions, so that a supervisor can see, without reconstruction, where the exit obligations apply. Keep the classification rationale under version control and review it when a function changes, a provider is added or a service is moved to a new platform. Ask your legal team to confirm how the requirements in the relevant regulatory technical standards apply to your entity type before you finalize the scope.

How to build and test an exit plan for a critical ICT provider

This sequence turns a provider dependency into a documented, owned and tested exit plan that the entity's governance can approve and keep current. Each phase produces an artifact that the next phase relies on.

Classify the services and link them to functions
Start by listing every ICT service the entity receives from each provider, then map each service to the critical or important functions it supports. The entity owns this step, with business owners and the risk function confirming which functions depend on which services. It is done when every service that supports a critical or important function has a named owner and a recorded link to that function in the service inventory.
Map dependencies and data flows
Document the systems, data sets, integrations, subcontractors and locations that sit behind each in-scope service. Include where data is stored and processed, which credentials and keys the provider holds, and what other providers the chain depends on. The output is a dependency and data map that shows what would have to move, be rebuilt or be deleted on exit. It is done when technology and data owners have reviewed the map against the live environment.
Assess substitutability and alternative providers
For each in-scope service, assess whether an alternative provider, an internal solution or a self-hosted open-source platform could take over the function, and what would be needed to do so. Record the realistic options, their gaps, and the concentration risk if several functions depend on one provider. Where the answer is that no substitute exists, record that finding explicitly and the risk acceptance that follows from it. It is done when each service has a documented substitutability assessment approved by the risk owner.
Write the exit and transition plan
Draft the exit plan with defined triggers for initiating exit, such as serious breach, evidenced weakness in the provider's ICT risk management, insolvency or a supervisory instruction. Assign roles, decision authority, communication paths, the sequence of data return and deletion, and the transition steps for each service. The plan should also state how the entity keeps the function running during transition. It is done when the management body or the delegated governance body has approved the plan and the trigger conditions are in the continuity and incident procedures.
Align the contracts with the plan
Check each contract against the plan, confirming that it has the termination rights, notice periods, data return and deletion terms, transition support and exit assistance the plan depends on. Where a contract is silent or weaker than the plan, record the gap and the negotiation or renewal action needed. Legal and procurement should confirm the terms, while the entity decides whether the residual gap is acceptable. It is done when each gap has an owner, a decision and a dated action in the contract register.
Test the plan through a desk exercise or partial live exit
Run the plan as a scenario exercise, such as provider insolvency or a suspension order, to see whether the people, data and steps described actually work. Where feasible, add a live partial exit, for example moving a non-production dataset or exporting and restoring data, to prove the data return path. Include the provider failure scenarios that the continuity testing rules require, such as insolvency, failure or political risk in the provider's jurisdiction. It is done when a test report records what was tested, who took part, and which steps succeeded or failed.
Record findings and update the plan
Log every finding from the test with an owner, a severity and a remediation action, then update the exit plan, dependency map, substitutability assessment and contracts where the test showed a gap. Feed the results into the entity's continuity testing and the ICT risk management review so the findings reach the management body. The step closes when the updated plan has been re-approved under governance and the findings are tracked to closure. The independent assessor only checks this record, it does not write the plan.

How exit changes in a planned exit, a provider failure or a supervisory order

A planned exit is the case the entity controls. It decides to move a service, typically to another provider or to an in-house platform, and runs the migration on its own timetable. The contract does most of the work here: the transition period and the data return terms set how long the provider must keep the service running and how the entity gets its data back in a usable form. DORA expects the exit strategy to be documented and tested before anyone needs it, so a planned exit should be a rehearsal of a plan that already exists.

Transition period: The contract must carry an adequate transition period for services supporting critical or important functions, as Article 30(3) requires. Confirm its length against the migration plan, not against the minimum the vendor offers.
Data return: Article 30(2) requires data return on termination. Specify the format, the completeness checks and the deletion certificate that follows.
Migration runbook: Keep a step-by-step plan with named owners, rollback points and the dependencies on other ICT services.
Test record: Show that the exit was tested, with dated results and the gaps closed afterwards.
Register update: Record the change in the register of information and in the arrangement's status.

Before relying on a planned exit, check that the contract's termination rights and notice periods match the timetable the migration needs.

When a supervisor can order a critical provider suspended

Article 42(6) gives competent authorities a last-resort power over critical ICT third-party service providers. Once a provider has been designated as critical and is overseen under the Lead Overseer framework, the authority can require financial entities to suspend, in part or in full, their use of that provider's service until the identified risks are addressed. The authority can also require the relevant contracts to be terminated. The power is meant for situations where other supervisory steps have not resolved the problem, so it is not a routine tool. For your exit planning, the practical point is that the order can arrive with little time to adjust, and it may cover only some of the services you buy from the provider.

Article 42(8) lists the factors the authority must weigh before using the power: the gravity and duration of the infringement, the serious weaknesses it reveals, any links to financial crime, whether it was intentional, and the risk to continuity of services. The same article requires the authority to give your entity enough time to adjust contracts and to deploy exit strategies and transition plans. That time allowance is not guaranteed to be long, and the entity cannot plan around an order alone. Keep exit plans current for every service that supports a critical or important function, and test whether each plan works if a suspension arrives at short notice. Ask your provider how it would respond to a suspension directive affecting only one service or one region.

The Article 58(1) review, due by 17 January 2028, covers among other things the criteria for designating critical ICT third-party providers. A change to those criteria could alter which providers fall under the Lead Overseer framework and therefore which providers are exposed to this power. Until the review concludes, do not assume your current provider list is final. Confirm with your competent authority how it expects designation changes to be communicated and whether it will require you to update your register of information or exit plans when a provider's status changes.

Who owns the exit plan, who prepares it and who tests it independently

The financial entity carries the obligation. Under DORA, the entity must maintain documented and tested exit strategies and transition plans for ICT services that support critical or important functions, and the management body must approve the policy that sets them. The entity decides whether to terminate a provider, chooses the replacement, and accepts the residual risk of any transition. Business and continuity testing stays with the entity, because only it can judge whether a failed provider would disrupt its own services.

Ownership: The management body approves the exit strategy and accountable owners are named for each critical service.
Termination decisions: The entity decides when to use contractual termination rights and how to manage the transition period.
Business testing: Scenarios such as provider insolvency or failure are run against the entity's own business impact analysis.
Records: Test results, lessons learned and updates to the register of information are kept by the entity.
Staffing: Internal staff must understand the plan well enough to execute it without the provider.

Check that your internal owners can name the person who would sign a termination notice and the person who runs the transition, and that both appear in the policy.

Why exit plans fail a supervisory review and how to avoid it

Supervisors rarely reject an exit plan for missing a section. They reject plans that look complete on paper but cannot be executed, tested or traced back to the services they protect. The cards below cover the gaps that most often surface in reviews, with the fix and the evidence that closes each one.

Plans written but never tested

An exit plan that has never been exercised is a document, not a capability. Article 28(8) expects exit strategies and transition plans for services supporting critical or important functions to be tested, and Article 25 of Delegated Regulation (EU) 2024/1774 expects continuity testing to reflect the provider failing. Schedule a tabletop exercise for each critical provider, then a partial technical exit such as restoring a data extract into a second environment. Evidence: dated test scripts, participants, results, and a remediation log with owners and closure dates.

No usable transition or data return terms

Article 30(3) requires exit strategies with a mandatory adequate transition period for services supporting critical or important functions, and Article 30(2) requires data return on insolvency or termination. Many contracts state a termination right but leave the transition period undefined, or return data only in a proprietary format that cannot be loaded elsewhere. Check the formats, the timing of return, the cost of extraction, and whether the provider must keep services running during the transition. Evidence: contract clause references mapped to the exit plan, and a sample export that a second team has loaded successfully.

Dependencies missing from the map

Exit plans often map the primary provider but not what sits beneath it. Sub-processors, data storage locations, third-party libraries, licence terms and hosting regions can each block a migration. Article 30(2) requires permitted subcontracting and data locations to be stated in the contract, so the plan should trace the chain at least one level down. Ask the provider for its current subcontractor list and check licence conditions that restrict transfer or continued use after termination. Evidence: a dependency diagram tied to the register of information entries and signed provider confirmations.

Substitute availability assumed, not checked

A plan that names a replacement provider but never confirms that the replacement can accept the workload, meet the same resilience standard, and start within the transition window is incomplete. Supervisors ask whether the alternative is genuinely available, with capacity, contract terms and onboarding feasibility. Document the candidate providers, the due diligence already done on them, the lead time to contract, and any capacity commitments. If no substitute exists, say so and describe the in-house or reduced-service fallback and its limits. Evidence: pre-qualification records, draft or signed agreements, and a documented decision where substitutability is limited.

Plans disconnected from continuity and the register

An exit plan that sits outside the business continuity programme and the register of information will contradict other records. Article 26(4) of Delegated Regulation (EU) 2024/1774 requires continuity measures that mitigate provider failure for critical or important functions, and the register must show the contractual arrangements and their dependencies. Link each exit plan to the relevant continuity scenarios, recovery objectives and register entries, and update all of them when a provider or subcontractor changes. Evidence: a cross-reference table between the exit plan, continuity test reports and register records, with matching version dates.

Questions buyers ask about DORA exit plans before hiring help

Does every ICT provider need a DORA exit plan?

No. The exit plan requirement follows the classification of the function the provider supports. Article 28(8) requires documented, tested exit strategies and transition plans for ICT services supporting critical or important functions, so a provider that supports only non-critical activities does not carry that specific duty. The classification still needs to be recorded and justified in your policy and register. Before you scope any work, confirm with your compliance lead which functions are critical or important and which providers support them, because that list drives how many exit plans you need and how deep each one goes.

Can our own team write the exit plan, or must a partner do it?

Your organization writes and owns the exit plan. DORA places the duty on the financial entity, and a partner cannot take that responsibility. An implementation partner can help prepare the technical material the plan depends on, such as data export procedures, inventories of the systems and data involved, migration runbooks and test records. Many teams draft the plan internally and bring in outside help only for the technical evidence or for testing the transition. Whichever route you choose, the management body must approve the policy that covers it.

What do the business and IT teams have to provide?

Business teams must identify which processes depend on each critical provider, how long those processes can tolerate disruption, and which alternatives are acceptable. IT and platform teams must document the systems, interfaces, data stores and configurations that would move, and they must confirm that data can be exported in usable formats. Legal and procurement need to align contract terms, including termination rights, notice periods and data return, with what the plan assumes. Expect the work to involve several rounds of review, because each assumption in the plan must match what the contract and the technical setup actually allow.

How long does an exit plan take to produce and test?

No fixed duration applies, because the timeline depends on the number of critical services, how much data and integration each service holds, how many business units rely on it, and whether the contracts already contain adequate exit terms. Renegotiating contracts often takes the longest, since it depends on the provider's willingness and your negotiating position. Testing adds time because it should follow the business impact analysis and use severe but plausible scenarios, including provider failure. Ask any partner for a written timeline tied to a fixed scope, and ask which dependencies could move the schedule.

Does a supervisor have to approve our exit plan?

DORA does not create a separate supervisory approval step for each exit plan in the provisions covered here. Your plan is part of your ICT third-party risk documentation, which competent authorities can review when they supervise compliance under their powers in Article 50. Supervisors also have a last-resort power under Article 42(6) to require a financial entity to temporarily suspend use of a critical provider's service or terminate contracts. Under Article 42(8), authorities must allow enough time for entities to adjust contracts and deploy exit strategies. Confirm with your national competent authority how it expects the plan to be presented and evidenced.

What can an implementation partner not do for our exit plan?

A partner cannot issue audit reports, attestations or certificates, and it cannot guarantee how a supervisor will judge your plan or what action a supervisor might take. Only independent auditors, assessors or the competent authorities perform those functions. A partner also cannot sign the plan on your behalf or accept the risk of a provider failure, which stays with your management body. What a partner can do is prepare systems, documentation and test evidence so that your own team and any independent reviewer can check the exit plan against the requirements.

How DeployOpen prepares exit plans, runbooks and evidence

DeployOpen works on the technical side of DORA exit strategies: the self-hosted platforms, data paths, runbooks and test records that an exit plan depends on. The organization owns its exit strategy, its contracts and its decision to terminate, and an independent auditor or supervisor assesses the result.

How we scope

Written scope names the critical or important services, providers and systems covered by the exit plan before work starts.
Scope lists data sets, interfaces, backups and dependencies that must move or be recovered during a transition.
Engagements are fixed-scope, with deliverables and timelines agreed in writing before any work begins.

How we build

We document a step-by-step exit runbook for each in-scope service, including roles, decision points and rollback steps.
We prepare data export and return procedures that test whether data can be extracted in a usable format.
We build a replacement or fallback path on self-hosted open-source platforms in the client's own infrastructure.

How we hand over

We deliver exit plan documents, runbooks, test reports and evidence files mapped to the organization's own DORA policy.
We walk the client's operations, risk and continuity teams through the runbooks and record their sign-off.
The organization decides what to adopt, and it keeps ownership of the plan, the contract clauses and any supervisory submission.

How we support

Ongoing support, upgrades and periodic exit testing are available as a retainer after handover.
We can rerun exit tests when a provider changes its service, terms or subcontracting arrangements.
Confirm with DeployOpen during scoping which updates, test frequencies and response commitments the retainer includes.

DORA exit strategies and exit plans for ICT providers