Most financial institutions believe their exit obligations under DORA are satisfied the moment a contract contains termination rights and a notice period.
According to Copla, that assumption tends to hold until someone stress-tests it against a critical or important function — and at that point, the gap between legal comfort and operational reality becomes very hard to ignore.
Copla recently discussed DORA exit strategy requirements, and why “we can terminate” isn’t an exit.
A service can be perfectly terminable on paper and still leave an institution stuck in practice. That tension sits at the heart of how Regulation (EU) 2022/2554 approaches exit.
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. The practical test is whether an institution can 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 hand firms a single universal completion deadline. The question regulators are really asking is whether continuity survives the move — and that is precisely what many programmes fail to demonstrate. Legal teams often close their work early while operations are left with an unworkable timetable.
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, together with periodic review and testing. Commission Delegated Regulation (EU) 2024/1774 adds requirements for ICT business continuity arrangements and testing for assets that support critical or important functions.
Stating that an exit plan exists sounds reassuring in a committee paper, but it says very little in isolation. A credible plan has to fit the contract, the supported function, the target environment, the controls that need to be rebuilt, and the time available to do the work. That is where the first meaningful divide between paper compliance and something a supervisor would regard as believable begins to emerge.
A familiar and persistent mismatch sits at the centre of this. Notice periods can look entirely workable when reviewed in the contract, whilst the actual migration, control revalidation, and reconciliation work takes considerably longer than the approval discussion ever acknowledged. This is not an unusual scenario — it is one of the most common failure points in exit planning under DORA.
The register of information (RoI), governed by Commission Implementing Regulation (EU) 2024/2956, gives supervisors a structured view of each arrangement and the institution’s own assessment of the service. That makes it important evidence — but it also has a very clear limit. The register can show that exit has been assessed. It cannot hold the operational sequence, named resource commitments, cutover logic, or test evidence that would make a transition executable.
Splitting the evidence into contract, function, and feasibility layers makes this boundary easier to see. The contract layer shows whether the arrangement gives the institution legal and commercial room to move; the function layer shows what the service supports and how much disruption can be tolerated; the feasibility layer shows whether leaving the provider actually looks plausible when the institution assesses the service. RoI templates can evidence fields within each of those layers, but the operational detail — migration steps, tooling, security redesign, data-portability work, and test results — has to sit outside the register.
Exit timing is another area where teams often look for a date in the regulation when the harder question is how that date has to be derived. Three inputs determine it: contract mechanics, including notice period, renewal windows, and transition support provisions; function tolerance, meaning the critical function’s acceptable outage window, recovery point objective (RPO), and recovery time objective (RTO); and migration feasibility, covering data portability, control redesign, security re-approval, and onboarding lead times.
The second input is where optimistic assumptions most often break down. Under template B_06.01 of the RoI implementing technical standards, RTO and RPO belong to the function, not to the provider contract — and that distinction matters enormously when function mapping is weak.
Disaster recovery (DR) testing and exit testing answer different questions, and conflating them is a common error even among otherwise competent teams. Commission Delegated Regulation (EU) 2024/1773 expects periodic review and testing of the documented exit plan, whilst Commission Delegated Regulation (EU) 2024/1774 expects business continuity arrangements and testing around critical or important functions.
A DR test inside the same provider estate can show that workloads can be restored after an incident. It says very little about a forced transition, where contractual access may narrow, the control environment may need to be rebuilt elsewhere, and the target environment may not yet exist. Good exit evidence outside the RoI typically contains 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.
Certain patterns in exit plans tend to reveal themselves quickly under challenge. A plan asserting that reintegration is possible, whilst template B_07.01 in the RoI rates reintegration as highly complex and no internal platform exists to receive the service, is a significant red flag. An alternative provider identified on paper with no contract near signature and an onboarding timeline longer than the notice period is another.
A function carrying aggressive RTO and RPO values whose migration path depends on extended dual running and lengthy reconciliation completes the picture. None of those weaknesses looks alarming in isolation; read together, they tell a clear story about the credibility of the exit position.
Supervisors will read weak exit fields as a resilience story, not simply a documentation gap. Low substitutability, no credible alternative, high reintegration difficulty, and severe discontinuity impact — when combined with a critical or important function tied to tight recovery objectives — create a picture of concentration risk. That combination is likely to be read as a resilience and concentration problem first, and a documentation question second. The same logic extends into the supply chain: a substitute-provider narrative loses persuasiveness when an institution cannot see clearly through the subcontracting structure.
Exit evidence can also break down when the RoI’s internal data relationships break down. The register was designed as a linked structure across contracts, providers, services, supply-chain relationships, functions, and assessments. If those identifiers stop holding together, an institution can have a sound exit position and still fail to evidence it coherently. Spreadsheet-led builds are particularly prone to this, as consistency across multiple templates and updates becomes difficult to maintain at scale.
Credible exit under DORA requires all three layers to stay aligned: the contract has to allow movement, the function has to survive the transition, and the institution has to be able to demonstrate — with enough specificity to withstand challenge — that the transition is feasible in practice. The register can capture the signals. Making sure those signals are true is where the harder work lies.
Read the full Copla post here.
Copyright © 2026 RegTech Analyst
Copyright © 2018 RegTech Analyst
