· Yair Knijn
The exit plan the contract required and nobody ever wrote
The head of procurement has the exit clause in every critical contract. Termination rights on material degradation, a transition period, a data-return obligation, drafted by counsel and signed. The assumption is that the clause is the control. It is not. It is the receipt for a control nobody built.
The gap shows up the day a critical provider raises its price beyond what you can absorb, gets acquired by a competitor, or lands on a regulator's concentration list. You reach for the exit and find no plan behind the paragraph. You bought the right to leave a building whose floor plan you never drew.
What DORA Article 28 expects from a critical-provider exit strategy
DORA Article 28 does not ask for an exit clause. It asks for an exit strategy, documented per ICT service that supports a critical or important function, and tested as a genuine operational process rather than filed. The strategy has to name the data-return format, a transition period long enough to move to an alternative or bring the service in-house, and the provider's cooperation obligations during handover.
For providers designated as critical third parties, the rule goes further: the first CTPP list landed in October 2025, and those exit plans have to be tested at least annually. Where a provider genuinely has no near-term substitute, you document the constraint and the controls you run while the dependency stands. Substitutability is what is being assessed, not the wording.
Clause versus plan: why the contract language is the easy half
Contract language is cheap because it is generic. The same exit paragraph fits a payments processor, a document store, and a fraud-scoring API, which is why it tells you nothing about whether you can leave any of them. A plan is specific or it is fiction. It names the egress endpoint, the field mappings that break on the way out, the integration with no equivalent at the next vendor, and who owns each step.
Counsel writes the clause in an afternoon. The plan is engineering and operations work, and nobody's standing job, so it does not get done. The control that satisfies the auditor and the one that saves you in a forced migration are different artifacts, and procurement owns the first.
Knowing your data, integrations, and dependencies well enough to migrate
Real substitutability comes from knowing three things cold, per provider, before you need them:
- Data: what records live there, in what format, and what breaks on reload elsewhere. A right to data return means nothing if the return is a
.csvdump with no schema and no relationships. - Integrations: every system that calls this provider or that it calls, and which couplings have no off-the-shelf equivalent elsewhere.
- Dependencies: the functions that stop the moment this provider goes dark, the subcontractors behind it, and the transition window each one needs.
You cannot assemble this the night before. Scattered across one register per product, the answer to whether you can leave a vendor without breaking a critical function is a guess, and you find out it was wrong mid-migration.
Keeping exit-readiness current as the estate evolves
An exit plan written once decays the moment someone adds an integration, the provider changes its export API, or a new subcontractor appears under the hood. The annual test exists because the estate moves and the plan does not.
The work that makes exit-readiness real is the same work that makes any cross-provider question answerable: one current, queryable record of what you depend on, who touches it, and what leaving would take. In Spot Suite, a Customer Environment carries that picture for its providers and integrations as one record rather than a drawer of static documents, so when a price hike or a designation forces the question, the exit plan is something you read off the system instead of inventing overnight. Proof you can leave starts with the inventory: products.