Cloud Concentration Risk and Exit Strategy Guide: Planning to Leave Before You Must

Most organisations could not leave their main cloud provider within a year, and few have tested whether they could keep critical services running if that provider failed or had to be exited quickly. Regulators now expect a documented, tested answer: the UK PRA's outsourcing supervisory statement SS2/21 asks for stressed and non-stressed exit plans, DORA requires exit strategies for ICT services supporting critical or important functions, and the EU Data Act gives every cloud customer switching rights and removes switching charges from 12 January 2027. This guide covers how to measure cloud concentration, what a credible exit strategy contains, how identities, keys and secrets lock you in, and how to test an exit without leaving. It is for cloud, risk and resilience leads and for executives who must sign off that exit is feasible.

Key takeaways

• Concentration is layered. Exposure comes from one provider, one region, shared fourth parties and the identity and key services that everything else depends on, not only from the headline hyperscaler contract.
• Stressed exit is the case that matters. The PRA states its main focus is on stressed exit and continuity, where the provider fails or becomes unavailable and there is no time for a negotiated migration.
• Multi-cloud is an option, not a requirement. SS2/21 asks firms to choose one or more cloud resiliency options on a risk basis; a single provider with tested regional resilience and a credible exit plan can be defensible.
• Identity and keys are the hardest things to move. Provider-native IAM roles, workload identities and non-exportable encryption keys must be rebuilt, not copied, and data encrypted under a provider key may be unreadable elsewhere.
• Test exit in slices. Restoring one critical service in an alternative environment, with real data and rebuilt identities, proves more than any paper plan.

What cloud concentration risk means

DORA defines ICT concentration risk as an exposure to individual or multiple related critical ICT third-party service providers creating a degree of dependency on such providers so that their unavailability, failure or other shortfall may potentially endanger the ability of a financial entity to deliver critical or important functions. The definition is written for financial services but describes the problem for any organisation. The PRA's SS2/21 (paragraph 5.24) lists the forms concentration takes: multiple arrangements with the same or closely connected providers, fourth-party dependencies on a shared sub-contractor, arrangements with providers that are difficult or impossible to substitute, and concentration of dependencies in one geographic location or jurisdiction.

Systemic concentration is also a supervisory concern. In the UK, FSMA 2023 lets HM Treasury designate critical third parties (CTPs) whose failure could threaten financial stability; the Bank of England, PRA and FCA final rules (PS16/24, published 12 November 2024) took effect on 1 January 2025 and include eight operational risk and resilience requirements, one of which covers termination of services. DORA's oversight framework does the same for critical ICT third-party providers in the EU. Oversight of the provider does not remove the customer's own obligation to manage its exposure and plan exit. For the wider supplier picture, see the Third-Party Concentration Risk Guide.

Regulatory expectations for exit

Data Act timing: the Data Act applies from 12 September 2025. The European Commission explains that providers could still charge for switching as a transitional measure during the first three years after entry into force (11 January 2024 to 12 January 2027), and that from 12 January 2027 switching charges, including data egress charges, are removed entirely. The Regulation also caps notice and transition periods for switching; read Chapter VI for the exact limits before relying on them in a plan.

DORA wording: the official EUR-Lex text was truncated when fetched for this guide, so Article 28(8) is paraphrased here from the Regulation as it stands: exit strategies must address provider failure, deteriorating service quality, business disruption and contract termination, and must be supported by comprehensive, documented and sufficiently tested exit plans, reviewed periodically, with alternative solutions and transition plans identified. Check the article text on EUR-Lex for exact wording.

Stressed and non-stressed exit

SS2/21 paragraph 10.1 distinguishes exit in stressed circumstances, such as the failure or insolvency of the provider, from a planned and managed exit for commercial, performance or strategic reasons. They need different plans.

A stressed exit plan is really a continuity plan, so it should share recovery objectives with the business impact analysis. See the Business Continuity and Disaster Recovery Guide and the Cloud Recovery and Clean Room Guide.

What a credible exit plan contains

• Scope and trigger: the services covered, their importance, and the events that activate stressed and non-stressed exit, with a named decision maker.
• Dependency map: every workload, data store, managed service, identity, key and network path the service uses, including fourth parties.
• Destination options: an alternative provider, a second region with independent control plane dependencies, on-premises, or a degraded manual process, each with estimated time and cost.
• Data plan: where an up-to-date copy lives outside the provider, its format, how integrity is checked, and how long reload takes at production volume.
• Identity and key plan: how human access, workload identities, secrets and encryption keys are re-established at the destination (next section).
• Contract terms: transition assistance, a transition period, data return in usable formats, deletion certificates, and audit and access rights. SS2/21 paragraph 6.4 expects contracts to support termination testing and prompt data access if the provider becomes insolvent.
• People and skills: who can operate the destination platform, and whether that depends on the provider's professional services.
• Post-exit tasks: data deletion at the outgoing provider (SS2/21 7.11), credential revocation and closure of federation trusts.

Identity, secrets and key portability

Workloads can be containerised and data exported, but the identity layer is provider-specific by design. This is where many exit plans quietly fail.

Keys deserve special attention. AWS documentation, for example, states that AWS KMS does not support decrypting ciphertext encrypted under a symmetric KMS key outside AWS KMS, even when the key material was imported, because the ciphertext format is not published. Imported key material lets you keep the original copy outside the provider for durability and disaster recovery, but data still has to be decrypted and re-encrypted during exit. Plan the re-encryption step, its duration and the keys it needs. See the Cryptographic Key Management Guide.

