Cloud Concentration Risk Under DORA, SS1/21 and the CTP Regimes

A practical reading of cloud concentration risk under DORA’s CTPP regime, the PRA’s SS1/21, and the UK Critical Third Party framework — written for the financial firms that depend on a small number of hyperscaler clouds and need to demonstrate they have thought about it.

The financial services sector’s dependence on a small number of cloud providers — predominantly AWS and Microsoft Azure, with Google Cloud as the third — has been a supervisory concern for nearly a decade. Three regulatory regimes now converge on it. DORA’s Critical ICT Third-Party Provider framework introduces direct EU oversight. The PRA’s SS1/21 expects UK banks and insurers to manage outsourcing concentration. The UK Critical Third Party regime gives the Bank of England, PRA, and FCA direct supervision over designated CTPs. None of these regimes prohibits cloud concentration. All of them expect firms to have thought about it.

This is a reading of what cloud concentration risk means concretely in each regime, where the regimes overlap, and the six things firms should actually do.

Free · 4 minutes

If your most senior engineer left tomorrow, would anyone still understand the system?

Fourteen questions on documentation, dependencies, and the gap between how the architecture works and how many people know it. Banded finding on screen, full sheet by email.

What “cloud concentration risk” means in each regime

Under DORA. Concentration is one of the criteria the ESAs use to designate Critical ICT Third-Party Providers. A provider serving a meaningful share of EU financial entities — particularly across multiple Member States and across multiple sectors — meets the criteria. Once designated, the provider comes under direct ESA oversight. For financial entities, DORA Article 28 requires assessment of concentration at firm level and obligations on the third-party register, contractual arrangements, and exit plans.

Under PRA SS1/21. Outsourcing concentration is one of the factors firms must assess when entering or maintaining material outsourcing arrangements. The supervisory expectation is that firms understand their exposure, document the concentration considerations in board reporting, and have viable exit strategies — particularly for cloud arrangements supporting important business services.

Under the UK CTP regime. The BoE, PRA, and FCA jointly designate Critical Third Parties — providers whose failure would pose risks to UK financial stability. The first wave of designations published in 2024–2025 includes the major hyperscaler cloud providers. Designation does not remove the firm’s own accountability for managing the dependency; it adds supervisory oversight of the provider itself.

Who this is for

  • The CTO or CISO at an EU or UK financial firm whose principal cloud dependencies are with one or two hyperscaler providers.
  • The head of operational resilience preparing the firm’s documentation for the next supervisory engagement.
  • The board member with technology risk responsibility looking for a defensible position on cloud concentration.

Where the regimes overlap and diverge

The three regimes converge on substance more than they diverge:

  • All three expect firms to maintain a register of material technology providers with concentration analysis.
  • All three expect documented, costed exit strategies for material providers, with exit testing where appropriate.
  • All three expect contractual provisions that allow supervisory access, audit, and information.
  • All three expect operational resilience scenarios that include cloud provider failure.

The divergence is in mechanics. EU and UK designation lists are not identical. Reporting templates, registers, and incident notification formats differ. Firms operating in both jurisdictions need consolidated arrangements that satisfy both supervisory readings.

The exit testing question

The single hardest practical issue in cloud concentration management is exit. Cloud platforms are not commodity infrastructure; each has its own native services, identity model, data formats, and operational patterns. An “exit” from one hyperscaler to another is not a configuration change — it is a major engineering programme of months to years and millions of euros of cost.

Supervisors know this. The expectation is not that exit is easy; the expectation is that the firm has thought about it honestly. A credible exit position needs:

  • An identified target architecture (where the workloads would go).
  • A realistic timeline (typically years for complex estates).
  • A realistic cost (typically multiples of the annual cloud spend for a year or two).
  • An identification of which workloads are easier and which are harder.
  • Some form of testing — desktop walkthroughs at minimum, partial migrations where feasible.

What does not pass supervisory scrutiny: a one-line statement that the firm “could move to another provider if necessary.”

The multi-region vs multi-cloud question

Some firms address concentration through multi-region deployment within a single provider; others pursue multi-cloud. Both are defensible positions, with different trade-offs:

Multi-region within one provider addresses regional failure, regional regulatory disruption, and many operational scenarios. It does not address provider-level failure (a single-provider control plane incident affecting all regions) or provider-level financial or regulatory disruption.

Multi-cloud addresses provider-level failure but introduces operational complexity, dual-vendor cost, and architectural compromise (lowest-common-denominator services). It also creates two third-party relationships to manage instead of one.

The honest answer is that for most firms, multi-region with a single provider plus a documented, costed exit position is more defensible and more operationally sustainable than partial multi-cloud.

Six things firms should actually do

1. Map cloud exposure by important business service. Which services depend on which cloud(s), in which region(s). Not the abstract architecture diagram — the actual service-to-cloud mapping.

2. Document the third-party register with concentration analysis. Per DORA Article 28 and equivalent UK expectations. Concentration considerations explicit, not implicit.

3. Build operational resilience scenarios that include cloud provider failure. Multi-region scenarios are not sufficient; provider-level scenarios need to be in the inventory.

4. Document an honest exit position. Identified target, timeline, cost, with testing evidence at the level the firm can credibly achieve.

5. Reflect designation status in contracts and supervision. Designated CTPs have their own obligations; the firm’s contractual posture and supervisory engagement should reflect this.

6. Take this to the board. Cloud concentration is a board-level risk. Annual board reporting on concentration position is the supervisory expectation.

How we engage with this

We read cloud concentration posture across DORA, SS1/21, and CTP expectations. As a Supplier and Dependency Review scoped to cloud concentration, we read the third-party register, the exit plans, the operational resilience scenarios, the board reporting, and the contractual position with material providers. The output is a written assessment of where the firm’s position would survive — or not — its next supervisory engagement.

We do not run exit tests. We do not migrate workloads. We do not negotiate contracts. We read what is there and write it down.

Pricing is published at /pricing/. If your firm is preparing for supervisory engagement on operational resilience, third-party risk, or cloud concentration specifically, the place to start is a conversation.

Sixteen Pillars is a technology governance consultancy based in Cyprus. Engagements run remote across the EU, UK, and Middle East, with on-site time where the engagement requires it.

Most technology problems are not technology problems. They are control problems.

The systems exist. The investment has been made. The question is whether leadership can understand, direct, evidence, and sustain what those systems produce. Find out where control exists — and where it only appears to.

Full Governance by Sixteen Pillars

Govern your business. Prove your compliance.

A board assurance cockpit for EU-regulated financial firms — tamper-evident, hash-chained proof of governance across DORA, GDPR, NIS2, ISO 27001, the EU AI Act and MiCA. In development.

See what's coming