analysis

Cloud Concentration Risk Under DORA: Why Your AWS Dependency Matters

DORA Atlas EditorialMarch 18, 202612 min read

The Oligopoly Problem

On July 18, 2024, a faulty update to a widely-used cybersecurity agent cascaded through global IT infrastructure, grounding flights, disabling payment terminals, and taking down banking services across multiple continents. The incident lasted hours. Recovery for some institutions took days. The root cause was not a cyberattack, not a natural disaster, and not a design flaw in cloud infrastructure — it was a single configuration change in a single third-party product deployed across thousands of organizations simultaneously.

This is the concentration risk that DORA's Pillar IV was designed to address. Not the theoretical risk that a cloud provider might fail, but the observable reality that the European financial sector's critical infrastructure increasingly depends on a small number of technology providers whose failure modes are correlated, whose market power makes substitution difficult, and whose sub-outsourcing chains create hidden dependencies that institutions cannot fully map.

The numbers tell the story. Industry analyses consistently show that three hyperscale cloud providers — Amazon Web Services, Microsoft Azure, and Google Cloud Platform — host the vast majority of European financial sector cloud workloads. When you add the major SaaS providers that themselves run on these platforms, the effective concentration deepens further. Your institution may contract with 30 different software vendors, but if 25 of them deploy on AWS, your actual cloud concentration is far higher than your vendor register suggests.

Article 29: The Concentration Risk Mandate

Art. 29 of DORA does not merely acknowledge concentration risk — it requires active management. Art. 29(1) requires that financial entities, "when performing the identification and assessment of the risks referred to in Article 28(1)(a)," shall "take into account whether the envisaged conclusion of a contractual arrangement in relation to ICT services supporting critical or important functions would lead to" several concentration scenarios.

Specifically, Art. 29(2) mandates consideration of:

(a) Contracting with a provider that is not easily substitutable. If a critical ICT service is provided by a vendor with no credible alternatives — due to market dominance, proprietary technology, data lock-in, or integration complexity — the institution must recognize and manage this non-substitutability risk.

(b) Multiple contractual arrangements with the same or closely linked provider. An institution using AWS for compute, S3 for storage, RDS for databases, and CloudWatch for monitoring has not diversified — it has concentrated within a single corporate ecosystem.

(c) An ICT third-party service provider on which other financial entities rely. Systemic concentration — where multiple financial entities depend on the same provider — creates correlated failure risk that transcends any single institution's risk assessment.

Art. 29 does not prescribe specific concentration limits or require mandatory diversification. It requires awareness, assessment, and documented management. But the supervisory expectation is clear: institutions that have not quantified their concentration exposure and developed mitigation strategies will face pointed questions.

Measuring Concentration: Beyond Vendor Counts

Counting vendors is not measuring concentration. An institution with 40 ICT service providers might appear diversified but could have extreme concentration if its five most critical services all depend on a single cloud platform.

The HHI Approach

The Herfindahl-Hirschman Index (HHI), originally developed for measuring market concentration in antitrust economics, is increasingly referenced by supervisors. See our step-by-step HHI calculator guide for practical worked examples as a methodology for ICT concentration assessment. The HHI is calculated by summing the squares of each provider's share of your total ICT service portfolio.

For practical application, weight the calculation by criticality. A provider hosting 15% of your services but supporting 60% of your critical functions represents far greater concentration risk than raw service counts suggest. A criticality-weighted HHI that accounts for the business impact of each service dependency provides a more accurate picture of actual concentration exposure.

Single-Point-of-Failure Analysis

Beyond aggregate concentration, identify specific single points of failure:

Sole-source critical services: Any critical or important function (Art. 3(22)) supported by a single provider with no identified alternative. If your core banking platform runs exclusively on one cloud provider's managed database service, losing that service means losing core banking.

Correlated sub-outsourcing: Your direct providers may be diverse, but their infrastructure may not be. If your payment processor, your anti-fraud system, and your customer authentication service all run on the same cloud platform, a platform-level incident affects all three simultaneously.

Technology monoculture: Concentration extends beyond providers to technology. If every application in your estate uses the same database engine, the same container orchestration platform, or the same message queue, a vulnerability in that technology component affects your entire infrastructure.

Geographic concentration: Services concentrated in a single availability zone, region, or jurisdiction create exposure to localized failures (power grid, network backbone, regulatory intervention). Art. 30(2)(c) requires contractual specification of data processing and storage locations precisely because geographic concentration is a risk factor.

Provider Group Analysis

