Cloud Exit Plan Template (ISO/IEC 27001 A.5.23, ISO/IEC 27036-4)
Exit triggers, lock-in and data inventory, formats, strategy options, alternative providers, timeline, contract exit terms, runbook, exit tests, DORA, Data Act
使い方: Use it for every critical cloud platform or SaaS service so you can leave it in an orderly way, planned or under stress. Fill the service profile, the data and asset inventory and the contract position first. The main pitfall is a plan that has never been tested, so data that exports in theory never imports anywhere.
プレビュー
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.
Document control
| 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
- 2. Service profile and criticality
- 3. Exit triggers and plan review triggers
- 4. Data and asset inventory
- 5. Exit strategy options
- 6. Alternative providers and in-house option
- 7. Timeline
- 8. Contractual exit assistance
- 9. Roles and governance during exit
- 10. Exit runbook
- 11. Testing the exit
- 12. Regulatory examples
- 13. Costs and resources
- 14. Size tiers
- 15. Records and evidence
- 16. References
- Standard and licence note
1. Purpose and scope
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
| 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
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
| 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
| 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
| 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
Planned exit (Example, Quillmere Analytics Ltd, option A, 2027):
| 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
| 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
| 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
| 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
| 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
| 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
| 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
| 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
| 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
| 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.
関連テンプレート
Certification Cycle Plan Template (ISO/IEC 27001 3-year cycle)
3-year certificate cycle, timing rules, Gantt timeline, audit coverage, change notifications, suspension and withdrawal, recertification, transfers, budget
ISMS・ISO/IEC 27001Certification Findings Action Plan Template (ISO/IEC 27001)
CB audit findings log, correction, extent check, root cause, corrective action, CB deadlines, submission log, verification and closure
ISMS・ISO/IEC 27001Cloud Service Controls Template (ISO/IEC 27017:2026)
Cloud customer and provider controls: role determination, shared responsibility matrix, implementation table, extra cloud controls, disclosures, monitoring