Cloud Exit Plan Template: Document How You Would Leave a Critical Provider

Most organisations can describe how they moved into a cloud or SaaS provider, but very few have written down, step by step, how they would get out again if they had to. This template gives you the sections of a documented exit plan for one critical provider: scope, triggers, data return, alternative providers, timelines, identity and key portability, testing and post-exit tasks. It is built around the exit plan expectations in the EU Digital Operational Resilience Act (DORA), its regulatory technical standards on contractual arrangements, and the EBA Guidelines on outsourcing arrangements, and it works just as well for firms with no regulator asking. Use one completed copy per provider or per contractual arrangement. It is for resilience, third-party risk, cloud platform and procurement teams. For the background on concentration risk and exit strategy, see the Cloud Concentration Risk and Exit Strategy Guide.

How to use this template

• Complete one plan per provider or contractual arrangement that supports a critical or important function. Delegated Regulation (EU) 2024/1773 Article 10 expects a documented exit plan for each contractual arrangement in scope.
• Replace text in square brackets, such as [Organisation], [Provider] and [Service owner], with your own terms. Delete guidance notes in italics once completed.
• "Must" marks a requirement; "should" marks recommended practice where a justified exception is allowed.
• Write for a stressed exit first (the provider has failed or must be left quickly). A planned, non-stressed exit is easier and reuses most of the same content.
• Keep the plan with your business continuity plan and the contract. EBA/GL/2019/02 paragraph 106 expects the exit strategy to be consistent with the outsourcing policy and business continuity plans.
• Review and test at the frequency set in section 11, and after any material change to the service, contract or provider.

Regulatory anchors for this template

DORA article wording above is paraphrased; check the text on EUR-Lex before quoting it in a regulatory submission. See the DORA Guide and the EU Data Act Guide.

1. Plan identification and ownership

• Provider and service: [Provider], [service names, account or tenant IDs, regions].
• Contract reference: [contract ID], start date [date], renewal date [date], notice period [days].
• Register of information reference: [entry ID]. See the DORA ICT Third-Party Risk and Register of Information Guide.
• Plan owner: [Service owner], accountable for keeping the plan current.
• Exit decision maker: [role, for example COO or management body delegate], with deputy [role].
• Approval: approved by [governance forum] on [date]; version [x.y]; next review [date].

2. Objectives and success criteria

State what a successful exit looks like. EBA/GL/2019/02 paragraph 108 asks firms to define the objectives of the exit strategy and success criteria for the transition of outsourced functions and data.

1. Objective: [Organisation] can move [service] to [destination] or stop using it, without undue disruption to business activities, without breaching regulatory obligations and without harm to customers.
2. Service continuity: the function stays within its impact tolerance or maximum tolerable downtime of [hours] throughout the exit.
3. Data: 100% of in-scope data returned in [formats], reconciled against record counts and checksums, with integrity confirmed by [role].
4. Access: no [Organisation] identity, credential, key or federation trust remains active at [Provider] after [date + days].
5. Evidence: a deletion confirmation from [Provider] received within [days] of data return.

3. Scope, criticality and exit scenarios

• Functions supported: [list of business functions], classified as [critical or important / other] on [date].
• Business impact analysis: reference [BIA ID]; recovery time objective [hours]; recovery point objective [minutes or hours].
• Substitutability: [easily substitutable / substitutable with effort / hard to substitute], with the reason.

4. Exit triggers and decision process

EBA/GL/2019/02 paragraph 108 expects indicators that trigger an exit. Define them so the decision is not improvised during an incident.

1. Monitoring indicators: [availability below x% over y months], [more than n severity 1 incidents per quarter], [loss of ISO/IEC 27001 or SOC 2 report], [credit rating or financial distress signal], [unapproved material sub-outsourcing], [unresolved security finding older than n days].
2. Escalation: a trigger breach is reported to [Plan owner] within [hours] and to [Exit decision maker] within [hours].
3. Decision options: continue with remediation plan; prepare for exit (warm standby); invoke stressed exit; invoke planned exit.
4. Record: every decision is logged with date, evidence and approver in [system].

5. Contractual exit provisions

List what the contract actually says, clause by clause. If a provision is missing, record it as a gap with a remediation owner.

• Termination rights: grounds available to [Organisation], including breach, material change such as sub-outsourcing, data security weaknesses and regulator instruction (EBA/GL/2019/02 paragraph 98). Clause [ref].
• Transition period: [months] of continued service after notice, at [pricing] (DORA Article 30(3)(f)). Clause [ref].
• Transition assistance: provider support for orderly transfer, named contacts, hours and rates (EBA/GL/2019/02 paragraph 99). Clause [ref].
• Data return: formats, schedule, completeness and any charges; note that Data Act switching charges fall away from 12 January 2027. Clause [ref].
• Data deletion: method, timing and written confirmation. Clause [ref].
• Insolvency access: how [Organisation] retrieves data if the provider fails. Clause [ref].
• Audit and access rights: retained during the transition. Clause [ref].