Cloud providers are corporate groups. AWS is Amazon. Azure is Microsoft. GCP is Alphabet. An institution using AWS for infrastructure, Ring for physical security, and Alexa for Business for meeting rooms has concentrated within a single corporate group — even though it appears in the vendor register as three separate providers. Art. 29(2)(b) explicitly references "closely linked" providers, requiring institutions to look beyond legal entity names to corporate group structures.

The Sub-Outsourcing Chain Problem

Art. 30(2)(a) requires contractual provisions on subcontracting — specifically, that the ICT third-party service provider must obtain the financial entity's specific or general approval before sub-outsourcing, and must notify the entity of any material changes to sub-outsourcing arrangements.

This provision exists because sub-outsourcing creates hidden concentration. Your SaaS provider may run on AWS. Your other SaaS provider may also run on AWS. Your managed security provider may use a threat intelligence feed that runs on AWS. None of these AWS dependencies appear in your direct vendor register — but they create a sub-outsourcing concentration that surfaces only when AWS experiences a regional outage.

Mapping sub-outsourcing chains is operationally difficult but supervisorily expected. Art. 28(3) register entries should include sub-outsourcing information for critical arrangements. Where providers resist transparency about their infrastructure dependencies, that resistance itself is a risk factor that should inform the concentration assessment.

Exit Strategies: The Credibility Test

Art. 28(8) requires financial entities to put in place "exit strategies" for ICT services supporting critical or important functions. An exit strategy must ensure that the entity can terminate an arrangement "without disruption to its business activities, without limiting compliance with regulatory requirements, and without detriment to the continuity and quality of services provided to clients."

For cloud services, credible exit strategies require:

Data portability. Can your data be extracted from the provider's platform in a usable format within your required recovery timeline? Cloud-native data formats, proprietary database engines, and platform-specific APIs create portability barriers that must be assessed and addressed before they become urgent.

Application portability. Applications built on cloud-native services (serverless functions, managed AI/ML, platform-specific container orchestration) may require substantial re-engineering to run on an alternative platform. The more deeply you integrate with a provider's proprietary services, the less credible your exit strategy becomes.

Transition timeline. How long would migration take? For a critical banking application with petabytes of data, complex integrations, and regulatory validation requirements, migration may take months — far longer than the recovery timeline implied by business continuity requirements.

Alternative providers. Have alternatives been identified, assessed, and at minimum pre-qualified? An exit strategy that says "migrate to Azure" without any validation that your applications actually run on Azure is not an exit strategy — it is an aspiration.

Testing. Has the exit strategy been validated? Even tabletop exercises that walk through migration steps, identify dependencies, and estimate timelines provide more assurance than untested documentation. Art. 28(8) does not explicitly require testing, but supervisors will assess credibility — and untested strategies are not credible.

Multi-Cloud vs. Multi-Region: What Actually Reduces Concentration

The instinctive response to cloud concentration is "go multi-cloud." But multi-cloud is not a silver bullet, and the operational complexity it introduces can create new risks.

Multi-Cloud: Genuine Diversification

True multi-cloud — running critical workloads on two or more independent cloud platforms simultaneously — genuinely reduces provider concentration. If your core banking platform can operate on both AWS and Azure, with data replication and automated failover, an AWS outage does not take down core banking.

But genuine multi-cloud is expensive and operationally complex. It requires:

Application architecture that avoids provider-specific services (or maintains provider-specific implementations for each platform)
Data synchronization across platforms
Operational teams skilled in multiple cloud ecosystems
Testing that validates cross-platform failover

For most financial institutions, genuine multi-cloud is feasible for a subset of critical services — not the entire estate. Prioritize based on criticality: which services, if unavailable, would breach impact tolerance thresholds?

Multi-Region: Resilience Within Concentration

Multi-region deployment — distributing workloads across multiple geographic regions within a single cloud provider — reduces geographic concentration and protects against regional failures (data center incidents, power grid disruptions, network backbone issues). It does not reduce provider concentration.

Multi-region is a necessary but insufficient response to DORA's concentration risk requirements. It addresses availability within a provider but not the Art. 29 concern about dependency on a non-substitutable provider.

The Pragmatic Approach

For most institutions, the pragmatic approach combines:

Multi-region deployment for resilience within the primary cloud provider
Genuine multi-cloud capability for the most critical services (core banking, payment processing, customer authentication)
Documented and tested exit strategies for all critical services
Ongoing monitoring of provider concentration using quantitative metrics (HHI, single-point-of-failure counts)
Contractual protections that ensure data portability and transition assistance (Art. 30(2)(f))

