Write an exit runbook for a critical provider

Do not include credentials, personal data, internal addresses, undisclosed controls or confidential contract and architecture details. Redact them, or use an approved private or local assistant.

We depend on [provider] for [workload] and have no tested exit plan. Target [another provider or our own infrastructure]. Scope: service/release [version], deployment [profile], operating model [description], relevant agreements and governance [details], customer-control boundary [boundary], review date [date] and required exit window [window].

Act as an operations lead writing an exit runbook that a named team could execute under time pressure. Do not treat export capability as proof that the organisation is permitted, prepared or technically able to complete the exit.

Produce a sequenced plan that keeps the service within its agreed continuity limits. For every step, state:
- the affected part of the exit and the supplied evidence, assumptions and missing evidence;
- data to export, including history, metadata, relationships, audit evidence and keys, plus format and reconciliation method;
- software, interfaces, configuration and dependencies to reproduce or replace;
- target infrastructure, operators, network and security controls to establish;
- contractual rights, transition duties, approvals, supplier-access revocation and supplier-copy deletion required;
- applicable compliance constraints for qualified review and separate data-ethics concerns for customer governance;
- cutover, rollback, acceptance evidence, owner, skills, duration and dependency on earlier steps.

Mark every Data, Software, Hardware or Organisational blocker. Label estimates with assumptions and ranges. Identify what must be done now to keep exit feasible, such as regular restore and exit exercises, open interfaces, version-pinned continuity material and enforceable transition terms. Recommend escrow only where it addresses a stated supplier-failure gap.

A written runbook does not demonstrate that exit works. End with the smallest exercise that would test the critical path, the evidence it must produce and the residual risks it leaves. Do not produce an overall sovereignty score or certification.
---
Use the toolkit as a practical way to examine who can possess, use and dispose of data and the software, hardware and organisational arrangements around it. Keep weak points visible instead of hiding them in one overall judgement.
Examine the organisational side through two complementary perspectives. Data compliance covers applicable rules, contracts, policies, authority, duties and supplier commitments. Data ethics asks whether choices are proportionate, fair, transparent and explainable. Governance operates across both.
Keep compliance questions and data-ethics concerns separate. Leave applicability and legal interpretation to qualified counsel, and do not present ethical considerations as a certification or universal verdict.
Scope every conclusion to the described service, deployment, operating model, agreements, customer boundary and date. Separate supplied facts from assumptions and missing or conflicting evidence. Do not produce an overall score, legal or ethical verdict, or certification.
Data handling: do not include personal data, credentials, secrets or confidential contractual, security or architecture details. Redact them and use an approved private or local assistant when redaction is insufficient.
Background and definitions: https://hoist-it.nl/toolkit
Relevant concepts: https://hoist-it.nl/toolkit/exit-clause  https://hoist-it.nl/toolkit/data-portability  https://hoist-it.nl/toolkit/vendor-lock-in  https://hoist-it.nl/toolkit/data-compliance  https://hoist-it.nl/toolkit/data-ethics