6. Data return and migration

1. Data inventory: [data stores, object buckets, databases, logs, backups, configuration], with volume [TB] and owner.
2. Independent copy: where a current copy lives outside [Provider] ([location]), its frequency [schedule] and how it is protected from provider-side deletion. See the Backup Security and Immutable Backup Guide.
3. Export method: [native export, API, bulk transfer device, replication], tested at production volume on [date], taking [hours].
4. Formats: [open or machine-readable formats, for example CSV, Parquet, JSON, SQL dump], plus schemas and metadata.
5. Integrity checks: record counts, checksums and sample reconciliation signed off by [role].
6. Logs and evidence: audit logs retained for [years] to meet [regulatory requirement] are exported before access ends.

7. Alternative solutions and destination options

Guidance: name a preferred option for each scenario in section 3. Option C does not count as an exit from the provider.

8. Transition plan and timeline

1. Day 0: exit decision recorded; communication plan started (section 10); notice served if planned exit.
2. Days 1 to [n]: destination environment provisioned; identity, network and key infrastructure prepared (section 9).
3. Days [n] to [m]: data exported, transferred and reconciled; applications rebuilt from infrastructure as code where available.
4. Cutover: [date or relative day]; rollback criteria: [criteria]; rollback path: remain on [Provider] within the transition period.
5. Stabilisation: [weeks] of parallel monitoring before the provider service is decommissioned.

The schedule must fit inside the contractual notice and transition periods recorded in section 5 (Delegated Regulation (EU) 2024/1773 Article 10).

9. Identity, secrets and key portability

• Human access: how administrators and users authenticate at the destination, including federation from [identity provider] and break-glass accounts.
• Workload identities and secrets: list of service accounts, API keys, OAuth clients and certificates that depend on [Provider], and the replacement for each. See the Third-Party Risk Management Guide.
• Encryption keys: where keys are held, whether they can be exported, and how data encrypted with provider-managed keys is decrypted before export. See the BYOK, HYOK and External Key Management Guide.
• DNS, certificates and endpoints: domains, TLS certificates and IP allow lists that need re-pointing.

10. Roles, resources and communications

• Exit lead: [role]; technical lead: [role]; data lead: [role]; legal and procurement: [role]; communications: [role].
• Skills: named staff or partners able to run the destination platform without relying on [Provider]'s professional services.
• Budget: pre-approved contingency of [amount] for stressed exit.
• Stakeholders to notify: customers, [competent authority] where required, auditors, dependent internal teams.

11. Testing and review

1. Tabletop: walk through the stressed scenario with the decision maker and leads at least [annually].
2. Technical test: export a representative data set at production volume and restore it at the destination at least [annually]; record duration and integrity results.
3. Full or partial failover: for the highest criticality services, run [component] at the alternative destination for [period] every [interval].
4. Review triggers: contract change, new sub-outsourcing, new service features adopted, change in criticality, or a failed test.
5. Findings: logged in [system] with owners and due dates, reported to [governance forum].

12. Post-exit closure

1. Revoke all credentials, OAuth grants, federation trusts and API keys issued to or by [Provider].
2. Obtain written confirmation of data deletion, including backups, within [days].
3. Update the register of information, asset inventory and business continuity plan.
4. Run a lessons learned review within [days] and update this template.

Implementation guidance

• Start with the highest criticality providers: complete plans first for hard-to-substitute services that support critical or important functions, then work down the register.
• Measure it: track the share of critical providers with an approved plan, the share tested in the last 12 months, the measured export time at production volume against the RTO, the number of open contractual gaps from section 5, and the count of provider-dependent credentials without a named replacement.
• Common failure patterns: plans that only describe a second region at the same provider; data export never tested at real volume; keys that cannot leave the provider; transition periods shorter than the measured migration time; and plans owned by procurement with no technical lead.
• Framework mapping: NIST SP 800-53 Rev 5 CP-2 Contingency Plan, SA-9 External System Services and SR-2 Supply Chain Risk Management Plan; NIST CSF 2.0 GV.SC-10 (provisions for activities after a partnership or service agreement ends).
• Small organisations: a two-page plan per key SaaS provider covering data export, an alternative product and credential revocation is a credible start.

Standards and references

• EUR-Lex: Regulation (EU) 2022/2554 (DORA)
• EUR-Lex: Commission Delegated Regulation (EU) 2024/1773 on contractual arrangements for ICT services
• EBA: Guidelines on outsourcing arrangements (EBA/GL/2019/02)
• Bank of England PRA: SS2/21 Outsourcing and third party risk management
• European Commission: Data Act
• NIST: SP 800-53 Rev 5

Related NHI Mgmt Group resources: Cloud Concentration Risk and Exit Strategy Guide · DORA Guide · Business Continuity Plan Template · Third-Party Risk Management Guide. This template summarises regulatory expectations and is not legal advice.