The Lead Overseer Regime: Articles 31-44

DORA introduces a novel regulatory mechanism for the most systemically important ICT third-party service providers: the Lead Overseer. Art. 31 empowers the ESAs to designate "critical ICT third-party service providers" based on their systemic importance to the financial sector.

Designation criteria (Art. 31(2)) include:

The number and nature of financial entities relying on the provider
The criticality of functions supported
The provider's degree of substitutability
The systemic impact of a large-scale failure

Designated critical ICT TPPs are subject to direct oversight by a Lead Overseer (one of the three ESAs), which can conduct inspections, issue recommendations, and — critically — impose a last-resort penalty of up to 1% of the provider's average daily worldwide turnover per day of non-compliance (Art. 35(8)).

For financial institutions, the Lead Overseer regime provides a supervisory backstop for concentration risk that individual institutions cannot address alone. But it does not eliminate the institution's own obligations under Art. 29. Even if your cloud provider is designated as a critical ICT TPP and subject to Lead Overseer supervision, you must still maintain your own concentration risk assessment, exit strategies, and substitutability analysis.

The Failure Scenario: What Happens When a Critical Provider Goes Down

Consider a scenario where a major cloud provider experiences a multi-region outage lasting 72 hours. For a bank with significant cloud concentration:

Hour 0-4: Detection and initial assessment. Which critical functions are affected? How many customers are impacted? Classification against Art. 18 criteria — this is almost certainly a major ICT incident requiring initial notification to the NCA within four hours.

Hour 4-24: Containment and communication. Activate business continuity plans. Assess whether backup systems (if they exist on a different platform) can assume critical workloads. Notify customers of service disruptions (Art. 23(2) for payment services). Brief the management body (Art. 14(2)).

Hour 24-72: Recovery and intermediate reporting. Submit intermediate incident report with quantified impact. Execute exit strategy — if one exists and has been tested. If no credible exit strategy exists, the institution is dependent on the provider's recovery timeline.

Post-72 hours: Root cause analysis and framework reassessment. Art. 13 requires lessons learned. Art. 29 concentration risk assessment must be updated. The management body must determine whether current concentration levels remain within risk tolerance.

The institutions that survive this scenario with minimal customer impact are those that invested in genuine diversification before the incident occurred. The institutions that suffer the most are those that assessed concentration risk as "low" because they had multiple vendors — without examining whether those vendors shared a common infrastructure dependency.

Platforms like Valendir that integrate third-party risk management with concentration analytics, exit strategy tracking, and incident reporting provide the continuous visibility needed to manage cloud concentration as a living risk — not an annual compliance exercise.

The Path Forward

DORA does not require financial institutions to abandon cloud computing. Cloud provides genuine operational benefits — scalability, cost efficiency, geographic flexibility — that support operational resilience when properly governed. What DORA requires is that institutions understand, measure, manage, and report the concentration risks that cloud adoption creates.

The path forward is not multi-cloud for its own sake, but informed, deliberate architecture decisions:

Quantify your current concentration. Calculate criticality-weighted HHI across your ICT service portfolio. Identify single points of failure. Map sub-outsourcing chains for critical providers.

Assess substitutability. For each critical provider, evaluate: How quickly could you migrate? What alternatives exist? What would migration cost? What would migration risk?

Build credible exit strategies. Not aspirational documents — actionable plans with identified alternatives, tested migration procedures, and realistic timelines.

Design for portable architecture. New application development should minimize provider lock-in. Use infrastructure-as-code, container-based deployment, and standard APIs where feasible.

Monitor continuously. Concentration is not static. Every new service adoption, every vendor consolidation, every sub-outsourcing change alters your concentration profile. Build continuous monitoring into your third-party risk governance.

Report to the board. Concentration risk is a board-level topic under Art. 5 and Art. 14. The management body should understand the institution's cloud dependency landscape and the credibility of its exit strategies.

The cloud concentration problem is not going away. If anything, the accelerating adoption of cloud-native services, AI platforms, and managed infrastructure will deepen provider dependencies across the financial sector. Institutions that build the governance, measurement, and architectural capabilities to manage this concentration now will be better positioned — both regulatorily and operationally — than those that wait for a failure to reveal what they should have measured.

This analysis reflects DORA Regulation (EU) 2022/2554 and associated ESA oversight framework as applicable in Q1 2026. Specific Lead Overseer designations and oversight arrangements are subject to ongoing ESA determinations.