| Regime | Jurisdiction | Core mechanism | Status as of mid-2026 |
|---|---|---|---|
| DORA (Digital Operational Resilience Act) | European Union | Direct oversight of designated Critical ICT Third-Party Providers by European Supervisory Authorities | In force since 17 January 2025; 19 CTPPs formally designated, including AWS, Google Cloud, and Microsoft |
| Critical Third Parties (CTP) regime | United Kingdom | Joint BoE/PRA/FCA oversight of firms designated by HM Treasury as critical to financial stability | Rules in force from 1 January 2025; major cloud providers subject to direct resilience and incident-reporting oversight |
| FSOC annual report framework | United States | Monitoring and recommendation (no direct designation power over cloud providers to date) | 2024–2025 reports flag cloud/third-party concentration as a growing systemic risk category |
| NIS2 Directive | European Union | Cybersecurity risk management obligations for essential and important entities, including cloud providers | Transposed into national law across member states; complements DORA for ICT providers |
Why “Concentration Risk” Suddenly Applies to Cloud Providers
Concentration risk is an old idea in finance — it’s the reason regulators worry when too many banks hold the same asset, or too much lending flows through too few counterparties. What changed by 2026 is that the same logic now applies to infrastructure. A small number of hyperscale cloud providers host the core computing, storage, and increasingly the AI inference layer for a large share of banks, insurers, hospitals, and government agencies simultaneously. When that shared dependency sits underneath organizations that are supposed to be independent of one another, a single provider’s outage, misconfiguration, or breach stops being that provider’s problem and becomes a sector-wide one.
This isn’t theoretical. Multiple high-profile cloud outages over the past several years have taken down banking apps, payment rails, airline check-in systems, and healthcare scheduling tools within the same hour, across companies with no formal relationship to each other beyond sharing a cloud region — a pattern our broader look at where cloud computing is headed through the rest of the decade flags as an increasingly central risk consideration, not just a growth story. The Financial Stability Board has explicitly noted that concentration in third-party technology providers serving large numbers of financial institutions increases the risk of concurrent, correlated events that can amplify a crisis rather than contain it — the opposite of what diversification is supposed to deliver.
The US Financial Stability Oversight Council’s most recent annual reporting cycle identifies third-party service provider concentration — cloud computing chief among them — as a systemic operational risk of growing significance, describing the resulting exposure as “single-point operational risk with limited substitutability.” That phrase matters: it’s not just that a provider might fail, it’s that if it does, there may be nowhere else to quickly move the workload.
Figure 1: The Concentration Risk Chain
A diagram showing a single hyperscale region hosting core workloads for a bank, an insurer, a hospital network, and a government payments processor simultaneously. An outage or breach at the shared provider propagates outward through each institution independently and at the same time, producing a correlated shock across sectors that would otherwise be considered unrelated to each other from a traditional risk-diversification standpoint.
What “Too Big to Fail” Means When Applied to a Cloud Provider
“Too big to fail” originally described banks whose collapse would be so damaging to the broader economy that governments would intervene rather than let them fail — which in turn created moral hazard, since the institution knew a bailout was likely. Applying the phrase to cloud providers is imperfect but instructive. No government is going to nationalize a hyperscaler’s data centers. What regulators are doing instead is treating systemic cloud dependency as a resilience problem to be managed directly, rather than a private commercial risk between a bank and its vendor.
That’s precisely the logic behind DORA’s Critical ICT Third-Party Provider designation and the UK’s Critical Third Parties regime: instead of waiting for a failure and assigning blame afterward, regulators now directly assess whether the provider itself has adequate risk management, testing, and incident-reporting practices — the same category of scrutiny previously reserved for the banks and insurers themselves. In November 2025, the European Supervisory Authorities published their first list of 19 designated CTPPs under DORA, including AWS, Google Cloud, and Microsoft alongside data center operators and telecom providers, each of which must now designate an EU-based coordination entity and pay oversight fees. The UK’s parallel regime went live around the same period, giving the Bank of England, PRA, and FCA joint authority to assess resilience, testing, and incident response at firms HM Treasury formally designates as critical.
The practical effect is a new category of quasi-utility regulation for infrastructure that was, until recently, treated as an ordinary vendor relationship. Financial institutions can no longer treat “we outsourced it to AWS” as a complete answer to a resilience question — under both DORA and the UK regime, the institution remains accountable for the outcome even while the provider is separately and directly overseen.
How Concentration Risk Actually Materializes
It helps to separate concentration risk into the distinct failure modes regulators actually worry about, because “the cloud might go down” undersells the range of exposure.
Figure 2: Four Faces of Concentration Risk
A simple quadrant: (1) Availability risk — a regional or global outage takes multiple unrelated institutions offline at once; (2) Security risk — a single vulnerability or compromised credential at the provider level cascades across every tenant using the affected service; (3) Contractual/exit risk — switching costs and proprietary managed services make it operationally and financially infeasible to leave, even when a provider’s terms or reliability degrade; (4) Data/AI model risk — increasing reliance on a hyperscaler’s native AI and data platform services creates a second, less visible layer of lock-in on top of raw infrastructure dependency.
Availability risk is the most visible and the one regulators cite most often — a single provider’s regional outage cascading across airlines, banks, and hospitals within the same hour has happened often enough to move from anecdote to expected scenario in resilience planning. Security risk is subtler: a single misconfiguration or vulnerability in a widely used managed service (an identity provider, a DNS layer, a common SDK) can simultaneously expose every tenant that depends on it, turning what looks like isolated multi-tenancy into a shared attack surface. Contractual and exit risk is the one DORA is most explicit about — Article 28 requires financial entities to maintain documented exit strategies for critical ICT arrangements precisely because switching costs (data egress fees, proprietary APIs, retrained staff) tend to be discovered only when an institution actually tries to leave — a cost-visibility problem similar to the one covered in our guide to FinOps for autonomous AI workloads, where costs hidden inside a provider’s proprietary tooling only become visible once someone actually tries to audit or move them. Data and AI model risk is the newest and least mature category: as banks and hospitals adopt a hyperscaler’s native AI and data platform tooling, the lock-in shifts from “where our servers run” to “whose model and data pipeline our decisions depend on,” a concern discussed further in our piece on AI in financial services and algorithmic risk management.
| Failure mode | Regulatory hook | Typical mitigation |
|---|---|---|
| Regional/global outage | DORA resilience testing; UK CTP incident reporting | Active-active multi-region or multi-provider deployment for critical functions |
| Shared vulnerability/breach | DORA ICT risk management; NIS2 cybersecurity obligations | Independent monitoring layer, credential isolation, blast-radius segmentation |
| Exit/switching cost lock-in | DORA Article 28 exit strategy requirement | Documented, tested exit plans; avoidance of deep proprietary API dependency for critical workloads |
| AI/data pipeline lock-in | Emerging guidance; not yet formally codified in most regimes | Model and data portability requirements written into vendor contracts up front |
The Regulatory Response, Sector by Sector
Financial services is furthest ahead because the systemic stakes are clearest and the regulators already had oversight muscle from the post-2008 reforms. DORA and the UK CTP regime both extend existing operational resilience frameworks to cover the ICT layer explicitly, rather than treating cloud vendors as an afterthought bolted onto vendor risk management policies. The Financial Stability Board’s cross-border coordination work — including its report on cloud adoption and concentration in the financial sector — reflects an understanding that concentration risk doesn’t respect national borders even when individual regulatory regimes do.
Other critical infrastructure sectors are earlier in the process. Healthcare regulators have historically focused on data privacy (HIPAA) rather than infrastructure concentration per se, though the same underlying dependency exists — a small number of cloud and EHR platform vendors now host clinical systems for a large share of hospital networks, even as the broader privacy compliance profession (see our coverage of the growing demand for data privacy officers) increasingly gets pulled into vendor concentration questions that were previously treated as pure infrastructure decisions. Government and public sector oversight runs through frameworks like FedRAMP, which govern which providers agencies may use but don’t yet formally address what happens if the small set of FedRAMP-authorized hyperscalers experience a correlated failure across multiple agencies simultaneously.
The common thread across sectors is a shift from indirect oversight (regulate the bank, let the bank manage its vendors) to direct oversight (regulate the systemically important vendor too). That shift is the real story of 2025–2026 cloud policy, and it has direct implications for how institutions architect around the risk — a topic covered in depth in our companion piece on hybrid cloud architecture patterns for regulated industries, where control-plane/data-plane splits and multi-provider resilience patterns are the practical response to exactly this regulatory pressure.
- Inventory your critical dependencies.Build a register of every ICT third party supporting a critical or important function, not just your primary cloud provider — DORA’s Article 28 register requirement is a useful template even outside the EU.
- Classify by substitutability.For each critical dependency, honestly assess how quickly and at what cost you could replace it. Low substitutability plus high criticality is where concentration risk actually bites.
- Test resilience, not just backups.Run scenario exercises assuming your primary provider is unavailable for an extended period, not just a brief outage — regulators increasingly expect evidence of testing, not just a disaster-recovery document.
- Negotiate exit terms before you need them.Data egress costs, format portability, and transition support should be contract terms agreed at signing, not discovered during a crisis exit.
- Separate the monitoring layer.Keep at least your security monitoring and incident detection independent of the primary provider’s own tooling, so a provider-side incident doesn’t also blind your ability to detect it.
- Track AI and data lock-in separately from infrastructure.Model dependency and data pipeline lock-in move faster than regulation currently accounts for — get ahead of it contractually rather than waiting for a formal requirement.
- Report up, not just across.Make concentration risk a board-level risk category with its own metrics and reporting cadence, not a line item buried inside a broader vendor management report.
Common mistakes
- Confusing multi-region with multi-provider. Running across three regions of the same hyperscaler still leaves you exposed to a global control-plane or identity-service failure at that one provider.
- Treating the exit strategy as a paper exercise. An exit plan that has never been tested against real data volumes and proprietary service dependencies typically underestimates both cost and time by a wide margin.
- Assuming the provider’s SLA covers your regulatory exposure. A service credit for downtime does not satisfy a regulator asking why a critical function had no resilience alternative.
- Ignoring AI service dependency as “just another API.” A hyperscaler’s proprietary model and data platform can create deeper lock-in than raw compute, precisely because it’s newer and less scrutinized by existing vendor risk frameworks.
- Waiting for formal designation before acting. Institutions that wait until their provider is formally named a CTPP or CTP before building resilience plans are starting the hardest work under the least favorable timeline.
In practice
A pan-European insurer preparing for its first DORA oversight cycle discovered, during its Article 28 register exercise, that three ostensibly independent policy administration systems all ultimately depended on the same regional identity and access management service from its primary cloud provider. On paper, the systems looked diversified — different teams, different codebases, different business lines. In practice, a single control-plane incident at the shared IAM layer would have taken down all three simultaneously. The fix wasn’t a wholesale multi-cloud migration, which the team judged too costly and operationally risky to execute quickly. Instead, they stood up an independent, provider-agnostic identity broker in front of the shared service for the three highest-criticality systems, giving them a tested failover path that didn’t depend on the primary provider’s own IAM staying healthy. The register exercise — originally treated as a compliance checkbox — is what surfaced a real architectural blind spot that a purely contractual vendor-risk review would have missed entirely.
Glossary
- Concentration risk
- The risk that reliance on a small number of shared providers or counterparties creates correlated exposure across otherwise independent institutions.
- Critical ICT Third-Party Provider (CTPP)
- Under DORA, a technology vendor formally designated by EU supervisory authorities as systemically important to the financial sector and subject to direct oversight.
- Critical Third Party (CTP)
- The UK equivalent designation, made by HM Treasury, subjecting a vendor to joint Bank of England, PRA, and FCA oversight.
- Systemic risk
- Risk of a disruption cascading across an entire sector or economy rather than remaining contained to a single institution.
- Substitutability
- How readily an organization could replace a given vendor or service with an alternative, at what cost, and in what timeframe.
- Exit strategy
- A documented, ideally tested plan for transitioning a critical function away from a specific ICT provider, required explicitly under DORA Article 28.
- Blast radius
- The scope of systems, data, or institutions affected when a single component, credential, or service fails or is compromised.
- Operational resilience
- An organization’s capacity to continue delivering critical functions through disruption, as distinct from simple disaster recovery or backup capability.
Key Takeaways
- Cloud concentration risk means a small number of hyperscalers now underpin enough shared infrastructure that one provider’s incident can cascade across otherwise unrelated institutions.
- DORA and the UK’s Critical Third Parties regime mark a shift from indirect to direct regulatory oversight of the cloud providers themselves, not just their financial-sector customers.
- 19 providers, including AWS, Google Cloud, and Microsoft, were formally designated as Critical ICT Third-Party Providers under DORA in November 2025.
- “Too big to fail” applied to cloud means resilience obligations and direct oversight, not government bailout — no hyperscaler is being nationalized.
- Multi-region deployment on a single provider does not solve concentration risk if the control plane or identity layer is shared across those regions.
- Exit strategies required under frameworks like DORA Article 28 only have value if tested against real data volumes, not left as an unexercised document.
- AI and data platform lock-in is an emerging, less-regulated layer of concentration risk that is moving faster than most current compliance frameworks account for.
FAQs
What exactly is cloud concentration risk?
It’s the systemic risk created when a small number of cloud providers host critical infrastructure for many otherwise-independent institutions simultaneously, meaning a single provider’s outage, breach, or failure can cascade across an entire sector rather than staying contained to one company.
Which cloud providers have been formally designated as systemically critical?
In November 2025, the European Supervisory Authorities designated 19 Critical ICT Third-Party Providers under DORA, including Amazon Web Services, Google Cloud, and Microsoft, alongside data center operators and telecommunications providers.
Does DORA apply outside the European Union?
DORA directly applies to EU-regulated financial entities and any ICT provider serving them, including non-EU cloud providers designated as critical. Its influence extends further because global institutions and providers often adopt DORA-aligned practices across all markets rather than maintaining separate regional standards.
How is the UK’s Critical Third Parties regime different from DORA?
The UK regime is run jointly by the Bank of England, PRA, and FCA, with HM Treasury making the final designation decision, whereas DORA’s oversight sits with the European Supervisory Authorities. Both share the same underlying goal: direct resilience oversight of systemically important technology vendors rather than indirect oversight through their financial-sector customers alone.
Can a bank or insurer simply avoid concentration risk by using multiple cloud providers?
Multi-cloud reduces but doesn’t eliminate concentration risk, and it introduces its own complexity and cost. True mitigation requires understanding which specific functions are critical, how substitutable each dependency actually is, and whether shared components (like identity services) undermine apparent diversification.
What does “too big to fail” mean when applied to a cloud provider, since governments won’t bail out AWS or Azure?
It refers to the systemic importance of the provider rather than an expectation of bailout. Regulators respond by directly overseeing the provider’s resilience, testing, and incident response, rather than waiting for a failure and then assigning blame to the financial institutions that depended on it.
Is AI service dependency treated as part of concentration risk yet?
Formal regulatory frameworks are still catching up. Most current designations focus on core infrastructure and ICT services, but a hyperscaler’s proprietary AI and data platform tooling is increasingly recognized informally as a comparable, and in some ways deeper, lock-in risk.
What should a mid-size financial institution do first if it hasn’t started addressing concentration risk?
Build a register of critical ICT third-party dependencies and honestly assess substitutability for each one — this single exercise, modeled on DORA’s Article 28 requirement, tends to surface the most urgent architectural and contractual gaps before any formal audit does.
References
- European Banking Authority — European Supervisory Authorities Designate Critical ICT Third-Party Providers Under DORA
- Financial Conduct Authority (UK) — Critical Third Parties: Strengthening UK Financial Services
- European Insurance and Occupational Pensions Authority — Digital Operational Resilience Act (DORA) Overview
- Financial Stability Board — Cloud Adoption in the Financial Sector and Concentration Risk
- U.S. Department of the Treasury — Financial Stability Oversight Council 2024 Annual Report
- European Securities and Markets Authority — Cloud Outsourcing and Financial Stability Risks
