Exit Strategy complete

Preparedness for migrating away from current providers, avoiding vendor lock-in

L0 Unaware

No exit plan exists; the organisation has not considered the possibility of migrating away from current providers

Criteria

EXIT-L0-C1 The organisation has no documented exit plan for any of its critical service providers

Evidence guidance

Ask for any document that describes how the organisation would migrate away from a named critical provider. There should be none, or only fragments inside unrelated procurement or business-continuity material. If a usable exit plan naming providers, data, and a target exists, the organisation is past this level and should be assessed against L1 or higher.
EXIT-L0-C2 No assessment has been performed to identify vendor lock-in risks or migration barriers

Evidence guidance

Request any lock-in or migration-barrier assessment: proprietary data formats, provider-specific APIs, integration depth, contractual breakage costs, or jurisdictional constraints on where data may be moved. The absence of any such record, or a register that lists providers without naming what makes leaving each one hard, places the organisation at this level.

Indicators

Asking about provider migration plans produces blank stares or dismissive responses
Contract renewal happens automatically without evaluating alternative providers
No one can name which providers the organisation could not leave inside a quarter, or why

Regulatory mappings

Regulation	Articles	Risk	Note
`DORA`	art-28	high	DORA Art 28(8) requires a documented, tested exit strategy for critical or important ICT third-party services. With no exit plan in any form, a financial entity has no basis for the mandated strategy and cannot demonstrate it could leave a provider without disrupting the supported function.
`NIS2`	art-21	high	Art 21(2)(d) treats supply-chain dependency as a risk that must be managed. An organisation with no exit planning has not assessed the continuity consequences of losing a critical supplier, leaving the dependency unmanaged.
`GDPR`	art-28	high	Art 28(3)(g) obliges the controller to be able to retrieve or have deleted its personal data when a processor relationship ends. With no exit plan, the controller has no assurance it could recover or extinguish that data at termination and cannot evidence the obligation.
`CLOUD-ACT`	18-usc-2703	high	Data held by a US-headquartered provider remains reachable under 18 USC 2703. An organisation that cannot move that data has no way to reduce its exposure if the provider is compelled or the legal basis for the arrangement falls away.

Upgrade path

Identify the three most critical provider dependencies and assess the migration barriers for each. Document what data formats, APIs, and integrations would need to change in a provider switch, and where the data is permitted to move given residency and jurisdiction constraints.

Risk if stagnant

Without any exit planning the organisation is captive to its providers. A price rise it cannot refuse, a service it cannot replace, a provider that exits the market or is placed under sanction, or a legal basis that collapses (for example a transfer mechanism struck down): any of these forces a crisis-mode migration with no preparation. The likely result is data loss, extended downtime, and a transition run under the worst possible conditions.

L1 Dependent

Basic data export capability exists but no structured exit plan; migration would require significant effort and extended downtime

Criteria

EXIT-L1-C1 The organisation can export its data from critical providers but only through manual processes or provider-specific tooling

Evidence guidance

Ask the team to demonstrate, or describe step by step, how data is exported from each critical provider. Confirm the route relies on console downloads, provider-specific CLIs, or support-ticket extracts rather than a documented repeatable procedure. Note whether the export covers all the data the organisation would need to operate elsewhere, or only the primary records while configuration, metadata, and history stay behind. A provider whose only export is a screen-scrape or a support request, with no record of what is and is not retrievable, sits at this level.
EXIT-L1-C2 No timeline, cost estimate, or resource plan exists for migrating away from any critical provider

Evidence guidance

Request any migration timeline, cost estimate, or resourcing plan for a named critical provider. The expected finding is that none exists, or that figures have been guessed in conversation but never written down or validated against actual data volumes and integration counts. A lock-in register that records the barriers but attaches no estimate of effort, duration, or cost to leaving still meets this criterion.

Indicators

Data export has been tested informally but never as part of a structured migration exercise
Exported data formats are proprietary or require significant transformation to be usable elsewhere
Whether a target provider is available, and where the data would be legally permitted to land, has not been established

Regulatory mappings

