Cloud Concentration Risk: When Your AWS, Azure, or GCP Dependency Becomes a Regulatory Problem

On October 20, 2025, a DNS resolution failure in AWS US-EAST-1 went wide. Thousands of organizations that had outsourced DNS to AWS found themselves offline. Estimates placed the cost at $75 million per hour during the disruption. The same week, coordinated Azure DNS routing failures compounded the impact across firms running redundant infrastructure on both providers.

Less than a month later, on November 18, 2025, the European Supervisory Authorities responded: they published the first list of 19 Critical ICT Third-Party Providers under DORA — including Amazon Web Services, Microsoft, and Google Cloud. For the first time in any major jurisdiction, cloud hyperscalers are subject to direct financial services regulatory oversight.

If your firm’s strategy is “we’re all-in on AWS” (or Azure, or GCP) with no documented exit plan, you now have a documented regulatory gap.

TL;DR

• The October 2025 AWS and Azure outages demonstrated sector-wide cloud concentration risk in practice; DORA responded with the November 18, 2025 designation of 19 Critical ICT Third-Party Providers, including all three major hyperscalers.
• DORA Article 28 requires financial entities to assess ICT concentration risk; Article 30 requires specific contract provisions including 12-month exit notice, audit rights, and sub-outsourcing transparency.
• 5 of 19 designated CTPPs are generic cloud infrastructure providers; over 65% of EU financial institutions rely on at least two of the three major hyperscalers for critical functions.
• US regulators (OCC, Fed) flag cloud concentration as an examination priority; OCC’s Fall 2025 Semiannual Risk Perspective lists technology dependency among top risks.
• The solution isn’t necessarily multi-cloud — it’s documented concentration awareness, compliant contracts, and a tested exit strategy.

What the 2024–2025 Outages Actually Proved

The systemic nature of cloud concentration risk stopped being theoretical on July 19, 2024. A single faulty CrowdStrike Falcon Sensor update caused 8.5 million Windows systems to crash simultaneously. The top 500 US companies by revenue (excluding Microsoft) faced an estimated $5.4 billion in financial losses — with only $540 million to $1.08 billion insured. Banks delayed transactions. Hospitals reverted to paper records. Airlines grounded flights.

That wasn’t a cloud infrastructure failure — it was a third-party software vendor running at kernel level on cloud-hosted Windows instances. But it illustrated the mechanism: a single vendor with sufficient depth across a concentrated infrastructure stack can fail everything at once.

The October 2025 events were the infrastructure version of the same lesson. DNS resolution failure at a hyperscaler doesn’t affect one company — it affects every organization that outsourced DNS to that provider. The October 2025 AWS and Azure disruptions hit firms that thought they had redundancy because they used both providers. When both DNS layers failed in the same week, the apparent redundancy collapsed.

Regulators read the same post-mortems you did. The CTPP designations published 28 days after the October outages were not coincidental timing.

DORA’s 19 CTPPs: What the November 2025 Designation Means

The European Supervisory Authorities — EBA, ESMA, and EIOPA — used a prescriptive methodology to determine which providers made the CTPP list. The criteria:

Five of the 19 designated CTPPs are generic cloud infrastructure providers — the ESAs weren’t being subtle about where the concentration concern sits. The full list spans hyperscale cloud, data center operators, telecommunications providers, and specialist financial technology firms.

What Designation Changes

For designated providers, CTPP status means direct ESA oversight: the right to conduct investigations, issue binding recommendations, and — in extreme cases — recommend restrictions on services to EU financial entities. The first comprehensive examinations of CTPPs are scheduled for 2026.

For financial institutions using these providers, CTPP designation means:

• Enhanced documentation requirements for these vendor relationships
• Contract provisions must comply with Article 30’s specific requirements
• Your concentration risk assessment must identify these relationships and document your substitutability analysis
• Regulators will ask to see your contracts and your assessment

The designation doesn’t restrict which providers you can use. It raises the bar for how you document and manage those relationships.

DORA Article 30: What Your Cloud Contracts Need to Say

Most hyperscaler contracts signed before 2025 weren’t written to DORA’s standards. The standard AWS service agreement, for instance, gives AWS very short notice periods for service changes and doesn’t include the audit rights DORA requires. If you haven’t reviewed your cloud contracts since DORA became effective in January 2025, start there.

Article 30 requires ICT contracts with critical third parties to include all of the following:

Service Level Descriptions — Not generic uptime percentages. Quantitative performance indicators covering availability, response time, incident classification tiers, and escalation paths. “99.9% uptime” doesn’t tell you what happens during the 0.1%, which is when you need the contract to be specific.

Incident Notification Obligations — Defined timeframes for when the provider must notify you of material incidents, what constitutes a material incident, and what information the notification must contain.

Audit and Access Rights — Including the right to conduct on-site inspections at provider premises and to engage third-party auditors. This is often the hardest provision to negotiate with hyperscalers. The CTPP oversight framework gives the ESAs their own direct audit rights over designated providers — but your contract rights are separate and necessary for your own compliance.

12-Month Minimum Exit Notice — And obligations on the provider to support an orderly transition: data portability, migration assistance, and knowledge transfer. The 12-month requirement is a regulatory signal about what a realistic migration timeline looks like. If your exit strategy assumes a 90-day migration of a complex cloud environment, that assumption needs testing.

