Most institutions think exit is covered once the contract contains termination rights and a notice period. That view usually holds until someone measures it against a critical or important function. A service can be legally terminable and still be operationally stuck, which is exactly the tension running through DORA, Regulation (EU) 2022/2554.
Exit starts where contract comfort ends
Under DORA, Regulation (EU) 2022/2554, exit sits inside information and communication technology (ICT) third-party risk management for services supporting critical or important functions. The useful reading is a practical one: the institution has to be able to 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 cover termination, exit, and transition conditions. It does not hand firms a universal completion deadline for every exit.
The law is asking whether continuity survives the move. That is the point many programmes miss. Teams often feel comfortable early and get stuck later, because legal can finish its work while operations are still left with an impossible timetable.
The legal baseline is wider than a contract clause
What DORA expects beyond termination rights
The contractual layer matters, but it is only the start.
Article 30 of DORA sets the baseline for ICT services supporting critical or important functions, while Commission Delegated Regulation (EU) 2024/1773 requires a documented exit plan for each relevant contractual arrangement together with periodic review and testing.
The operational edge comes from Commission Delegated Regulation (EU) 2024/1774, which requires ICT business continuity arrangements and testing for ICT assets that support critical or important functions.
Weak programmes start to show at that point. “Exit plan exists” sounds tidy in a committee paper, but it says very little by itself.
The 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. In my view, that is the first serious filter between paper compliance and something a supervisor would regard as believable.
Copla Registry
Turn exit plans into operational evidence
Exit strategies often exist on paper but break down under scrutiny. Copla Registry structures dependencies, providers, and alternatives into a dataset that supports credible, testable exit planning.
- Map exit strategies to actual services, providers, and dependencies
- Link alternative providers and substitution options to live records
- Maintain evidence that supports supervisory review and challenge
Where the mismatch appears: notice period vs migration reality
A familiar mismatch sits right in the middle of this. Notice periods may look workable in the contract, while the actual migration, control revalidation, and reconciliation work takes far longer than the approval discussion ever suggested.
RoI exit plan fields: what the register can evidence (and what it can’t)
What the register can evidence
The register of information gives supervisors a structured view of the arrangement and of the institution’s own assessment of the service under Commission Implementing Regulation (EU) 2024/2956, the RoI ITS. That makes the RoI important evidence. It also gives it a very obvious limit once you read the templates closely.
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 the transition executable.
Contract, function, feasibility: separating RoI signals from execution proof
The cleanest way to see that boundary is to split the evidence into contract, function, and feasibility layers. The mapping below follows the contract templates together with template B_06.01 and template B_07.01 in the RoI ITS.
| Layer | What the layer is doing | What the RoI can evidence | What has to sit outside the RoI |
|---|---|---|---|
| Contract | It shows whether the arrangement gives the institution any legal and commercial room to move | Contract references, start and end dates, renewal and termination markers, notice-period information, and related contractual data | The contract text, transition-assistance wording, fallback positions, waiver mechanics, and the actual termination playbook |
| Function | It shows what the service supports and how much disruption the institution can tolerate | Function identification, criticality or importance, RTO, RPO, and discontinuity impact | Business impact analysis, dependency maps, service-owner decisions, continuity assumptions, and target-state operating choices |
| Feasibility | It shows whether leaving the provider looks plausible when the institution assesses the service | Exit-plan existence, substitutability, reintegration difficulty, alternative-provider identification, and impact of discontinuing the ICT service | Migration steps, tooling, ownership, security redesign, onboarding readiness, data-portability work, parallel-run design, and test results |
Where to find field-level exit evidence in the RoI templates
For a more granular view of which RoI fields actually evidence exit readiness, the field-level breakdown is more useful than any broad label. The wider supervisory logic behind the templates sits in the DORA register of information.
How to set exit timing under DORA (there is no single deadline)
The three inputs
Teams often hunt for a date in the regulation when the harder question is how the date has to be derived. Exit timing has to be worked out from three inputs taken together.
- Contract mechanics: notice period, renewal windows, end dates, termination triggers, and any transition support or extension provisions.
- Function tolerance: the supported function’s criticality, acceptable outage window, recovery point, and the business effect of degraded service.
- Migration feasibility: data portability, workload-transfer effort, control redesign, security re-approval, onboarding lead times, and any need for dual running.
The second input is where optimistic assumptions usually break. In template B_06.01 of the RoI ITS, recovery time objective (RTO) and recovery point objective (RPO) belong to the function, not to the provider contract. That is also why exit assumptions fail when function mapping is weak.
Illustrative scenario
180-day notice period against nine-to-twelve-month migration path
The pressure point looks like this: a firm has a 180-day notice period for a service that supports a critical function with a four-hour RTO, while the actual migration path needs nine to twelve months because security controls have to be rebuilt, records have to be reconciled, and dual running cannot be avoided.
That mismatch is not exotic. It is the ordinary shape of a bad exit assumption once someone forces the contract, the function, and the engineering work into the same conversation.
Disaster recovery (DR) testing and exit testing answer different questions
Why the tests diverge under the delegated acts
A lot of otherwise competent teams fool themselves here.
Commission Delegated Regulation (EU) 2024/1773 expects periodic review and testing of the documented exit plan, while Commission Delegated Regulation (EU) 2024/1774 expects business continuity arrangements and testing around critical or important functions. Those obligations sit close together, but they are not asking the same question.
A disaster recovery test inside the same provider estate can show that workloads can be restored after an incident. It says much less about provider failure or forced transition, where contractual access may narrow, the control environment may have to be rebuilt elsewhere, and the target environment may not even exist yet.
What “tested exit” evidence looks like outside the RoI
Good evidence outside the RoI usually contains the pieces that govern execution: 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.
Those expectations are implicit in the review and testing logic of Delegated Regulation (EU) 2024/1773 and the continuity-testing logic of Delegated Regulation (EU) 2024/1774.
Exit plan red flags that show up under challenge
The weak patterns are usually easy to spot once the operational questions begin.
A plan says reintegration is possible, yet 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 has been identified, yet no contract is near signature and the onboarding timeline is longer than the notice period.
A function carries aggressive RTO and RPO values, yet the migration path depends on extended dual running and lengthy reconciliation. None of that looks strange in isolation. Read together, it gives the game away.
Supervisors will read weak exit fields as a resilience story
The pattern supervisors will read first
The exit-related fields in the RoI do not sit there as harmless descriptors. Under Commission Implementing Regulation (EU) 2024/2956, the RoI ITS, low substitutability, no serious alternative, high reintegration difficulty, and severe discontinuity impact create a very clear picture of dependency.
Add a critical or important function and the supervisory reading becomes sharper.
One pattern is especially revealing. If B_07.01 in the RoI ITS shows low substitutability, difficult reintegration, and no credible alternative provider, while B_06.01 ties the service to a critical function with tight RTO and RPO values, the exit-plan flag does not do much to calm the picture. I would expect that combination to be read as a concentration and resilience problem first, and a documentation question second.
Why supply-chain visibility changes the reading
The same logic carries into the supply chain.
A substitute-provider story is much less persuasive when the institution cannot see clearly through the subcontracting chain, which is also why substitute-provider planning breaks when the supply chain is opaque.
Supervisors tend to notice weakness in the joins between fields rather than in one dramatic omission. That is where what supervisors are really checking when exit fields look weak becomes easier to read.
Exit evidence still breaks when the RoI relationships break
Why the data relationships matter
The reporting point that matters here is narrower than many teams expect.
The RoI was designed in Commission Implementing Regulation (EU) 2024/2956 as a linked structure across contracts, providers, services, supply-chain relationships, functions, and assessments. If those identifiers and links stop holding together, the institution can have a sensible exit position and still fail to evidence it coherently in the register. That linked logic is easier to see in the data model explained in plain English.
Keep the RoI intact as a connected dataset
RoI integrity depends on stable identifiers and correctly maintained relationships across contracts, services, providers, and functions. Copla Registry enforces structure at source to keep every link consistent as the dataset evolves.
Why spreadsheet-led builds fray
Spreadsheet-led builds start to fray once the data has to stay consistent across multiple templates and updates. Why Excel-based DORA RoI projects fail covers that pattern directly.
Some teams deal with it by building a repeatable export workflow around the register, whether internally or through a dedicated DORA RoI export workflow.
Exit under DORA becomes credible when those layers stay aligned. The contract has to allow movement. The function has to survive it. The institution has to show, with enough specificity to survive challenge, that the transition is feasible in practice. The register can capture the signals. The harder work sits in making sure they are true.
