# Cloud Exit Plan: [Cloud service] for [Organization name]

> Documents how [Organization name] will leave a cloud service in an
> orderly way, planned or under stress: exit triggers, data and asset
> inventory, data portability and formats, timelines, alternative
> providers, contractual exit assistance, the exit runbook, deletion
> and the exit test. Supports ISO/IEC 27001:2022 + Amd 1:2024 Annex A
> control A.5.23 (security for cloud service use, new in 2022, which
> includes exit from cloud services), with A.5.20, A.5.22, A.5.30 and
> A.8.13, guided by ISO/IEC 27002:2022 and ISO/IEC 27036-4:2016 on the
> security of cloud services. Replace every `[bracketed]` value and
> every row marked *Example*. This is a documentation format, not legal
> advice.

<!--
Guidance: How to use this template
- Write one plan per critical cloud service (an IaaS or PaaS platform,
  a core SaaS such as the productivity suite, CRM or HR system). Less
  critical services can share one short plan with a row each.
- Fill first: section 2 (service profile and criticality), section 4
  (what data and assets must leave and in which format) and section 8
  (what the contract gives you). Without these the rest is guesswork.
- Main pitfall: a plan that has never been tested. Data that exports in
  theory may not import anywhere in practice. Section 11 asks for a
  tabletop at least yearly and a technical test by risk.
- Financial entities under DORA (Regulation (EU) 2022/2554) must have
  documented and tested exit strategies for ICT services that support
  critical or important functions; section 12 gives the mapping. The
  method is useful for any organisation.
- Related templates: `isms/cloud-services-security-policy` (DOC-ISMS-044),
  `isms/supplier-register` (DOC-ISMS-066),
  `compliance/supplier-security-assessment` (DOC-ISMS-067),
  `isms/supplier-security-agreement-27036` (DOC-ISMS-068),
  `isms/ict-readiness-business-continuity-plan` (DOC-ISMS-047),
  `compliance/business-impact-analysis`, `ops/disaster-recovery-plan`,
  `isms/backup-policy`, `data/data-retention-deletion-standard`,
  `isms/control-evidence-matrix`.
-->

## Document control

<!-- Guidance: The exit plan is a controlled document: re-approve it when the service, the contract or the alternative provider changes. Record the last exit test date in the header so a reviewer sees its age at a glance. -->

| Field | Value |
|---|---|
| Document ID | DOC-ISMS-076 |
| Version | [1.0] |
| Status | [Draft / In review / Approved / Superseded] |
| Owner | [@service-owner] |
| Approvers/reviewers | [@cto], [@isms-manager], [@procurement-lead], [@legal-counsel] |
| Last updated | YYYY-MM-DD |
| Classification | [Confidential] |
| Standard and edition | ISO/IEC 27001:2022 + Amd 1:2024 (A.5.23, A.5.20, A.5.22, A.5.30, A.8.13); ISO/IEC 27002:2022; ISO/IEC 27036-4:2016 |
| Next scheduled review | YYYY-MM-DD (12 months, or at a trigger in section 3.2) |
| Cloud service and provider | [Service name, provider, service model IaaS / PaaS / SaaS] |
| Contract reference | [Contract ID, renewal date, notice period] |
| Last exit test | YYYY-MM-DD, [tabletop / technical], result [pass / pass with actions / fail] |

### Approvals

| Role | Name | Decision | Date |
|---|---|---|---|
| Service owner | [@service-owner] | [Prepared] | YYYY-MM-DD |
| ISMS manager | [@isms-manager] | [Reviewed] | YYYY-MM-DD |
| Procurement and legal | [@procurement-lead], [@legal-counsel] | [Reviewed] | YYYY-MM-DD |
| Top management | [@cto] | [Approved] | YYYY-MM-DD |

### Revision history

| Version | Date | Author | Change |
|---|---|---|---|
| 0.1 | YYYY-MM-DD | [@author] | First draft |
| 1.0 | YYYY-MM-DD | [@author] | Approved for issue |
| [x.y] | YYYY-MM-DD | [@author] | [Change summary] |

## Contents

