What DORA’s ICT Concentration Risk Requirements Mean for EU Financial Infrastructure

The Digital Operational Resilience Act has been in force since January 17, 2025. For most EU financial entities, the regulation’s technical standards were already demanding enough. But the third-party risk provisions, specifically the requirements around ICT concentration risk, are where infrastructure decisions start to look different. If your organization runs critical financial functions on AWS, Azure, or Google Cloud, those providers are now on a list of designated Critical ICT Third-Party Providers under direct EU supervisory oversight. That changes how you document risk, what your contracts need to contain, and whether your exit strategy is credible enough to show a regulator.

What Is DORA?

The Digital Operational Resilience Act (DORA), officially Regulation (EU) 2022/2554, establishes a uniform ICT risk management framework for financial entities operating in the European Union. It applies to banks, insurance companies, investment firms, payment institutions, crypto-asset service providers, and 20 other categories of financial entity. The act entered into force on January 17, 2025.

DORA’s core objective is straightforward: financial entities must be able to withstand, respond to, and recover from ICT disruptions, and they must be able to demonstrate that capability to supervisors. The regulation doesn’t just ask for policies. It asks for evidence that the controls work.

The Five Pillars, and Where Infrastructure Decisions Live

DORA organizes its requirements into five areas:

ICT risk management (Articles 5–15) requires board-level accountability for ICT risk, documented risk frameworks, protection and prevention measures, detection capabilities, and recovery and restoration processes. The ICT risk management framework is the governance layer, but it points directly at the infrastructure layer. You need to be able to classify what systems support critical functions, how they’re protected, and how they recover.

Incident reporting (Articles 17–23) requires classification and notification of major ICT incidents. For major incidents, the initial notification must reach the relevant competent authority within four hours of classification. That timeline is only achievable if detection and logging infrastructure is in place before an incident occurs.

Resilience testing (Articles 24–27) requires regular testing of ICT tools and systems. Significant entities must conduct Threat-Led Penetration Testing (TLPT) at least every three years. Testing has to run against live or near-live environments, which means the infrastructure layer needs to support that kind of access without compromising production.

Third-party risk management (Articles 28–30) governs how financial entities manage dependencies on external ICT providers. This is where infrastructure choices have the most direct regulatory impact.

Information sharing (Article 45) covers voluntary cyber threat intelligence exchange. It matters less for infrastructure architecture decisions than the other four pillars.

What Articles 28–30 Actually Require

Article 28 establishes the general principles for third-party ICT risk management. Financial entities are required to maintain a Register of Information that documents every ICT third-party arrangement, including provider details, contract scope, data locations, subcontractors, and criticality classification. The register gets submitted annually to the relevant national competent authority in a standardized xBRL-CSV format.

Criticality classification matters. If an ICT arrangement supports a critical or important function (defined under Article 3(22) as a function whose disruption would materially impair financial performance, soundness, or continuity of services) it triggers the deeper obligations in Article 30. Classification is based on operational impact and substitutability, not contract value.

Article 29 addresses ICT concentration risk directly. Financial entities must assess concentration risk before entering into new arrangements and document mitigation measures. Relying on a single provider for multiple critical functions is a risk that has to be assessed, documented, and reported to competent authorities. Exit strategies must be credible and tested, not just written down.

Article 30 specifies the minimum contractual content for arrangements supporting critical or important functions. The list includes: full service description and SLAs, data location and portability rights, access and audit rights for the financial entity, and cooperation obligations with supervisory authorities. These are regulatory requirements, not negotiating positions.

Why the Hyperscaler Concentration Problem Is Now a Regulatory Issue

In November 2025, the EBA, EIOPA, and ESMA published the first official list of 19 designated Critical ICT Third-Party Providers under DORA. AWS, Microsoft Azure, and Google Cloud are on it. So are Bloomberg, IBM, and Tata Consultancy Services, among others.

The designation matters for any financial entity using these providers for critical or important functions. Contracts with designated CTPPs are now subject to direct review by the Lead Overseer (the EBA for banking). The provider itself is required to cooperate with ESA oversight and may be examined by Joint Examination Teams. Financial entities may receive requests for confirmation data about how those relationships are structured.

The concentration risk picture at the sector level is what prompted the designation. Regulators have noted that AWS, Azure, and GCP together supply critical infrastructure for a large share of EU financial institutions. That concentration, with multiple systemically important institutions depending on the same three providers, is the kind of systemic risk DORA was designed to address.

For an individual institution, this doesn’t mean you have to move off public cloud. But it does mean:

• Every arrangement with a designated CTPP must be in your Register of Information with a completed criticality assessment
• Concentration risk across your CTPP arrangements must be assessed and documented before adding new ones
• Exit strategies must be written down and tested, not just theoretically possible
• Supervisors can now ask for your contracts and your concentration risk documentation

How Private Cloud Changes the Risk Calculus

OpenMetal is not a designated CTPP. Using OpenMetal infrastructure instead of a hyperscaler doesn’t eliminate third-party ICT risk. You still have a third-party provider and you still need to manage that relationship under Articles 28–30. But it changes the nature of the risk in ways that matter for DORA compliance.

Concentration risk reduction. Moving critical or important functions to a dedicated private cloud provider that is not a designated CTPP reduces concentration in the designated-provider tier. An organization that currently runs everything on AWS can’t easily argue it has low concentration risk. An organization that runs critical workloads on dedicated private infrastructure and uses public cloud for less sensitive functions can document a more defensible risk distribution.

