Exit strategies and substitutability in the register.

Why these two sit together

Substitutability asks whether you could replace a provider. Exit asks what you would actually do. They are recorded together because either alone is misleading: a provider that is theoretically substitutable but has no exit path is a concentration risk, and an exit plan that assumes a replacement nobody has identified is a document rather than a control.

Both attach to arrangements supporting critical or important functions, which is why the criticality determination has to be settled before either can be attempted.

Assessing substitutability

The assessment is about the difficulty of replacement, not about whether alternatives exist in the abstract. Four dimensions carry it:

• Market. Are there providers capable of delivering this service at your scale and in your jurisdictions? “There are many cloud providers” is not an answer if only one meets your data residency and certification requirements.
• Technical. How much of the implementation is provider-specific? Proprietary interfaces, embedded data formats and bespoke integrations all reduce substitutability regardless of market depth.
• Data. Can you get your data out in a usable form, in reasonable time, at known cost? This is the dimension most often assumed rather than verified.
• Operational. What would migration require in people, elapsed time and parallel running, and what is the tolerance of the function for disruption during it?

What an exit strategy has to contain

1. Triggers. What would cause exit — provider failure, service degradation, a change of control, a regulatory event, or a commercial decision. Each has a different timeline.
2. Destination. Reintegration in-house, migration to an alternative provider, or an orderly wind-down of the service. The register distinguishes these, and they are not equally credible for every arrangement.
3. Sequence and duration. The steps, in order, with the time each takes and the dependencies between them.
4. Data extraction. Format, volume, verification, and what happens to residual copies at the provider.
5. Continuity during transition. How the function keeps operating while the move happens.
6. Cost. Both the migration cost and the cost of running in parallel.
7. Ownership. Who executes it, and who decides to start.

What the register records

The templates in Implementing Regulation (EU) 2024/2956 record the assessments against the arrangements supporting critical or important functions — whether an exit plan exists, the nature of the reintegration or migration route, and the substitutability position, alongside the identification of possible alternative providers where applicable. The register carries the conclusion; your own documentation has to carry the reasoning behind it.

The contractual dependencies

An exit strategy depends on rights the contract either grants or does not. Termination rights on the triggers you identified. Assistance obligations during transition, with defined duration and cost. Data return in a specified format and timescale, with deletion afterwards. Access and audit rights sufficient to verify what you are getting back. Where the arrangement lacks these, the exit strategy is aspirational and the gap belongs in the contract remediation plan rather than hidden inside a register field.

Where the assessments fail

• Assessing the provider instead of the arrangement. The same provider can be readily substitutable for one service and not for another.
• Naming an alternative nobody has approached or qualified.
• Ignoring data extraction, which is usually the longest pole and the least tested.
• No trigger framework, so the plan has no starting condition and never starts.
• Never rehearsing. A plan that has not been walked through with the people who would run it has unknown duration, which is the one figure the assessment turns on.
• Copying a template across arrangements, producing identical assessments for services with nothing in common.

REGREP is an independent software provider. This record explains a reporting framework in plain language and is not legal, tax or regulatory advice. Confirm scope, thresholds and submission dates with your competent authority before you file.