- [1. Purpose and scope](#1-purpose-and-scope)
- [2. Service profile and criticality](#2-service-profile-and-criticality)
- [3. Exit triggers and plan review triggers](#3-exit-triggers-and-plan-review-triggers)
- [4. Data and asset inventory](#4-data-and-asset-inventory)
- [5. Exit strategy options](#5-exit-strategy-options)
- [6. Alternative providers and in-house option](#6-alternative-providers-and-in-house-option)
- [7. Timeline](#7-timeline)
- [8. Contractual exit assistance](#8-contractual-exit-assistance)
- [9. Roles and governance during exit](#9-roles-and-governance-during-exit)
- [10. Exit runbook](#10-exit-runbook)
- [11. Testing the exit](#11-testing-the-exit)
- [12. Regulatory examples](#12-regulatory-examples)
- [13. Costs and resources](#13-costs-and-resources)
- [14. Size tiers](#14-size-tiers)
- [15. Records and evidence](#15-records-and-evidence)
- [16. References](#16-references)
- [Standard and licence note](#standard-and-licence-note)

## 1. Purpose and scope

<!-- Guidance: State which service this plan covers and the outcome of a successful exit: which business services continue, with what data, on what platform, within what time. Questions: is the plan for the whole service or one region or tenant? Does it cover reversal (bringing a workload back in-house)? -->

This plan makes sure that [Organization name] can stop using
[cloud service] without unacceptable disruption to business services,
loss of data or breach of legal and contractual obligations, whether the
exit is chosen (planned exit) or forced (stressed exit).

| Item | Value |
|---|---|
| Service covered | [Production platform on provider X: compute, managed databases, object storage, identity integration, monitoring] |
| Business services supported | [Customer-facing analytics platform, customer API, internal reporting] |
| Exit outcome | [All services running on the target platform, all data migrated and verified, provider copies deleted and confirmed] |
| Out of scope | [Services covered by their own exit plan: productivity suite, HR system] |
| Policy basis | Cloud services security policy DOC-ISMS-044, which requires an exit plan for every critical cloud service |

## 2. Service profile and criticality

<!-- Guidance: Take criticality from the business impact analysis (`compliance/business-impact-analysis`, DOC-ISMS-120). If the BIA sets a recovery time objective of 4 hours, a stressed exit must at least protect the data and allow recovery elsewhere; a full migration in 4 hours is rarely realistic, so say what happens instead. -->

| Attribute | Value |
|---|---|
| Service model | [IaaS / PaaS / SaaS] |
| Deployment and regions | [Primary region, DR region] |
| Criticality (BIA) | [Critical / High / Medium] |
| Recovery time objective, recovery point objective | [RTO], [RPO] (from DOC-ISMS-120) |
| Data classification | [Confidential, personal data as processor] |
| Users and tenants | [Number of internal users, customers, tenants] |
| Lock-in factors | [Proprietary managed services, provider-specific APIs, identity federation, data volume and egress, licence terms] |
| Concentration | [Other critical services on the same provider] |
| Contract term and notice | [Start, renewal date, notice period, termination rights] |

Lock-in assessment *(Example, Quillmere Analytics Ltd)*:

| Component | Portability | Reason |
|---|---|---|
| Containers on managed Kubernetes | High | Standard container images and manifests |
| Managed PostgreSQL | High | Standard dump and restore, logical replication |
| Object storage (1.8 TB) | Medium | Standard API, but egress time and cost |
| Provider serverless functions (14) | Low | Provider-specific triggers and runtime |
| Provider key management | Low | Keys not exportable; data must be re-encrypted on the target |
| Provider identity and access policies | Low | Rebuilt on the target from infrastructure as code |

## 3. Exit triggers and plan review triggers

<!-- Guidance: List the events that start an exit decision, who decides, and how fast. Separate exit triggers (leave the service) from review triggers (update this plan). DORA Article 28(7) lists circumstances in which financial entities must be able to terminate an ICT contract (serious breach, issues found in monitoring, weaknesses in the provider's ICT risk management, loss of effective supervision); they are reasonable triggers for anyone. -->

### 3.1 Exit triggers

| Trigger ID | Trigger | Type | Decision by |
|---|---|---|---|
| CEX-TRG-01 | Provider insolvency, acquisition or withdrawal of the service or region | Stressed | Top management |
| CEX-TRG-02 | Prolonged or repeated outage beyond tolerance in the BIA | Stressed | Top management |
| CEX-TRG-03 | Serious security incident at the provider affecting our data, or loss of trust in its controls | Stressed | Top management with ISMS manager |
| CEX-TRG-04 | Material breach of contract, law or regulation by the provider | Stressed or planned | Top management with legal |
| CEX-TRG-05 | Regulator or customer requirement that the provider can no longer meet (for example, data location or supervisory access) | Planned | Top management |
| CEX-TRG-06 | Unacceptable price change or contract terms at renewal | Planned | CFO and CTO |
| CEX-TRG-07 | Strategic decision: consolidation, better alternative, return to in-house hosting | Planned | Top management |
| CEX-TRG-08 | Loss of a certification or attestation that our customers require (for example, the provider's ISO/IEC 27001 certificate) | Planned | ISMS manager proposes, top management decides |

### 3.2 Plan review triggers

Review this plan when the service architecture changes materially, a new
critical component is adopted, the contract is renewed or amended, the
alternative provider changes, an exit test produces actions, or a
relevant law or customer contract changes.

## 4. Data and asset inventory

<!-- Guidance: An exit is only as good as the inventory. List every data set and every asset you need to take with you or rebuild, with the export method and the format. Include configuration, logs needed for legal holds, and keys. Link to the asset inventory (DOC-ISMS-012). Pitfall: forgetting audit logs and backups held only by the provider. -->

| Item ID | Data or asset | Volume *(Example)* | Export method | Target format | Owner | Retention after exit |
|---|---|---|---|---|---|---|
| CEX-DAT-01 *(Example)* | Customer analytics database | 620 GB | Logical dump and logical replication | PostgreSQL dump, CSV for archive | Data platform lead | Migrated |
| CEX-DAT-02 *(Example)* | Customer uploaded files | 1.8 TB | Object storage sync tool | Original files with metadata manifest (JSON) | Platform lead | Migrated |
| CEX-DAT-03 *(Example)* | Application and audit logs | 340 GB | Export to archive storage | Compressed JSON lines | Security lead | Kept [12] months per DOC-ISMS-014 |
| CEX-DAT-04 *(Example)* | Backups | 2.4 TB | Not exported; fresh backups taken on target | Not applicable | Platform lead | Provider copies deleted |
| CEX-DAT-05 *(Example)* | Infrastructure as code and pipeline definitions | Repository | Already in our repository host | Source code | Platform lead | Kept |
| CEX-DAT-06 *(Example)* | Secrets and certificates | 210 items | Re-issued on the target, not exported | Not applicable | Security lead | Revoked at provider |
| CEX-DAT-07 *(Example)* | Encryption keys in provider key management | 12 keys | Not exportable; data decrypted in transit and re-encrypted with target keys | Not applicable | Security lead | Scheduled for deletion |
| CEX-DAT-08 *(Example)* | Monitoring dashboards and alert rules | 85 rules | Export as code where possible, rebuild otherwise | Vendor-neutral rule format or documentation | SRE lead | Rebuilt |

Total migrated data *(Example)*: 620 GB + 1.8 TB + 340 GB = 2.76 TB
(backups excluded; they are recreated on the target).

Format rules:

- Prefer open, documented, machine-readable formats (CSV, JSON, SQL
  dumps, standard archive formats) with schema documentation.
- Export metadata (owners, timestamps, access rights, tenant IDs) with
  the data, or the data loses meaning.
- Verify integrity of each export with checksums and row or object
  counts reconciled against the source.
- Protect data in transit with encryption and in staging with access
  restricted to the exit team.

## 5. Exit strategy options

<!-- Guidance: Describe the realistic options and choose a preferred one per scenario. A stressed exit usually aims to protect data and keep a minimum service; a planned exit aims for a full migration with parallel running. -->

| Option | Description | When to use | Indicative duration *(Example)* |
|---|---|---|---|
| A. Migrate to an alternative provider | Rebuild on another provider from infrastructure as code, migrate data, cut over | Planned exit, or stressed exit with notice | 12 to 16 weeks |
| B. Bring in-house | Move to own data centre or colocation | Only where capacity and skills exist | 6 to 12 months |
| C. Replace with a different product | Adopt another SaaS and migrate data, accepting process change | SaaS exits | 8 to 20 weeks |
| D. Minimum service mode | Restore critical functions from our own backups on an alternative platform while full migration continues | Stressed exit with no notice | Within the RTO for the critical subset |
| E. Retire the service | Archive data and stop the service | Service no longer needed | 4 to 8 weeks |

Preferred options *(Example, Quillmere Analytics Ltd)*: option A for a
planned exit; option D followed by option A for a stressed exit. For
option D to work, the backup policy (DOC-ISMS-061) requires a daily
copy of the customer database and object storage in a second, independent
location under our control *(Example)*.

## 6. Alternative providers and in-house option

<!-- Guidance: Name categories and shortlisted alternatives in your internal copy; do not leave this empty. Check each alternative at least yearly for capacity, security assurance, data location and price. A shortlist that has never been contacted is weak evidence. -->

| Alternative | Type | Fit | Assurance checked | Data location | Last reviewed |
|---|---|---|---|---|---|
| [Provider B] | Public cloud IaaS and PaaS | [High: managed Kubernetes and PostgreSQL available] | [ISO/IEC 27001 certificate scope and validity, SOC 2 report] | [Regions] | YYYY-MM-DD |
| [Provider C] | Regional cloud provider | [Medium: fewer managed services] | [Certificate, questionnaire] | [Regions] | YYYY-MM-DD |
| [In-house or colocation] | Own infrastructure | [Low for the small tier] | Not applicable | [Site] | YYYY-MM-DD |

Keep the target design portable: containers, standard databases,
infrastructure as code with provider modules isolated, and a documented
list of provider-specific services with their replacements.

## 7. Timeline

<!-- Guidance: Show a realistic planned-exit timeline and the stressed-exit first 72 hours. Check the timeline against the contract notice period and any statutory switching periods that apply. Example dates are fictional. -->

Planned exit *(Example, Quillmere Analytics Ltd, option A, 2027)*:

```mermaid
gantt
  title Planned exit to an alternative provider (Example)
  dateFormat YYYY-MM-DD
  section Decide
  Exit_decision_and_notice      :d1, 2027-03-01, 7d
  section Build
  Target_environment_build      :b1, after d1, 30d
  Migration_rehearsal           :b2, after b1, 14d
  section Move
  Parallel_run                  :m1, after b2, 21d
  Cutover                       :m2, after m1, 2d
  section Close
  Verify_retrieval_and_deletion :c1, after m2, 30d
```

| Phase | Start | Duration | End |
|---|---|---|---|
| Exit decision and notice | 2027-03-01 | 7 days | 2027-03-08 |
| Target environment build | 2027-03-08 | 30 days | 2027-04-07 |
| Migration rehearsal | 2027-04-07 | 14 days | 2027-04-21 |
| Parallel run | 2027-04-21 | 21 days | 2027-05-12 |
| Cutover | 2027-05-12 | 2 days | 2027-05-14 |
| Verify retrieval and deletion | 2027-05-14 | 30 days | 2027-06-13 |

Total: 7 + 30 + 14 + 21 + 2 + 30 = 104 days, about 15 weeks. Notice to
the provider is given in the first phase so that the contractual
transition period covers the parallel run and cutover; confirm the
contract allows this.

Stressed exit, first 72 hours:

| Time | Action |
|---|---|
| 0 to 4 hours | Convene the exit team; confirm the trigger; secure the latest independent backups; freeze non-essential changes |
| 4 to 24 hours | Decide option D or immediate option A; notify customers if service is affected; start building the minimum service on the alternative platform |
| 24 to 72 hours | Restore critical data sets; restore critical functions; start full export from the provider while access remains; legal assesses contract rights |

## 8. Contractual exit assistance

<!-- Guidance: Read the actual contract and the provider's terms. Record what you are entitled to and what is missing; missing items go to the next renegotiation and to the risk register. Under A.5.20, exit rights you never negotiated are rights you do not have. -->

| Item | Contract position | Gap or action |
|---|---|---|
| Termination rights and notice period | [Clause, days] | [Gap] |
| Transition period during which service continues after notice | [Clause, duration] | [Gap] |
| Data export in usable formats, at no or agreed cost | [Clause] | [Gap] |
| Data retrieval period after termination | [Clause, duration] | [Gap] |
| Exit assistance (people, documentation, cooperation with the new provider) | [Clause, rates] | [Gap] |
| Egress and switching charges | [Clause] | [Gap] |
| Deletion of all data and copies, with written confirmation | [Clause, timeframe] | [Gap] |
| Continued access to logs and audit evidence for legal holds | [Clause] | [Gap] |
| Treatment of subprocessors at exit | [Clause] | [Gap] |
| Escrow or continuity for SaaS configuration and custom code | [Clause] | [Gap] |

Supplier agreement requirements are set in DOC-ISMS-068
(`isms/supplier-security-agreement-27036`). Where the EU Data Act applies
(see section 12), check that the contract reflects its switching rights.

## 9. Roles and governance during exit

<!-- Guidance: An exit is a project or, when stressed, an incident. Name the decision owner and the team now, not during the crisis. Link to the crisis management plan for stressed exits. -->

| Role | Responsibility | Holder |
|---|---|---|
| Exit sponsor | Decides to exit, approves option and budget | [@cto] |
| Exit lead | Runs the plan, reports progress and risks | [@service-owner] |
| Platform and data leads | Build target, migrate data, verify integrity | [@platform-lead], [@data-lead] |
| Security lead | Keys, secrets, access, deletion evidence, security of the target | [@security-lead] |
| Legal and procurement | Notice, contract rights, exit assistance, deletion confirmation | [@legal-counsel], [@procurement-lead] |
| Communications | Customers, regulators, staff | [@comms-lead] |
| ISMS manager | Updates SoA, risk register, supplier register, evidence | [@isms-manager] |

A stressed exit is run under the crisis management and communications
plan (`isms/crisis-management-communications-plan`, DOC-ISMS-078) and,
where an incident is involved, the incident response plan DOC-ISMS-020.

## 10. Exit runbook

<!-- Guidance: Write the runbook as numbered, checkable steps. Each step needs an owner and a done criterion. Keep technical detail (commands, scripts) in the linked repository so this page stays readable. -->

```mermaid
flowchart TD
  A["1. Trigger confirmed and exit decided"] --> B["2. Notice and contract actions"]
  B --> C["3. Target platform built from code"]
  C --> D["4. Data exported and verified"]
  D --> E["5. Rehearsal and parallel run"]
  E --> F{"Acceptance criteria met?"}
  F -->|"No"| D
  F -->|"Yes"| G["6. Cutover and customer communication"]
  G --> H["7. Provider access revoked, data deleted, confirmation received"]
  H --> I["8. Records updated and lessons learned"]
```

| Step | Action | Owner | Done when |
|---|---|---|---|
| 1 | Confirm trigger, decide option, appoint team | Exit sponsor | Decision recorded |
| 2 | Send notice; request exit assistance; confirm transition and retrieval periods in writing | Legal | Provider acknowledgement |
| 3 | Build target environment from infrastructure as code; apply DOC-ISMS-060 baseline; set up keys, secrets, logging, backups | Platform lead | Security review passed |
| 4 | Export each item in section 4; reconcile counts and checksums; re-encrypt with target keys | Data lead | Reconciliation report signed |
| 5 | Rehearse migration; run in parallel; compare outputs | Platform lead | Acceptance criteria met |
| 6 | Cut over; monitor closely for [7] days; inform customers | Exit lead | Service stable, no Critical issues |
| 7 | Revoke provider accounts and federation; rotate shared secrets; request deletion; receive written confirmation | Security lead | Deletion confirmation filed |
| 8 | Update supplier register, asset inventory, SoA references, risk register, this plan | ISMS manager | Records updated |

Acceptance criteria *(Example)*: 100% of records reconciled; all
critical user journeys pass; performance within [10]% of baseline;
backups on the target tested by restore (DOC-ISMS-071); security
monitoring live on the target.

## 11. Testing the exit

<!-- Guidance: Test at two depths: a tabletop that walks through decisions and contract steps, and a technical test that exports real data and restores it on the alternative platform. Record results and actions. Auditors and, for DORA entities, supervisors ask for evidence that the plan was tested. -->

| Test type | Frequency *(Example)* | Scope | Evidence |
|---|---|---|---|
| Tabletop (`security/tabletop-exercise`) | At least [annually] | Decision, notice, roles, communications, contract gaps | Exercise report with actions |
| Partial technical test | At least [annually] for critical services | Export of the largest data set and restore on the alternative platform | Test record with timings and reconciliation |
| Full technical test | Every [2 to 3] years, or before contract renewal | Rebuild critical services on the alternative platform from code and backups | Test report, updated timeline |

| Test ID | Date | Type | Result | Measured | Actions |
|---|---|---|---|---|---|
| CEX-TST-001 *(Example)* | 2027-02-10 | Partial technical, Quillmere Analytics Ltd | Pass with actions | Export and restore of 620 GB database: 9 hours; reconciliation 100% | Script the restore of 14 serverless functions as containers (CEX-ACT-01) |
| CEX-TST-002 *(Example)* | 2027-09-15 | Tabletop | Pass | Decision within 2 hours; contract retrieval period found to be 15 days only | Negotiate a longer retrieval period at renewal (CEX-ACT-02) |

## 12. Regulatory examples

<!-- Guidance: List only the rules that apply to you and record them in the legal register (DOC-ISMS-014). The examples below are international illustrations, summarised in our own words; read the official text and take legal advice. -->

| Regulation | What it asks, in summary | Applies to |
|---|---|---|
| DORA, Regulation (EU) 2022/2554 (applies from 17 January 2025) | Article 28(8): exit strategies for ICT services supporting critical or important functions, so the entity can exit without disrupting its business, its regulatory compliance or its client services; exit plans that are comprehensive, documented, sufficiently tested and periodically reviewed; alternative solutions and transition plans identified. Article 28(7): circumstances in which such contracts must be terminable. Article 30(2)(h): termination rights and minimum notice periods. Article 30(3)(f): contracts for critical or important functions include exit strategies with a mandatory adequate transition period during which the provider keeps serving and the entity can migrate to another provider or in-house | EU financial entities |
| EU Data Act, Regulation (EU) 2023/2854 | Chapter VI on switching between data processing services, applicable from 12 September 2025. Article 25 contract terms include: a notice period to start switching of at most two months; switching completed within a maximum transitional period of 30 calendar days after it (where that is technically unfeasible the provider must say so within 14 working days and propose an alternative of no more than seven months; the customer may extend the period once); a data retrieval period of at least 30 calendar days after the transitional period; an exhaustive list of exportable data; erasure after retrieval. Article 29: only reduced, cost-based switching charges until 12 January 2027 and no switching charges from that date. Article 31 exempts custom-built services from some of these rules and non-production test versions from the whole chapter. Summarised in our own words; check the official text (provider-side checklist in `data/eu-data-act-readiness`) | Customers and providers of data processing services in the EU |
| GDPR | Processor contract terms on return or deletion of personal data at the end of services (Article 28(3)(g)) | Controllers using cloud processors |
| Sector outsourcing guidance | Many financial, health and public-sector regulators expect exit plans for material outsourcing | Check your sector regulator |

## 13. Costs and resources

<!-- Guidance: Estimate the cost of a planned exit so management can fund it and see the lock-in cost. All figures are examples; use your own currency. -->

| Cost line | Planned exit *(Example, USD)* |
|---|---|
| Internal effort: 3 engineers for 15 weeks at a loaded USD 2,400 per week | 108,000 |
| Data egress (2.76 TB) and transfer tooling | 1,500 |
| Parallel running of both platforms for 21 days | 9,000 |
| External migration support | 20,000 |
| Contingency (10% of the lines above) | 13,850 |
| Total | 152,350 |

Check: 3 x 15 x 2,400 = 108,000; 108,000 + 1,500 + 9,000 + 20,000 =
138,500; contingency 13,850; total 152,350. Use local currency in your
copy.

## 14. Size tiers

<!-- Guidance: Show how the plan scales. A small company may have one critical cloud platform and two critical SaaS services; a large group may need a portfolio of exit plans and a concentration view. -->

| Topic | Small: Quillmere Analytics Ltd *(Example)* | Medium: Quillmere Health Systems *(Example)* | Large: Quillmere Group *(Example)* |
|---|---|---|---|
| Profile | 46 staff; production on one public cloud provider in two regions (primary and DR) | 320 staff; two offices and one colocation suite; hosted clinical scheduling service | 2,400 staff, 6 sites in 4 countries, own data centre, IT and OT |
| Plans held | 3: production platform, productivity suite, CRM | 5: hosting platform, productivity suite, ticketing, HR, messaging for hospital notifications | Portfolio of 14 plans *(Example)* grouped by provider, with a concentration register |
| Main lock-in | Provider serverless functions and key management | Hospital integrations tied to the messaging provider | Several business units on the same hyperscaler; OT historian in a vendor cloud |
| Alternative | Second public cloud provider shortlisted; colocation not viable | Own colocation suite as fallback for core databases | Own data centre as fallback for selected workloads; second provider for others |
| Testing | Annual partial technical test, annual tabletop | Annual tabletop, partial technical test per critical plan each year | Rolling programme: each plan tested by tabletop yearly; full technical tests by risk |
| Owner | Head of Engineering Operations (0.5 FTE ISMS manager) | Service owners with the ISMS manager | Business unit owners; CISO office keeps the portfolio and reports concentration to the board |

## 15. Records and evidence

<!-- Guidance: Name the records that prove the plan exists, is current and has been tested. Link them in the control evidence matrix (`isms/control-evidence-matrix`, DOC-ISMS-033). -->

| Record | Proves | Owner | Location | Retention *(Example)* |
|---|---|---|---|---|
| Approved exit plan (this document) | A.5.23 | Service owner | [Document management system] | Current + previous 2 versions |
| Contract with exit terms and gap list | A.5.20 | Legal | [Contract repository] | Contract term + 6 years |
| Supplier register entry with criticality and exit plan link | A.5.19, A.5.22 | ISMS manager | DOC-ISMS-066 | Life of relationship + 6 years |
| Alternative provider review | A.5.23 | Service owner | [Document store] | 3 years |
| Exit test reports and action tracking | A.5.30, A.5.23 | Service owner | [Document store, tracker] | 3 years |
| Independent backup copies and restore tests | A.8.13 | Platform lead | DOC-ISMS-071 | Per backup policy DOC-ISMS-061 |
| Deletion confirmations after an actual exit | A.5.23, A.8.10 | Security lead | [Contract repository] | 6 years |
| Management decisions on triggers and exits | 9.3 inputs | ISMS manager | DOC-ISMS-085 | Per management review records |

## 16. References

<!-- Guidance: Cite only the editions you checked and re-check at each review. -->

| Reference | Edition and status (checked 2026-11-01) | Use |
|---|---|---|
| ISO/IEC 27001:2022 + Amd 1:2024 | Current; https://www.iso.org/standard/82875.html, Amd 1 https://www.iso.org/standard/88435.html | A.5.23, A.5.20, A.5.22, A.5.30, A.8.13 |
| ISO/IEC 27002:2022 | Current; https://www.iso.org/standard/75652.html | Control guidance |
| ISO/IEC 27036-4:2016 | Current; https://www.iso.org/standard/59689.html | Security of cloud services in supplier relationships |
| ISO/IEC 27017:2026 | New edition 2026-07-27; https://www.iso.org/standard/82878.html | Cloud service controls (see `isms/cloud-27017-controls`) |
| ISO/IEC 27031:2025 | Current; https://www.iso.org/standard/80975.html | ICT readiness for business continuity |
| DORA, Regulation (EU) 2022/2554 | Applies from 17 January 2025; https://eur-lex.europa.eu/eli/reg/2022/2554/oj | Example: exit strategies |
| EU Data Act, Regulation (EU) 2023/2854 | Switching rules applicable from 12 September 2025; https://eur-lex.europa.eu/eli/reg/2023/2854/oj | Example: switching between data processing services |

Related templates: `isms/cloud-services-security-policy`,
`isms/supplier-register`, `compliance/supplier-security-assessment`,
`isms/supplier-security-agreement-27036`,
`isms/ict-readiness-business-continuity-plan`,
`compliance/business-impact-analysis`, `ops/disaster-recovery-plan`,
`isms/backup-policy`, `compliance/dora-ict-risk-management-framework`,
`isms/control-evidence-matrix`.

## Standard and licence note

Structure aligned with ISO/IEC 27001:2022 + Amd 1:2024 Annex A control
A.5.23 and related controls A.5.20, A.5.22, A.5.30 and A.8.13, with
ISO/IEC 27002:2022 and ISO/IEC 27036-4:2016 as guidance. The text,
triggers, runbook and examples are original. Control numbers are cited
with short descriptive labels; no ISO/IEC text is reproduced, and you
need the official standards to implement the controls. Regulations are
summarised in our own words as international examples; this is a
documentation format, not legal advice. Check the current editions and
legal texts before use. Template licence: MIT.