Data residency documentation. Article 30 requires that contracts specify data locations. OpenMetal’s Amsterdam facility is a Tier III data center in the Netherlands. Data stored and processed there is EU-resident, which simplifies the data location documentation requirement. This matters especially for financial entities with GDPR obligations running alongside DORA, as the two frameworks overlap on data governance.

Audit rights and single-tenant architecture. Public cloud environments present audit challenges. In a shared, multi-tenant environment, “audit rights” in practice often means reviewing logs and reports generated by the provider rather than independently examining the infrastructure. Single-tenant bare metal and private cloud deployments allow more direct access to the infrastructure layer, including system logs, network traffic records, and hardware provenance, which strengthens the audit trail available during a DORA examination or incident investigation.

Exit strategy credibility. One area regulators are scrutinizing is whether documented exit strategies are actually executable. Proprietary managed services create real switching friction. Infrastructure built on open-source foundations (OpenStack and Ceph) is more portable. The skills and tooling required to migrate are more widely available, and the data is accessible in open formats. That doesn’t make migration trivial, but it makes the exit strategy more plausible on paper and in practice.

What OpenMetal’s Amsterdam Infrastructure Offers

OpenMetal operates a Tier III data center in Amsterdam, Netherlands. The Amsterdam facility runs bare metal dedicated servers and hosted private cloud deployments built on OpenStack and Ceph.

From a compliance posture standpoint, OpenMetal holds a Business Associate role under HIPAA, follows the ISO 27001:2022 framework, and is pursuing SOC 2. Those certifications are relevant to DORA’s ICT risk management requirements. A provider’s own security controls and governance framework are part of the due diligence a financial entity needs to document under Article 28.

For financial entities with confidential computing requirements, including encrypted key management, sensitive transaction processing, and regulated data handling, OpenMetal’s XL v4 and XL v5 servers support Intel TDX out of the box, providing hardware-level Trust Domain isolation for workloads that need it. This is relevant for firms managing validator key infrastructure, healthcare data under cross-sector obligations, or AI inference on sensitive financial datasets.

Engineer-to-engineer support includes dedicated Slack channels and assisted onboarding. For financial entities building out their ICT risk management documentation, having direct technical contact with the infrastructure provider simplifies the audit right and due diligence process that Article 28 requires.

What Private Cloud Does Not Solve on Its Own

Infrastructure decisions are one part of DORA compliance, not the whole of it.

Moving workloads to a private cloud provider doesn’t automatically produce the ICT risk management framework, incident classification procedures, resilience testing program, or Register of Information that DORA requires. Those are organizational and governance deliverables. Infrastructure can support them or complicate them, but it doesn’t replace them.

OpenMetal’s role is to supply infrastructure that is well-documented, ISO 27001 aligned, single-tenant, EU-resident, and built on open foundations that support legitimate audit access. What your organization does with that infrastructure, how you classify functions, build detection and logging, document third-party arrangements, and construct exit strategies, is a compliance program that requires legal and compliance expertise alongside the right infrastructure.

If your organization is working through DORA obligations, the infrastructure layer is worth reviewing alongside your compliance team, not instead of one.

Frequently Asked Questions

What is DORA and when did it take effect?

DORA is the EU Digital Operational Resilience Act (Regulation (EU) 2022/2554). It establishes a comprehensive ICT risk management framework for financial entities operating in the EU. It entered into force on January 17, 2025, and applies to banks, insurers, investment firms, payment institutions, crypto-asset service providers, and other financial entities operating within the EU.

Does DORA apply to non-EU organizations?

DORA applies to any organization providing ICT services to EU financial entities, regardless of where the ICT provider is headquartered. If you supply cloud infrastructure, data analytics, or other technology services to an EU-regulated financial institution, DORA’s third-party provisions affect your contractual obligations.

What is ICT concentration risk under DORA?

ICT concentration risk is the risk that a financial entity, or the financial sector as a whole, depends too heavily on a single ICT provider or a small group of providers for critical functions. Article 29 requires financial entities to assess this risk before entering new ICT arrangements and to document mitigation measures. The designation of AWS, Azure, and GCP as Critical ICT Third-Party Providers in November 2025 has made concentration risk documentation more urgent for institutions that rely on those providers for critical functions.

What are the contractual requirements for critical ICT arrangements under Article 30?

Article 30 requires that contracts supporting critical or important functions include: a full service description with SLAs, specification of data locations, data portability rights, audit and inspection rights for the financial entity and its supervisors, and cooperation obligations with competent authorities. These are mandatory provisions, not optional additions.

Does using a private cloud provider instead of a hyperscaler eliminate third-party ICT risk under DORA?

No. Any third-party ICT arrangement requires management under DORA’s Articles 28–30. What private cloud can do is reduce concentration risk in the designated-CTPP tier, improve data residency documentation, support more direct audit access in single-tenant environments, and produce more credible exit strategies when built on open-source foundations.

Is OpenMetal a Critical ICT Third-Party Provider under DORA?

OpenMetal is not on the November 2025 CTPP designation list. However, financial entities using OpenMetal infrastructure should still document that arrangement in their Register of Information and apply appropriate due diligence under Article 28. OpenMetal’s ISO 27001:2022 alignment and HIPAA Business Associate posture support the due diligence documentation process.