DORA Is Live: What the EU Operational Resilience Act Means for Financial Tech

On January 17, 2025, the European Union’s Digital Operational Resilience Act — DORA — entered full enforcement. After two years of transition, the regulation is no longer a planning exercise. For banks, insurers, investment firms, crypto-asset service providers, and the technology vendors that serve them, DORA is now the operating baseline for doing business in the EU financial sector.

The regulation represents a fundamental shift in how regulators treat technology risk in finance. Where previous frameworks treated ICT (Information and Communications Technology) risk as a subcategory of operational risk, DORA elevates it to a standalone discipline with its own audit trails, testing requirements, and third-party accountability chains. The premise is straightforward: modern financial services run on software, and software failures can trigger systemic crises. DORA is the EU’s answer to that reality.

What DORA Actually Covers

DORA (Regulation EU 2022/2554) applies to a sweeping range of financial entities — over 22,000 organizations across EU member states. The scope includes:

• Credit institutions (banks, savings institutions)
• Payment and e-money institutions
• Investment firms and trading venues
• Insurance and reinsurance undertakings
• Crypto-asset service providers (CASPs) registered under MiCA
• Central counterparties, credit rating agencies, and data reporting services

Crucially, DORA also applies to ICT third-party service providers — meaning cloud platforms, data analytics vendors, core banking software providers, and any critical technology supplier to the above entities. This is what makes DORA structurally different from prior financial regulation: the technology vendor is no longer just a contractor. Under DORA, they are a regulated entity with their own obligations.

The Five Pillars of DORA Compliance

1. ICT Risk Management

Financial entities must maintain a comprehensive ICT risk management framework — not a one-time document, but a living system. This means continuous asset identification, threat classification, risk scoring, and documented controls. Boards and senior management are explicitly accountable: DORA requires governance structures that place ICT risk oversight at the executive level, not siloed in IT departments.

2. Incident Reporting

DORA introduces a harmonized, time-bound incident reporting regime. Major ICT-related incidents must be reported to the relevant national competent authority within strict deadlines: an initial notification within 4 hours of classification, an intermediate report within 72 hours, and a final root-cause report within one month. The definition of what constitutes a “major incident” is precise — thresholds cover the number of affected clients, geographic spread, transaction value disruption, and reputational damage scope.

3. Digital Operational Resilience Testing

This is where DORA raises the bar most visibly. All in-scope entities must conduct regular resilience testing, including vulnerability assessments and scenario-based tests. For significant financial institutions, DORA mandates Threat-Led Penetration Testing (TLPT) — advanced red team exercises conducted at least every three years. TLPT must be performed by certified testers and cover production systems, not just test environments. Results feed directly into the risk management framework and are disclosed to supervisors.

4. Third-Party ICT Risk Management

Every financial entity must maintain a complete, up-to-date register of all ICT third-party contracts and perform due diligence on critical providers. Contracts with critical ICT vendors must include specific clauses: exit strategies, audit rights, performance benchmarks, and — critically — the right for the financial entity’s regulator to conduct audits of the vendor. Subcontracting chains must be mapped and monitored. Concentration risk — over-reliance on a single provider — must be actively managed.

5. Information Sharing

DORA explicitly encourages — and in some cases requires — financial entities to share threat intelligence and vulnerability information with peers and regulators through designated cyber threat information-sharing arrangements. This is a deliberate policy choice: the EU views financial sector cybersecurity as a collective defense problem, not a competitive advantage.

Who Is Really Affected — Including Non-EU Companies

The territorial reach of DORA extends well beyond EU borders. Any ICT company providing services to EU financial institutions is within scope if those services are deemed critical. This has direct implications for global technology giants.

AWS, Microsoft Azure, and Google Cloud have all been placed under scrutiny as potential Critical ICT Third-Party Providers (CITPPs). The European Supervisory Authorities (EBA, ESMA, EIOPA) are empowered to designate specific providers as CITPPs, which triggers a direct oversight framework: the designated authority can request information, conduct investigations, and impose fines — regardless of where the provider is headquartered.