Regulation	Articles	Risk	Note
`DORA`	art-28	high	Ad-hoc export is not the documented, tested exit strategy DORA Art 28(8) requires. A financial entity that can pull data by hand but holds no plan cannot show it could transition a critical ICT service in an orderly way or within a tolerable timeframe.
`GDPR`	art-28	high	Manual export gives some practical ability to retrieve personal data at the end of a processor relationship under Art 28(3)(g), but with no tested procedure the controller cannot be confident the retrieval is complete or that residual copies are deleted on the provider side.
`NIS2`	art-21	high	Art 21(2)(d) supply-chain risk management expects the continuity consequences of losing a supplier to be understood. Awareness that export is possible, without a timeline or target, leaves the dependency only partly assessed and largely unmanaged.
`CLOUD-ACT`	18-usc-2703	high	The data still sits with the provider and remains reachable under 18 USC 2703. A manual export capability does not reduce exposure unless the organisation can actually move the data to a provider outside that reach, which at this level it has not planned to do.

Upgrade path

Negotiate contractual portability clauses with critical providers, including data export in open, documented formats, API access for migration tooling, and a transition-assistance period. Begin estimating migration timelines and costs for the top three dependencies, and confirm for each a credible target provider and a jurisdiction where the data is permitted to land.

Risk if stagnant

Knowing the data can be pulled out by hand creates a false sense of security. The export may be incomplete, the format may be unusable elsewhere, and no one has confirmed a target provider exists or that the data may legally move there. If a provider must be left at short notice, the organisation discovers the true cost and duration of the migration only while attempting it, which is the most expensive moment to find out.

L2 Contractual

Contracts include portability clauses, data export in open formats, and defined transition assistance from providers

Criteria

EXIT-L2-C1 Contracts with critical providers include portability clauses requiring data export in open, documented formats within defined timeframes

Evidence guidance

Request the executed contract or its exit/portability schedule for each critical provider. Confirm it names the export formats (and that they are open and documented rather than proprietary), the scope of what is exported (primary data, configuration, metadata, logs), and a maximum time within which the provider must deliver the export on termination. A clause promising export 'on reasonable request' with no format, no scope, and no deadline does not satisfy this criterion. Check the clause survives termination for cause, not only an amicable wind-down.
EXIT-L2-C2 Transition assistance periods are contractually guaranteed, providing support during migration to an alternative provider

Evidence guidance

Request the transition-assistance clause. Confirm it specifies a defined assistance period that runs past the contract end date, the level of support the provider must give during migration (engineering hours, data handover, parallel running), and that the obligation persists even where the contract is terminated for cause or non-payment is disputed. A goodwill statement that the provider will 'cooperate' with no committed duration or scope does not meet this criterion.
EXIT-L2-C3 AI Portability of AI-feature artefacts (fine-tuned models, embeddings, vector indices, retrieval-augmented generation document stores) is documented per tool, and the cost of re-creating these artefacts on an alternative provider is estimated

Evidence guidance

Request the AI-artefact portability map. For each AI-enabled SaaS tool, the map should answer: which AI artefacts exist (fine-tunes, embeddings, vector indices, RAG document stores, prompt libraries), in what format (if any) the vendor will export each artefact, and in which formats it cannot be exported (e.g. proprietary embedding spaces tied to a specific model). Where artefacts cannot be exported, the re-creation cost should be estimated: re-embedding the document corpus on a new model, retraining a fine-tune on equivalent data, rebuilding vector indices. A portability map that lists primary tenant data without naming the AI artefact tier does not satisfy this criterion.
EXIT-L2-C4 A cost-of-exit and cost-of-staying analysis exists for each critical provider, covering migration effort, breakage fees, downtime risk, and non-monetary factors such as knowledge concentration, strategic inflexibility, and geopolitical exposure

Evidence guidance

