ICT concentration risk under DORA refers to the regulatory and operational danger that materialises when a large share of the EU financial sector depends on the same handful of hyperscale cloud providers. Under DORA Regulation (EU) 2022/2554, which became applicable on 17 January 2025, that dependency is no longer a commercial preference to be managed internally: it is a named prudential risk category subject to binding assessment, contractual requirements and cross-border supervisory oversight.
Why hyperscaler concentration is now a systemic regulatory problem
Financial regulators have long worried about single points of failure in market infrastructure. DORA extends that concern explicitly to cloud and software supply chains.
The scale of the problem is concrete. The European Systemic Risk Board (ESRB) documented in its 2022 report on systemic cyber risk that three hyperscalers, AWS, Microsoft Azure and Google Cloud, collectively hold an estimated 65 to 70 percent of European financial sector cloud workloads. A prolonged outage or security incident at any one of them would propagate across banks, insurers, asset managers and market infrastructure operators simultaneously, producing sector-wide disruption that no individual institution could prevent by acting alone.
DORA responds to this by treating concentration at the sector level, not just the entity level. DORA Article 28 requires every financial entity to assess its ICT third-party risk management framework specifically for concentration risk, to document that assessment and to demonstrate to supervisors that material dependencies have been identified and that substitutability has been evaluated. The obligation is prospective: institutions must show not only where they are concentrated today but how they would respond if a critical provider became unavailable.
The Register of Information: making dependency visible to supervisors
The DORA Register of Information is the mechanism that converts individual concentration risk into sector-wide supervisory intelligence.
Each financial entity must maintain and submit a structured Register of Information listing every ICT third-party service provider, the nature and criticality of services provided, data classification, and the geographic location of data processing and storage. The register is not an internal document: it must be reported to the relevant national competent authority, and EBA, EIOPA and ESMA are empowered to aggregate these registers across the EU to identify concentration patterns that no single national supervisor could detect.
The practical consequence for institutions that have relied heavily on a single hyperscaler is that this dependency is now explicitly visible to their supervisors in a structured, comparable format. Institutions that have not yet mapped which workloads sit on which provider, or which have allowed de facto consolidation onto one vendor over time, face both a compliance gap and a reputational risk in supervisory dialogue.
DORA applies to more than 22,000 financial entities and ICT third-party service providers across the EU, according to the European Commission’s own impact assessment from 2022. The Register of Information is the data infrastructure that makes DORA’s oversight framework operationally real at that scale.
Critical Third-Party Provider designation: criteria and consequences
DORA creates a formal designation mechanism for the highest-risk providers: the Critical Third-Party Provider (CTPP) status, governed in detail by Commission Delegated Regulation (EU) 2024/1502.
The designation criteria set out in that Delegated Regulation include: the number of financial entities that use the provider for critical or important functions; the systemic importance of those clients (a provider serving five globally significant banks is weighted differently from one serving five small payment institutions); the cross-border footprint of the provider’s operations within the EU; the degree of substitutability (can the service realistically be sourced elsewhere within an operationally relevant timeframe); and the degree of interconnection with other critical infrastructure.
Designation as a CTPP does not fall on the financial entity: it falls on the provider itself. The Joint Oversight Network, composed of EBA, EIOPA and ESMA, gains direct supervisory powers over designated CTPPs. This includes the right to conduct inspections, request information, issue recommendations and, in extreme cases, require a CTPP to remediate identified risks. As the EBA has stated in its regulatory guidance: “The concentration of critical services in a small number of third-party providers creates a single point of failure for the entire financial system. This is precisely the systemic risk DORA is designed to address.”
For financial entities, the relevance of CTPP designation is indirect but significant. A provider that receives a recommendation from the oversight network and fails to comply generates a compliance signal that every entity relying on that provider must factor into its own risk assessment. Dependence on a CTPP that is under active supervisory scrutiny becomes a board-level risk, not a procurement matter.
Contractual provisions: what DORA requires and where hyperscalers resist
DORA Article 30 sets out a mandatory minimum list of provisions that ICT third-party contracts must contain when the services support critical or important functions. Several of these provisions create structural friction with US-controlled hyperscalers.
| DORA contractual requirement | Sovereign European provider | US-controlled hyperscaler |
|---|---|---|
| Full audit and inspection rights for the financial entity and competent authorities | Typically contractually available; on-site inspection feasible | Hyperscalers routinely offer shared audit reports (SOC 2, ISO 27001) but resist bespoke on-site access |
| Data localisation and processing geography guarantees | Contractually and technically enforceable under Swiss FADP or EU GDPR | US CLOUD Act can override contractual data location commitments via US government order |
| Exit and termination rights with defined transition support | Feasible; open-source stacks reduce lock-in | Proprietary APIs, data formats and licensing structures impede realistic exit timelines |
| Service level agreements with measurable resilience targets | Negotiable at entity level | Standard SLAs are non-negotiable for most financial entities below tier-one status |
| Subcontracting transparency and control | Contractually enforceable in smaller supply chains | Hyperscaler subcontracting chains can span dozens of entities across multiple jurisdictions |
ESMA has been direct on this point in its Joint Regulatory Technical Standards consultation: “Financial entities must ensure that ICT third-party service providers meet appropriate standards of security and resilience, and that contracts include provisions allowing for effective supervision and exit strategies.” The audit rights requirement is the provision most frequently reported as difficult to enforce with large US providers, because hyperscalers’ multi-tenant architecture makes entity-specific physical inspection impractical.
Using sovereign infrastructure to reduce concentration risk scores
DORA’s substitutability assessment is not a theoretical exercise: it asks whether a financial entity could realistically transfer critical functions away from a provider within a defined timeframe if that provider became unavailable or unsafe to use. Sovereign, multi-provider infrastructure is the most direct structural answer to that question.
A hybrid sovereign architecture, in which critical and regulated workloads sit on European-hosted infrastructure using open-source platforms (such as a Nextcloud-based document environment, open-source database layers and European colocation), while commodity workloads remain on hyperscalers, can demonstrably reduce the concentration score for the regulated portfolio without requiring a full migration. The key regulatory test is not whether a hyperscaler is used at all, but whether any single provider is irreplaceable for critical or important functions.
Diversification across two or more European-controlled providers, each operating under distinct legal jurisdictions and infrastructure footprints, satisfies the substitutability test more convincingly than any contractual arrangement with a single dominant provider. The IBM Cost of a Data Breach Report 2023 placed the average total cost of a data breach in financial services at USD 5.97 million, a figure that does not include regulatory fines or supervisory remediation costs. Concentration in a single provider amplifies the financial exposure of any single incident, because the same event that causes operational disruption may simultaneously trigger GDPR breach notification under Article 33, NIS-2 incident reporting under Article 23 of Directive (EU) 2022/2555 and DORA major ICT incident reporting under Article 19.
When a critical incident involves a US-jurisdictioned provider: the regulatory overlap
The intersection of DORA, GDPR and NIS-2 becomes operationally complex when a major ICT incident occurs at a US-headquartered cloud provider. Each framework imposes its own notification timeline: DORA requires an initial notification to the competent authority within four hours of classifying an incident as major; GDPR Article 33 requires notification to the supervisory authority within 72 hours of becoming aware of a personal data breach; NIS-2 requires an early warning within 24 hours and a full notification within 72 hours.
These timelines can run concurrently, but the information available to the financial entity may be severely limited if the incident originates inside the provider’s infrastructure rather than the entity’s own systems. US-controlled providers are not required by EU law to share forensic detail with EU supervisors, and any US government involvement in the incident (for example, a classified data access request that triggered a security failure) may be subject to non-disclosure obligations under US law. The financial entity is then in the position of being legally required to report to three separate regulatory frameworks with incomplete information about an incident it did not cause and cannot independently investigate.
Sovereign infrastructure does not eliminate incident risk, but it eliminates the jurisdictional opacity. An incident at a European-hosted, European-operated provider is fully subject to EU legal process, audit rights are real and enforceable, and there is no competing legal framework that restricts information sharing with EU authorities.
Frequently Asked Questions
What is DORA ICT concentration risk and why does it matter for cloud procurement?
ICT concentration risk under DORA refers to the systemic danger that arises when a large number of financial entities depend on the same small group of cloud or software providers. If one of those providers fails or is compromised, the disruption propagates across the entire sector. DORA Article 28 requires financial entities to actively identify, monitor and mitigate this risk, making cloud procurement a regulatory decision, not just a commercial one.
Which cloud providers are most likely to be designated as Critical Third-Party Providers under DORA?
Commission Delegated Regulation (EU) 2024/1502 sets the designation criteria, which include the number of financial entities served, systemic importance of those clients, substitutability, cross-border footprint and interdependencies. AWS, Microsoft Azure and Google Cloud are the most likely candidates given their dominant market share across EU financial services, though formal designation is made by the Joint Oversight Network of EBA, EIOPA and ESMA.
What contractual provisions does DORA require that hyperscalers may resist?
DORA Article 30 requires that ICT third-party contracts include full audit rights for the financial entity and its competent authority, data localisation provisions, exit and termination rights with realistic transition periods, and service level agreements with measurable resilience targets. US-controlled hyperscalers routinely resist on-site audit rights and may not be able to contractually guarantee that EU data remains outside US jurisdiction, given the CLOUD Act’s extraterritorial reach.
How does the DORA Register of Information work and who has access to it?
Under DORA, each financial entity must maintain a Register of Information documenting all ICT third-party service providers, the services they supply, data classification, criticality and geographic location of data processing. This register must be submitted to the relevant national competent authority, and EBA, EIOPA and ESMA can aggregate these registers across the EU to identify systemic dependencies.
Can a financial institution realistically exit a hyperscaler to reduce concentration risk?
Exit is operationally difficult but structurally achievable in stages. DORA’s substitutability assessment pushes institutions to document and periodically test exit scenarios. Sovereign alternatives, such as European-hosted infrastructure running open-source platforms, can absorb specific workloads, reducing the concentration score even without a full migration. A hybrid sovereign architecture, where critical and regulated data sits on sovereign infrastructure while commodity workloads remain on hyperscalers, is the approach most consistent with DORA’s proportionality principle.