In practical terms, this means a cloud provider headquartered in Seattle or Dublin must demonstrate DORA-compliant resilience capabilities to European regulators if a meaningful share of EU financial institutions depend on their infrastructure. The extraterritorial reach is intentional — it closes the accountability gap that existed when EU banks outsourced critical functions to vendors outside the EU regulatory perimeter.

Where Compliance Stands in Early 2026

Enforcement began January 17, 2025, but the compliance landscape in early 2026 remains uneven. Industry surveys from late 2024 found that fewer than half of EU financial institutions considered themselves substantially compliant with DORA at the enforcement deadline. The most challenging areas:

• TLPT implementation — finding certified testers, scoping production system tests, and managing the legal complexity of probing live banking infrastructure
• Third-party contract renegotiation — many legacy vendor contracts lack the audit rights and exit provisions DORA now requires; renegotiation takes time and leverage
• ICT asset inventories — many mid-tier banks discovered their asset registers were incomplete or outdated when attempting to build DORA-compliant risk maps
• Concentration risk analysis — the degree to which financial sectors in individual EU countries rely on a handful of cloud providers created uncomfortable findings in several national assessments

Regulators have signaled proportionality — smaller institutions face lighter obligations under DORA’s explicit simplified ICT risk management framework for entities below defined thresholds. But proportionality does not mean exemption. All in-scope entities must at minimum implement the baseline requirements.

What DORA Means for Cloud and Tech Vendors

For technology vendors, DORA changes the commercial relationship with financial clients in lasting ways. Customers will now demand contract clauses that were previously negotiating points — audit rights, SLA specificity, incident notification timelines, and subcontractor disclosure. Vendors who resist these terms risk losing EU financial sector business to more compliance-ready competitors.

The CITPP designation process is the highest-stakes element for large vendors. A designation triggers direct regulatory oversight and can impose operational requirements — such as maintaining dedicated EU infrastructure or data residency guarantees — that conflict with a provider’s global architecture. Several large cloud providers have invested in EU-sovereign cloud regions partly in anticipation of these requirements.

For fintech startups building infrastructure products or B2B SaaS sold into EU banking, DORA compliance is increasingly a sales prerequisite rather than a differentiator. Enterprise procurement teams at banks now include DORA questionnaires in vendor onboarding flows.

Practical Compliance Steps for 2026

For organizations still working toward full compliance, the priority sequence is:

1. Complete the ICT asset inventory — you cannot manage what you cannot see. Map all systems, data flows, and third-party dependencies before anything else.
2. Classify and register third-party contracts — build the register DORA requires, flag which providers are critical, and identify contract gaps.
3. Establish incident classification protocols — define in advance what constitutes a major incident under DORA’s thresholds. The 4-hour notification clock cannot be stopped by internal debate about classification.
4. Schedule and resource TLPT — for significant institutions, this requires budget, certified external testers, and board sign-off. Lead times for qualified TLPT providers extend 6 to 9 months.
5. Engage legal on contract renegotiation — prioritize the largest and most critical vendors. Exit strategy clauses are non-negotiable under DORA.
6. Report to the board — ICT risk governance must be visibly at executive level. Board minutes should document DORA briefings and decisions.

DORA is not a one-time compliance exercise. It is an ongoing operational discipline that regulators will audit, test, and enforce. Organizations that treat it as a checkbox will find the 2026 supervisory cycle more uncomfortable than the initial enforcement deadline.

Sources & Further Reading

• Regulation (EU) 2022/2554 — Digital Operational Resilience Act — EUR-Lex
• DORA Overview and Implementation — European Banking Authority (EBA)
• DORA Interactive Single Rulebook — ESMA
• Critical ICT Third-Party Providers Under DORA — S&P Global Market Intelligence
• DORA Compliance Readiness: What Financial Institutions Must Do — Deloitte