Exit Strategies for ICT Providers

An exit strategy for an ICT provider is a plan for moving a service away from that provider without interrupting the service or losing the data and knowledge it needs. Under DORA, exit planning is part of third-party risk management, not an afterthought for the end of a contract. A workable plan covers what data will be returned and in what form, what assistance the provider will give during transition, how knowledge will transfer, and how the service will keep running while the move takes place. Planning those points in advance matters because exit is hardest precisely when it is most urgent, such as after a failure or a breakdown in the relationship.

A planned exit follows a commercial decision, such as a change of strategy or the end of a contract term, and can be sequenced at a pace the entity chooses. A forced exit follows a failure, a serious breach, or a provider ceasing to operate, and must proceed under pressure. The same plan serves both cases, but the forced case exposes every gap in it: data that cannot be exported, knowledge held only by provider staff, or transition assistance that depends on goodwill. Testing the plan against the forced case, even in discussion, is therefore more valuable than assuming exit will always be orderly.

A core banking illustration clarifies what exit must preserve. The service needs its customer and transaction data in a usable form, the configuration and rules that make the system behave as customers expect, and the operational knowledge that explains exceptions and workarounds. Data in a proprietary format that only the outgoing provider can read is not a genuine return. Knowledge that lives only in the heads of provider staff is not a genuine handover. Exit planning should therefore specify formats, completeness checks, and knowledge transfer activities, and should treat each of those as a deliverable to be verified rather than a promise to be trusted.

Continuity during transition often depends on running old and new arrangements in parallel for a period, so that problems can be found before the old service is switched off. Parallel running needs data synchronisation, clear cutover criteria, and a route back if the new arrangement fails early. It also needs people: staff on both sides who understand the service and can resolve issues quickly. A transition plan that jumps directly from one provider to another, without a parallel phase or a fallback, concentrates risk into a single moment. The exit guide and the oversight guide both point to the same lesson, which is that continuity is designed, not hoped for.

An exit plan can be tested in part without leaving the provider. The entity can verify that data exports work and are complete, that documentation is current, that staff understand their roles, and that a replacement could be procured within a realistic timeframe. A tabletop discussion that walks through a forced exit scenario can reveal missing steps without disrupting the live service. Those tests do not prove that a real exit would succeed, but they are far more informative than an untested plan sitting in a contract annex. Findings from testing should feed back into the plan, the contract, and the register.

Exit planning should also consider timing and cost in broad terms, without pretending that either can be forecast precisely. A move that coincides with a peak period for the service, a regulatory change, or a major internal programme carries more risk than the same move at a quieter time. Costs may include parallel running, data migration, retraining and dual licensing, and those costs affect whether exit is a realistic option or only a theoretical one. An exit strategy that ignores timing and cost may look sound on paper while being unusable in practice, which is why the strategy should be reviewed when the service, the provider, or the business around them changes.