Request the analysis for each critical provider and check both directions: what leaving would cost (migration effort, contractual breakage, downtime and re-validation risk) and what staying costs (deepening knowledge concentration at the provider, loss of negotiating position, exposure to the provider's jurisdiction and political environment). Confirm the analysis is refreshed on a defined trigger, at minimum at contract renewal or on a material service change. A one-off procurement estimate from contract signing, or an analysis that counts only direct fees and ignores the non-monetary side, does not satisfy this criterion.

Indicators

Provider contracts explicitly address data portability, export formats, and transition assistance
A cost-of-exit and cost-of-staying analysis exists per critical provider, including the non-monetary side, and is refreshed at contract renewal or on a material service change
An AI-artefact portability map exists per tool (fine-tunes, embeddings, vector indices, RAG document stores) with re-creation cost estimates for artefacts that cannot be exported

Regulatory mappings

Regulation	Articles	Risk	Note
`DORA`	art-28	medium	DORA Art 28(8) requires documented exit strategies for critical ICT third-party services. Contractual portability and transition-assistance clauses are the paper backbone of that strategy. Where AI features have been integrated into critical workflows, AI-artefact portability is part of the same exit strategy and not a separate concern. The clauses remain untested at this level, so the entity holds rights rather than proven readiness.
`GDPR`	art-28	medium	A portability clause requiring export in open formats, plus a transition-assistance period, gives the controller a contractual route to retrieve or have deleted its personal data when the processor relationship ends, as Art 28(3)(g) requires. The route is contractual: the controller has not yet proven the export is complete or that the provider deletes residual copies.
`NIS2`	art-21	medium	Negotiated exit and transition clauses are a recognised supply-chain risk-management measure under Art 21(2)(d). They reduce the continuity risk of losing a critical supplier on paper, but enforcement is contractual and the migration has not been exercised.
`CLOUD-ACT`	18-usc-2703	medium	A portability clause is a precondition for moving data off a US-headquartered provider exposed under 18 USC 2703, but it does not by itself reduce exposure. The data stays put until an actual migration runs, and the contract cannot override a compelled-disclosure order while the data remains with the provider.

Upgrade path

Develop detailed migration runbooks for each critical provider and execute at least one full migration drill, importing production-equivalent data into a real alternative environment to validate the timelines, data volumes, and integration dependencies the contract assumes. Alongside the technical work, document the cost of exit and the long-term cost of staying for each critical dependency, including the non-monetary factors: downtime risk, retraining, knowledge concentrated in proprietary tooling, and accumulating lock-in as integrations deepen.

Risk if stagnant

Contractual portability rights are only as good as the organisation's ability to execute on them. A clause that has never been exercised hides whether the export is complete, whether the alternative provider can actually ingest the data, and whether the transition fits the timeframe the contract promises. If a provider has to be left under pressure, for instance because a transfer mechanism is struck down or the provider is sanctioned, the organisation is testing its untested rights for the first time during the event itself. The contract is enforceable in court long after the operational window to migrate has closed.

L3 Controlled

Tested migration plans exist for all critical providers with validated runbooks, rehearsed procedures, and confirmed alternative environments

Criteria

EXIT-L3-C1 Detailed migration runbooks exist for all critical provider dependencies, and at least one full migration drill has been completed successfully

Evidence guidance

Request the runbooks and the report from the most recent migration drill. Confirm a runbook exists for each critical provider, names the target environment and the data and integrations to be moved, and that the drill actually executed the migration rather than walking through it on paper. Look for the drill's measured outcome: what moved, how long it took, what broke, and what was fixed in the runbook afterwards. A runbook with no completed drill, or a drill that was a discussion rather than an execution, does not satisfy this criterion.
EXIT-L3-C2 For each critical provider, a target environment under different control (an alternative provider, or organisation-run infrastructure) is pre-configured and has been validated by importing production-equivalent data, so an exit can begin without first having to procure and build the destination

Evidence guidance

Ask to see the target environment for each critical provider and the record of the validation import. Confirm the target is under genuinely different control from the provider being exited, not another region or account of the same vendor, since that does not survive a provider-level withdrawal, sanction, or compelled-disclosure event. Confirm production-equivalent data has actually been imported and the workload shown to run there, within the timeframe the exit plan assumes. A target that exists only as a design, or that is another tenancy of the same provider, does not satisfy this criterion.
EXIT-L3-C3 New managed services and integrations are reviewed against an exit-impact check before adoption, so portability is preserved continuously rather than recovered at each drill

Evidence guidance

Request the adoption or architecture review procedure and the records of recent reviews. Confirm exit impact is a named checkpoint covering export formats, proprietary coupling, and any artefacts that could not be migrated, and that the review can block or condition an adoption on those grounds. The records should show the check actually shaping decisions: conditions imposed, alternatives chosen, or exceptions consciously accepted and documented. A checklist that exists but has never recorded an outcome on any adoption does not satisfy this criterion.

Indicators

Migration drills are conducted at least annually, with results documented and runbooks updated based on findings
Data portability is verified by successfully importing production-equivalent datasets into a target under different control from the provider being exited
Adoption and architecture reviews record an exit-impact outcome for each new managed service, with conditions imposed or exceptions consciously documented

Regulatory mappings

Regulation	Articles	Risk	Note
`DORA`	art-28	low	A tested migration runbook per critical provider and a pre-validated target environment turn the DORA Art 28(8) exit strategy from a document into a demonstrated capability. The entity can show, from its own drill evidence, that it could transition the supported function in an orderly way and within a tolerable timeframe.
`NIS2`	art-21	low	Validated, rehearsed exit for each critical supplier is technical enforcement of the Art 21(2)(d) supply-chain continuity expectation. The continuity consequence of losing a supplier is no longer assessed only on paper; it has been exercised.
`GDPR`	art-28	low	A drill that imports production-equivalent data into an alternative environment evidences that the controller can in practice retrieve its personal data at the end of a processor relationship under Art 28(3)(g), rather than relying on an untested contractual promise.
`CLOUD-ACT`	18-usc-2703	low	A pre-validated target under different control means the organisation can move data off a provider exposed under 18 USC 2703 on a known timeline. The exposure is not removed while the data remains with the provider, but the organisation can now act on it deliberately rather than under crisis conditions.

Upgrade path

Architect all systems for provider-agnostic operation using open standards, portable formats, and abstraction layers, so switching providers becomes a routine operational procedure rather than a project. Add continuous portability validation that exercises deployment to more than one target on every change, so drift that reintroduces a provider-specific dependency is caught as it lands rather than at the next annual drill.

Risk if stagnant

Tested migration plans degrade as systems evolve. A new managed service, a provider-specific API adopted for speed, or an integration added without an exit in mind can quietly reintroduce lock-in between drills. Runbooks fall out of date, and the pre-built target may no longer match production. If the drill cadence lapses, the organisation believes it is exit-ready while its actual readiness has decayed, and discovers the gap only when an exit is forced rather than chosen.

L4 Autonomous

Fully portable infrastructure with provider-agnostic architecture; switching providers is a routine operational procedure with minimal disruption

Criteria

EXIT-L4-C1 All systems are architected for provider-agnostic operation using open standards, portable formats, and abstraction layers that eliminate provider-specific dependencies

Evidence guidance

Inspect the architecture and the dependency inventory. Confirm workloads run on portable substrates (containers and open orchestration, open data formats, abstracted storage and messaging) rather than provider-proprietary managed services, and that any remaining provider-specific dependency is recorded with a deliberate justification. Ask how a new managed service is prevented from entering production: look for an architectural review gate that rejects provider lock-in by default. A stack that depends on a vendor's proprietary database, identity, or function service on the critical path does not satisfy this criterion, however well-run that service is.
EXIT-L4-C2 Provider switching can be executed as a routine operational procedure with near-zero downtime and no data loss, without depending on the outgoing provider's cooperation or continued availability

Evidence guidance

Request the record of an actual live provider switch (or a production-grade drill that cut real traffic over) and the procedure used. Confirm the cutover completed with no data loss and minimal downtime, and that it did not rely on the outgoing provider's assistance, since a forced exit (sanction, suspension, compelled disclosure) removes exactly that cooperation. Confirm the procedure runs on the organisation's own tooling rather than a provider's migration service. A switch that only works with the outgoing provider's active help, or that has never moved production traffic, does not satisfy this criterion.

Indicators

Automated portability tests run in CI/CD pipelines, continuously validating that workloads can deploy to multiple target environments
The organisation has executed at least one live provider migration with minimal business impact and without the outgoing provider's assistance
New managed services are gated by an architectural review that rejects provider-specific lock-in on the critical path by default

Regulatory mappings

Regulation	Articles	Risk	Note
`DORA`	art-28	minimal	Provider-agnostic architecture and routine, cooperation-independent switching satisfy the DORA Art 28(8) exit-strategy requirement at its strongest reading: the entity can leave a critical ICT provider without disrupting the supported function and without the provider's assistance, removing the concentration risk the article is written to contain.
`NIS2`	art-21	minimal	When losing any single supplier is a routine operational event rather than a continuity crisis, the Art 21(2)(d) supply-chain dependency is structurally managed rather than mitigated. The dependency that the measure addresses has largely been removed by construction.
`GDPR`	art-28	minimal	The controller can move personal data off any processor on demand and into an environment it chooses, so the Art 28(3)(g) ability to retrieve or delete data at the end of a relationship is exercised at will rather than dependent on a processor's goodwill or timeline.
`CLOUD-ACT`	18-usc-2703	minimal	An organisation that can switch providers as a routine operation can move data out of the reach of 18 USC 2703 quickly and without the outgoing provider's help. The exposure becomes a decision the organisation can act on at any time rather than a structural condition it is locked into.

Risk if stagnant

Full portability is a property that has to be maintained, not a state that is reached and kept. Every new feature, integration, or managed service is an opportunity to reintroduce a provider-specific dependency, and without an architectural gate that rejects lock-in by default the stack drifts back toward captivity one convenient service at a time. Portability tests that are not kept current stop catching the drift, and the organisation believes it is autonomous while a forced exit would reveal otherwise.