Most financial institutions assume their exit obligations under the Digital Operational Resilience Act (DORA) are satisfied the moment a contract contains termination rights and a notice period.
According to Copla, That assumption tends to hold until someone actually measures it against a critical or important function — and it rarely survives that test. A service can be perfectly legal to terminate and still be operationally immovable, and that tension sits at the heart of Regulation (EU) 2022/2554.
Under DORA, exit planning falls within the broader framework of information and communication technology (ICT) third-party risk management, specifically for services that support critical or important functions.
Copla recently discussed DORA exit strategy requirements, and why “we can terminate” isn’t an exit.
The practical test is straightforward: can the institution terminate or transition an ICT service without breaching the recovery tolerance of the function that depends on it? DORA requires contracts for critical or important functions to address termination, exit, and transition conditions, but it does not prescribe a single universal deadline for completing every exit.
The real question the regulation is asking is whether continuity survives the move. This is where many programmes go wrong. Legal teams can complete their work well ahead of schedule, while operations teams are left facing a migration timetable that was never realistic in the first place.
What DORA actually requires beyond termination rights
The contractual layer is only the starting point. Article 30 of DORA establishes the baseline for ICT services supporting critical or important functions. Commission Delegated Regulation (EU) 2024/1773 goes further, requiring a documented exit plan for each relevant contractual arrangement, along with periodic review and testing. Commission Delegated Regulation (EU) 2024/1774 adds requirements for ICT business continuity arrangements and testing specifically for ICT assets underpinning critical or important functions.
Weak programmes tend to surface at precisely this point. “Exit plan exists” may look tidy in a committee paper, but it says very little on its own. A credible plan must account for the specific contract, the function it supports, the target environment, the controls that need rebuilding, and the time realistically available to do the work. That is the first serious dividing line between paper compliance and something a supervisor would find believable.
The mismatch between notice periods and migration reality
A familiar tension runs through most exit programmes. Notice periods may appear workable on paper whilst the actual migration work — including control revalidation and reconciliation — takes substantially longer than was ever acknowledged during the approval process. This mismatch between legal mechanics and operational reality is one of the most common failure points in DORA exit planning.
What the register of information can and cannot evidence
The register of information (RoI) gives supervisors a structured view of each arrangement and the institution’s own assessment of the service, as set out under Commission Implementing Regulation (EU) 2024/2956. That makes it important evidence, but reading the templates carefully reveals its limits.
The RoI can demonstrate that exit has been assessed. It cannot hold the operational sequencing, named resource commitments, cutover logic, or test evidence that would make a transition genuinely executable. The distinction becomes clear when exit evidence is separated into three layers: contract, function, and feasibility.
The contract layer shows whether the arrangement gives the institution legal and commercial room to move. The RoI can evidence contract references, start and end dates, renewal and termination markers, and notice-period information. What must sit outside the register includes the contract text itself, transition-assistance wording, fallback positions, and the actual termination playbook.
The function layer shows what the service supports and how much disruption the institution can tolerate. The RoI can capture function identification, criticality, recovery time objective (RTO), recovery point objective (RPO), and discontinuity impact. Business impact analysis, dependency maps, and continuity assumptions must sit elsewhere.
The feasibility layer shows whether leaving the provider is plausible given the institution’s own assessment. The RoI can evidence exit-plan existence, substitutability ratings, reintegration difficulty, alternative provider identification, and the impact of discontinuing the service. Migration steps, tooling, security redesign, data-portability work, and test results must all live outside the register.
How to set exit timing under DORA
Teams often search for a fixed deadline in the regulation when the harder question is how that deadline must be derived. Exit timing under DORA has to be worked out from three inputs simultaneously: contract mechanics, including notice periods, renewal windows, termination triggers, and transition support provisions; function tolerance, meaning the criticality of the supported function, acceptable outage windows, RPO, and the business effect of degraded service; and migration feasibility, covering data portability, control redesign, security re-approval, onboarding lead times, and any need for dual running.
The function tolerance input is where optimistic assumptions most commonly break down. In template B_06.01 of the RoI ITS, RTO and RPO belong to the function, not to the provider contract — a distinction that matters enormously when assumptions are stress-tested against reality.
Why disaster recovery testing and exit testing are not the same thing
Commission Delegated Regulation (EU) 2024/1773 expects periodic review and testing of the documented exit plan. Commission Delegated Regulation (EU) 2024/1774 expects business continuity arrangements and testing around critical or important functions. These obligations sit close together, but they are asking different questions.
A disaster recovery test conducted within the same provider environment can demonstrate that workloads can be restored after an incident. It says comparatively little about a provider failure or forced transition, where contractual access may narrow, the control environment may need to be rebuilt from scratch, and the target environment may not yet exist. Good exit evidence outside the RoI typically includes a target architecture, a data-portability approach, a control revalidation path, named ownership for the transition sequence, and a test cadence tied to the importance of the function.
Exit plan red flags that emerge under challenge
Weak exit plans tend to become obvious once operational questions begin. Common patterns include: an exit plan that claims reintegration is feasible whilst template B_07.01 in the RoI ITS rates reintegration as highly complex and no internal platform exists to receive the service; an alternative provider identified by name where no contract is near signature and the onboarding timeline exceeds the notice period; and a function carrying aggressive RTO and RPO values where the migration path depends on extended dual running and lengthy reconciliation. None of these signals looks alarming in isolation. Read together, they tell a consistent story.
How supervisors will read weak exit fields
Exit-related fields in the RoI are not passive descriptors. Under Commission Implementing Regulation (EU) 2024/2956, low substitutability, the absence of a credible alternative, high reintegration difficulty, and severe discontinuity impact combine to paint a clear picture of dependency. Add a critical or important function and the supervisory reading sharpens considerably. If B_07.01 shows low substitutability, difficult reintegration, and no credible alternative provider, whilst B_06.01 ties the service to a critical function with tight RTO and RPO values, the presence of an exit-plan flag does relatively little to improve the picture. That combination is likely to be read as a concentration and resilience problem first, and a documentation question second.
The same logic extends into the supply chain. A substitute-provider narrative is considerably less persuasive when the institution cannot see clearly through the subcontracting chain. Supervisors tend to notice weakness in the joins between fields rather than in a single dramatic omission.
Why data relationships in the RoI matter
The RoI was designed in Commission Implementing Regulation (EU) 2024/2956 as a linked structure spanning contracts, providers, services, supply-chain relationships, functions, and assessments. If those identifiers and links break down, an institution can hold a sensible exit position and still fail to evidence it coherently in the register. Spreadsheet-led builds tend to fray once data has to stay consistent across multiple templates and updates, which is a known failure mode in DORA RoI projects.
Exit under DORA becomes credible only when all three layers — contract, function, and feasibility — remain aligned. The contract must allow movement. The function must survive it. And the institution must be able to demonstrate, with enough specificity to withstand challenge, that the transition is actually feasible in practice. The register can capture the signals. Making sure those signals are true is the harder work.
Copyright © 2026 FinTech Global
