Why DORA Changes Infrastructure Decisions for Financial Institutions

The Digital Operational Resilience Act has been in force since January 17, 2025. In 2026, regulators moved from guidance to active enforcement, and an estimated 50% of financial institutions are still not fully compliant. (CybelAngel, 2026) Fines for non-compliance can reach up to 2% of global annual turnover or €10 million, whichever is higher. (CybelAngel, 2026)

This is not a one-off checkbox. DORA changes how banks, insurers, payment providers, and investment firms view their infrastructure, vendors, and their ability to demonstrate resilience in practice.

What DORA Is (and Is Not)

DORA (Regulation EU 2022/2554) is the first unified ICT risk management framework for the financial sector in the EU. It applies to approximately 22,000 financial entities across all 27 EU member states, as well as to third-party ICT service providers serving them, regardless of where those providers are headquartered. (YouSign, 2026)

Before DORA, financial institutions managed risk primarily by holding capital buffers. But that never adequately covered technology risk. A bank can be well-capitalized and still be taken offline by a cloud provider outage or a third-party software failure. DORA targets precisely that gap. (EIOPA)

It is also worth being clear about what DORA is not: it is not a directive that each country transposes into national law in its own way. It is a regulation - it applies directly and uniformly across all EU member states from January 2025. (EUR-Lex, Regulation EU 2022/2554)

The Five Pillars, and Why Infrastructure Is at the Center of All of Them

DORA structures its requirements around five areas: ICT risk management, incident reporting, resilience testing, third-party risk, and information sharing. Each of them has a direct impact on infrastructure.

ICT risk management requires board-level accountability for technology risks. Every system supporting a critical function of a bank or insurer must be documented, protected, and recoverable within a clearly defined timeframe in the event of an outage, with evidence available to regulators. (Regulation EU 2022/2554, Articles 5–15)

Incident reporting operates under strict timelines: a major incident must be reported to the regulator within four hours of being identified, followed by an intermediate report within 72 hours and a final report within one month. (IBM, 2026) This requires monitoring infrastructure capable of detecting, classifying, and escalating incidents quickly. A manual process simply cannot meet this at scale.

Resilience testing covers regular vulnerability assessments, penetration tests, and - for larger institutions - Threat-Led Penetration Testing (TLPT) conducted under the TIBER-EU framework, required at least every three years. (digital-operational-resilience-act.com, 2025) Filing away test results is not enough; remediation actions must be documented and tracked.

Third-party risk is where most institutions have the largest gaps. More on this below.

Information sharing on cyber threats is currently encouraged rather than mandatory, but regulators increasingly treat participation as a sign of maturity. (Regulation EU 2022/2554, Article 45)

The Third-Party Problem Is Structural

On November 18 2025, the European Supervisory Authorities (ESAs) published the first official list of 19 Critical ICT Third-Party Providers (CTPPs) under DORA. The full list includes: Accenture, Amazon Web Services EMEA, Bloomberg, Capgemini, Colt Technology Services, Deutsche Telekom, Equinix (EMEA), FIS, Google Cloud EMEA, IBM, InterXion HeadQuarters, Kyndryl, LSEG Data and Risk, Microsoft Ireland Operations, NTT DATA, Oracle Nederland, Orange, SAP, and Tata Consultancy Services. (FinTech Global, May 2026)

What does this mean in practice? Contracts with these providers are now subject to direct regulatory oversight. Financial institutions that rely on them for critical functions must document that dependency in the Register of Information and demonstrate that concentration risk has been properly assessed, not merely noted. (Regulation EU 2022/2554, Article 31; cyadviso.com, 2026)

The numbers speak for themselves: more than 65% of EU financial entities rely on at least two of the three major cloud providers for critical functions. (DORA Blog / Cryptaguard, April 2026) ECB analysis found that more than 30% of total outsourcing expenditure at significant European banks flows to just 10 providers, most headquartered outside the EU, and half of all critical outsourcing spend reaches only 30 providers. (OpenMetal, June 2026)

The first annual ESAs DORA incident report, published on June 3, 2026, documented 3,383 major ICT incidents across the EU financial sector in 2025. Nearly 29% of them originated from third-party failures. (Mitratech, June 2026) This is not a theoretical risk; it reflects how the sector is currently built.

Under Articles 28–30, institutions must:

• maintain a complete Register of Information covering all ICT vendors,
• assess concentration risk before entering into any new contract,
• ensure contracts include mandatory clauses: SLAs, audit rights for both the institution and regulators, security standards, business continuity obligations, and termination rights,
• have documented exit plans for every critical provider, tested at least annually. (cyadviso.com, 2026)

Contracts signed before January 17 2025 must be renegotiated. No grace period applies. (FluxForce AI, May 2026)

What This Means for Infrastructure in Practice

DORA does not prescribe a specific architecture. What it does is create conditions in which certain decisions become significantly harder to defend to a regulator.

Concentration on a single provider is now a documented liability. If an institution runs most of its critical systems on one cloud provider and that provider goes down, as AWS, Azure, and GCP each did at least once during 2025, the institution must be able to demonstrate a credible contingency plan. (Gresham Tech, January 2026) The AWS outage on October 20 2025, which caused a cascading failure in the US-EAST-1 region affecting Coinbase, Robinhood, PayPal, Lloyds Bank, and Halifax for over 15 hours, is precisely the scenario DORA's resilience testing framework is designed to stress-test. (Gresham Tech, January 2026)

Exit plans must be real, not just on paper. Article 28 requires documented exit strategies for all critical ICT providers. For CTPPs on the ESAs list, these plans must be tested at least annually. A plan without a tested migration path and a realistic timeline will not satisfy a regulator conducting an examination. (Regulation EU 2022/2554, Article 28(8); cyadviso.com, 2026)

Data sovereignty is becoming an infrastructure requirement. The European Commission's technology sovereignty package from June 2026 signals a long-term regulatory direction toward reducing the bloc's dependence on cloud infrastructure headquartered outside the EU. (Mitratech, June 2026) In practice, institutions running entirely on non-EU hyperscalers will find that dependency increasingly difficult to justify, not only to regulators, but to their own boards. Private cloud solutions with clear EU data residency, or hybrid architectures combining private and public cloud, are therefore becoming a relevant answer, not only as a regulatory hedge, but as a long-term strategic position.

At Touch4IT, we operate our own Touch4IT Private Cloud hosted in ISO-certified data centers in the EU. For clients who need full control over where their data physically resides - a directly relevant question under DORA compliance - it is an alternative that eliminates dependency on a single hyperscaler while meeting data residency requirements.

The Register of Information is only as useful as the data it contains. In the ESAs' 2024 dry-run exercise, only 6.5% of nearly 1,000 firms successfully passed all 116 data quality checks. (Orbiq, March 2026) DORA enforcement in 2026 is built around precisely this kind of visibility; institutions that cannot produce an accurate, current, supervisor-ready register have a foundational problem that no policy document will solve.

Compliance as an Infrastructure Strategy

There is a visible pattern: institutions that treat DORA as a burden focus on documentation. Institutions that treat it as an infrastructure problem focus on systems.

The difference shows in outcomes. A financial institution with well-classified systems, clean third-party contracts, tested exit plans, and monitored vendor dependencies is not just compliant; it is genuinely more resilient. When a cloud provider goes down at 2 AM, it responds differently from one that has nothing but a document in a drawer.

Where to Start

For institutions still working toward full compliance in 2026, the priority order is fairly clear.

First, complete the Register of Information to a standard that would hold up under regulatory review. Every criticality classification needs a documented rationale, and provider records must be current, not a snapshot from 2024.

Then audit third-party contracts against the mandatory clause checklist under Article 30. Any contract missing audit rights, exit provisions, or incident notification requirements is a current breach, not a future risk. (FluxForce AI, May 2026)

Next, honestly assess concentration risk. If two or three providers make up the majority of critical infrastructure, that fact needs to be formally acknowledged at board level, with a documented mitigation plan, even if it will take years to execute. If part of that plan involves diversifying toward private cloud infrastructure with EU data residency, that is an area where we have direct experience.

Finally, test what you have. Resilience testing under DORA is not a penetration test run once a year and filed away. It is an ongoing verification that systems behave the way the documentation says they do.

And Where We Can Help

At Touch4IT, we can assist with several of these steps, whether that means designing and operating infrastructure with clear EU data residency, including our T4 Private Cloud; assessing concentration risk and preparing exit plans; or setting up monitoring and CI/CD processes that enable continuous resilience testing.