For senior leaders the problem is not whether services run in the cloud but whether they can be reclaimed, migrated or safely decomissioned when suppliers change, contracts end or political pressure forces an exit. The political scrutiny of major deals in 2026 — most visibly the NHS and Met/Palantir rows — has focused attention on break clauses and evidence of value. Boards need a short, deliverable programme that turns contractual promises into proven reversibility. This briefing gives a 90‑day plan, the contractual language to insist on, and tests that prove a supplier can actually deliver data, logs and operational knowledge if asked to leave.
Why boards must treat cloud exit as a live risk now
In 2026 public debate and ministerial scrutiny have made one thing clear: vendor concentration and perceived vendor lock‑in are now boardroom issues. Parliamentary exchanges, media investigations and regulator interest have placed several large public contracts under active review and created market urgency for alternative arrangements. Senior leaders must stop treating exit as a legal appendix and start treating it as an operational capability that is actively tested and budgeted.
Supplier exit is a commercial and operational risk: loss of practical access to data and logs impedes business continuity, undermines contractual value and exposes organisations to reputational, regulatory and continuity harms. The NCSC’s supply‑chain guidance and supplier assurance questions make clear that suppliers must demonstrate how they will return data, preserve evidence and support forensics — not just hand over CSV files at termination. Public‑sector guidance and G‑Cloud service‑documents already expect exit planning to be part of service delivery documents.
Board evidence pack: what to demand now (the 90‑day pack)
Produce a one‑page executive summary for the board showing: (1) the top five cloud suppliers by criticality and a single‑sentence exit rating for each, (2) whether a tested data export exists in an accessible format, (3) the existence and proof of a source‑code escrow or equivalent, (4) the cost and time estimate to migrate each critical workload, and (5) recommended board actions (resource, procurement actions, or stress tests).
Collect and verify the underlying evidence for each supplier: a certified data export (sample dataset extracted and validated), encryption‑key ownership and KMS control clauses, runbooks for cutover and rollback, a copy of audit logs and the retention schedule, and the contractual triggers and notice periods for termination and for invoking exit assistance. If any of these items are absent, record a remediation plan with owners and dates.
Include a short legal annex with the supplier’s committed exit clauses (data extraction format and API contracts, escrow arrangements, runbook handover obligations, forensic access windows and retention of logs for regulatory and legal needs).
Contractual levers and minimal draft clauses (practical, not academic)
Require machine‑readable data exports and schema mapping: the contract must require the supplier to provide a complete, machine‑readable export (CSV/Parquet/JSON) of application data plus an export of metadata, indexes and relationship maps within a fixed (contractual) timescale — with acceptance testing by the buyer within a defined window.
Encryption key custody and bring‑your‑own‑key (BYOK): where possible keep control of production encryption keys or demand a documented key‑handover process. Contracts should require evidence that encryption keys can be revoked or transferred and that the buyer can recreate the cryptographic environment needed to decrypt backups.
Forensic and audit access: guarantee a post‑termination forensic access window and pre‑agreed evidence retrieval procedures (logs, audit trails, config snapshots). Specify maximum times to produce each artefact and contractual remedies for delay.
Runbook and IP escrow: insist on an operational runbook, architecture diagrams and a working copy of any bespoke code in escrow. The escrow arrangement should be testable on an annual basis and include the right to execute the code under a specified disaster or insolvency trigger.
Break triggers and pricing of exit assistance: define objective break triggers (persistent SLA failure, insolvency, regulatory instruction, material misrepresentation) and a capped, transparent exit assistance rate, with milestone payments tied to evidence delivery (data extract, validated restore, knowledge transfer).
Operational tests you must run (the vendor fire drill)
Vendor exit stress test: for each critical supplier run a tabletop and a small‑scale technical extraction. The supplier must produce a complete export for a defined workload and a documented, runnable migration sequence to a buyer‑owned sandbox within 60 days of test start. Record time, cost and blockers.
Parallel run and acceptance: conduct a parallel restore of the exported data into a buyer‑controlled environment to validate completeness and functional integrity. Acceptance criteria must be concrete (search results, record counts, integrity checks).
Annual or event‑driven replay: schedule regular replays after major upgrades or contract extensions, and require the supplier to notify and re‑test on any architecture change that affects exportability.
Third‑party verification: where technical complexity is high, require a neutral third party to run the export and restore and produce an assurance report suitable for internal audit and insurers.
Commercial and governance actions for the next 90 days
Day 0–30: compile the board evidence pack; identify top five critical cloud/supplier relationships; demand the supplier produce a ‘sample export’ within 14–30 days. Board issues an instruction to procurement and legal to prioritise 'reversibility' in all extensions.
Day 31–60: run vendor stress tests for at least the top two critical suppliers; legal finalises mandatory exit language for new procurements and extensions; finance models the TCO of a forced exit and captures contingencies.
Day 61–90: accept and record the results; revise supplier criticality; either approve remediation plans or instruct commercial actions (milestone payments withheld until exit proof delivered, short term dual‑vendor pilots, or invoke break clauses where available). Prepare a public summary for audit traceability where appropriate.
Board governance: ensure the board receives an explicit supplier‑resilience update in the next board cycle and require the SRO to own supplier reversibility as a standing item on the risk register with a quantified RAG status.
Commercial nuance: when exit is not feasible — practical mitigations
Some workloads are effectively non‑portable because of proprietary managed services or specialised cloud‑native components. Where exit will be costly or impractical, treat the supplier as a strategic partner by: (1) creating a parallel, progressively scaled alternative (a 'warm' fallback), (2) insisting on expanded audit and escrow evidence, and (3) negotiating shorter contract terms with options to switch to modular services.
Consider architectural mitigations early: reduce data gravity by separating core data stores from proprietary vendor services, standardise APIs, and retain minimal critical services in buyer‑controlled landing zones or on sovereign cloud partners where necessary.
Boards must stop treating exit as legal fine‑print and start treating it as an operational capability that is tested, paid for and owned — otherwise suppliers will retain the option to withhold the very evidence the buyer needs to retain control.
Antares recommended actions
These are Antares's recommended first actions for organisations turning the issues in this article into practical governance and delivery.
- Produce a 90‑day board evidence pack that lists critical suppliers, their exit status and a remediation plan (owner and deadline).
- Immediately require top two critical suppliers to deliver a validated, machine‑readable sample export and runbook within 30 days.
- Insert mandatory exit clauses into all extensions: machine‑readable export, encryption key transfer/BYOK, escrow of bespoke code, forensic access windows and capped exit assistance fees.
- Run a vendor exit fire drill (export → restore → acceptance) for the two highest‑risk suppliers within 60 days, with third‑party verification where necessary.
- If a workload is non‑portable, negotiate shorter terms, stronger audit rights and a funded, incremental parallel migration plan ('warm fallback').