Rotation is part of exit. Every non-human credential that touched the outgoing environment should be treated as exposed at cut-over: rotate secrets, revoke tokens and remove federation trusts, then confirm no workload still authenticates to the old tenant. See the Secrets Management Guide.

Implementing and testing an exit strategy

1. Inventory and tier. List cloud services supporting important business services, record provider, region, managed services used and fourth parties, and rate substitutability (SS2/21 5.19).
2. Assess concentration. Aggregate exposure by provider, region and shared fourth party; report it to the risk committee alongside impact tolerances.
3. Reduce avoidable lock-in. For new builds, require an exit note in the architecture review: proprietary services used, export path, identity model and key ownership.
4. Hold data and keys outside the blast radius. Keep a current, restorable copy of critical data and the keys to read it in a location that does not depend on the primary provider's control plane or identity.
5. Write the plans. One stressed and one non-stressed plan per important service, using the contents above, approved by the service owner.
6. Test in slices. Start with a desk-based walkthrough, then restore one service in the alternative environment with rebuilt identities and secrets, measure the time, and compare it with the impact tolerance. Run the test in an isolated environment so it cannot disturb production; roll back by tearing the test environment down and revoking any credentials it created.
7. Negotiate the contract. Add transition assistance, data return formats, test support and deletion confirmation; record which Data Act switching rights apply.
8. Review annually and on change. Re-test when the architecture, provider or regulation changes.

Decision guidance

• Single provider with strong exit plan: suits most organisations; lower complexity and cost, with risk addressed through multi-region design, data held outside the provider and a tested stressed-exit slice.
• Active multi-cloud for specific services: justified where impact tolerance is very short and provider failure is a plausible scenario; costs include duplicated skills, two identity models and the loss of proprietary services.
• Hybrid fallback: a minimal on-premises or alternative-provider capability for the few services that must survive provider loss.
• Small organisations: focus on data portability, independent backups, an independent identity provider and a documented manual workaround; full multi-cloud is rarely proportionate.
• Large or regulated organisations: expect supervisors to ask for evidence of tested exit for material arrangements and of concentration monitoring at group level.

Detection and measurement

Monitor provider health dashboards and status feeds, resource creation in unapproved regions, adoption of new proprietary managed services, and the location of backups and keys. Track exit readiness in the same risk reporting as other resilience measures.

• Concentration share: percentage of important business services dependent on a single provider and on a single region.
• Exit plan coverage: percentage of material cloud arrangements with approved stressed and non-stressed exit plans.
• Tested exit time: measured time to restore each tested service elsewhere, compared with its impact tolerance.
• Portable data and keys: percentage of critical data with a current, restorable copy and readable keys outside the primary provider.
• Identity portability: percentage of workload identities and secrets defined as code and inventoried per service.

Framework mapping

Common failure patterns

• Backups inside the same provider and identity domain. When the tenant is compromised, suspended or unavailable, the backups go with it. Keep at least one copy under separate credentials and control. See the Backup Identity Isolation Guide.
• Exit plan written for procurement, not operations. A contract annex lists data return clauses but nobody has estimated how long it takes to move petabytes or rebuild hundreds of IAM roles.
• Keys forgotten. Data is exported but encrypted under non-exportable provider keys, or the exported copy depends on secrets that only exist in the outgoing provider's secrets manager.
• Fourth-party blindness. The organisation diversifies its own hosting while its payment, CRM and messaging suppliers all run in the same provider region. See the Third-Party Risk Management Guide.
• Multi-cloud on paper. A second provider account exists but hosts nothing current, with no tested deployment pipeline or identity setup.
• Old credentials left alive. After migration, service accounts, federation trusts and API keys in the old tenant are never revoked and remain an access path to data that was not deleted.

For incident-driven lessons on what happens when a widely used provider fails, see the Major IT Outage Lessons Guide.

Practitioner checklist

• Map every important business service to its cloud providers, regions, managed services and fourth parties.
• Report concentration by provider, region and shared fourth party to the risk committee at least annually.
• Approve a stressed and a non-stressed exit plan for each material cloud arrangement.
• Keep a current, restorable copy of critical data, and readable keys, outside the primary provider's control plane and identity.
• Define workload identities, policies and secrets as code and inventory them per service.
• Test a stressed-exit slice for at least one important service a year and compare measured time with impact tolerance.
• Include transition assistance, data return formats, test support and deletion confirmation in cloud contracts, and record Data Act switching rights.
• Rotate and revoke every credential and federation trust tied to an exited environment, and confirm data deletion.

Standards and references

• Bank of England PRA: SS2/21 Outsourcing and third party risk management
• EUR-Lex: Regulation (EU) 2022/2554 Digital Operational Resilience Act
• European Commission: Data Act explained
• European Commission: Data Act
• Bank of England PRA: PS16/24 Operational resilience, critical third parties to the UK financial sector
• AWS: Importing key material for AWS KMS keys
• NIST: SP 800-53 Rev. 5
• NIST: Cybersecurity Framework 2.0

Related NHI Mgmt Group resources: Third-Party Concentration Risk Guide · Cloud Recovery and Clean Room Guide · Cloud Security Guide · DORA Guide · Business Continuity and Disaster Recovery Guide