Sub-Outsourcing Transparency — A list of all sub-contractors with access to your systems or data, plus change notification requirements when sub-contractors change. This is the starting point for managing fourth-party risk in your cloud stack.

Business Continuity Obligations — What the provider commits to do during a disruption, including backup procedures and recovery timelines.

ICT Concentration Risk Assessment: What Article 28 Actually Requires

DORA Article 28 directly addresses concentration risk. Financial entities must identify and assess ICT concentration risk as part of their ICT third-party risk management framework.

The assessment has two levels:

Entity-Level Assessment: Your Firm’s Dependency Profile

1. Map cloud dependencies — Which business functions and critical processes run on which cloud providers? Include not just direct cloud usage but the cloud infrastructure underlying your SaaS vendors.

2. Score criticality — For each provider dependency, what’s the impact of a 4-hour outage? A 24-hour outage? A 1-week outage? Which processes can’t run at all without that provider?

3. Score substitutability — Could you migrate critical workloads within your recovery time objective (RTO) if the provider was unavailable? “Could you theoretically do it?” is not the same as “have you documented a realistic path and tested it?”

4. Document in your ICT risk register — Concentration risk findings belong in your formal risk documentation, not just in a slide deck from last year’s business continuity planning cycle.

Sector-Level Assessment: The Correlated Failure Problem

You don’t control sector-level concentration, but you need to understand it. Over 65% of EU financial institutions rely on at least two of the three major hyperscalers for critical functions. A simultaneous failure of AWS and Azure isn’t a tail scenario — it nearly happened in October 2025.

Your impact tolerance analysis should test correlated outage scenarios: What happens to our critical services if two hyperscalers experience disruptions simultaneously? If the answer is “we’re offline,” that’s the risk you need to document and mitigate.

For organizations that have already built DORA-compliant third-party ICT risk programs, concentration risk assessment plugs into the existing ICT risk register and impact tolerance framework. For organizations still building, this is foundational.

US Regulatory Expectations: OCC and Federal Reserve

US financial institutions aren’t directly subject to DORA, but the same concentration logic appears in US examination guidance — and examiners are asking for it.

OCC Bulletin 2023-17 (third-party risk management, issued June 2023) requires banks to assess concentration risk in third-party relationships, particularly those supporting critical activities. The OCC expects a current inventory of all outsourcing relationships available for examination, concentration risk analysis for critical vendor relationships, and documented contingency plans if a critical vendor is unavailable.

The OCC Semiannual Risk Perspective (Fall 2025) explicitly flags technology dependency and cloud infrastructure concentration as examination priorities for 2026. Examiners are asking to see vendor inventories with criticality ratings, concentration assessments, and tested exit plans — not just policies stating that exit plans exist.

The FCA published observations from firms’ self-assessments on operational resilience in March 2026, noting that many firms had documented impact tolerances for their important business services but had not tested whether they could actually operate within those tolerances during a hyperscaler disruption. The regulators’ concern isn’t theoretical — they reviewed the October 2025 post-mortems.

For community banks and credit unions: the scale of your cloud dependency is smaller, but the relative concentration can be higher. If your core banking platform, digital banking, and payment processing all run on a single cloud provider via a single SaaS core processor, you have the same structural problem as a large bank — at a different scale.

Multi-Cloud vs. Cloud Concentration Risk

The instinct when confronting cloud concentration risk is to go multi-cloud. That’s not automatically the right answer.

Where multi-cloud helps:

• Geographic distribution across independent failure domains
• Operational independence for different business functions
• Negotiating leverage and avoiding single-vendor lock-in

Where multi-cloud creates new problems:

• Operational complexity increases — more configurations to secure, more integrations to manage
• Security posture can degrade when split across multiple platforms
• Apparent diversity can mask underlying concentration in shared fourth-party infrastructure

The regulatory question isn’t “are you multi-cloud?” — it’s “have you assessed your concentration, documented it, and demonstrated you can recover?” A single-cloud firm with compliant contracts, a documented exit strategy, and evidence of exit testing can satisfy regulators. A multi-cloud firm that’s never tested failover between providers, and whose SaaS vendors all ultimately run on the same underlying hyperscaler infrastructure, cannot.

Vendor tiering methodology is the right starting point — identify your critical infrastructure vendors first, then apply the deeper concentration analysis to those relationships specifically.

So What? The Concentration Risk Assessment Checklist

The November 2025 CTPP designations mark the beginning of active regulatory oversight of cloud concentration, not its end. The ESAs’ first examinations of designated providers in 2026 will produce findings that shape examination expectations for financial institutions using those providers.

Getting your contracts, documentation, and exit strategy aligned now puts you ahead of those expectations. Waiting until an examiner asks about it during a third-party risk review puts you on the back foot explaining gaps in a risk category regulators have explicitly flagged.

Sources: EBA DORA CTPP Designation (November 18, 2025) · Morgan Lewis: DORA Critical ICT Provider List Analysis · AWS US-EAST-1 Outage: $75M/Hour Analysis · FCA Operational Resilience Observations (March 2026) · DORA Critical ICT Third-Party Provider Designations (2025-2026)