3,383 Incidents Later: What DORA's First ICT Data Reveals About Your Operational Risk Program

TL;DR

• The ESAs reported 3,383 major ICT incidents in 2025 under DORA — 282 per month on average, with one-third having cross-border impact and 8% affecting more than 10 countries
• Nearly one-third of incidents originated from third-party failures, making vendor and infrastructure dependency the leading external risk driver in financial services
• Only 10% of incidents were cyber-related — system failures (51%) and external events (27%) dominated, which inverts how most firms allocate operational risk focus
• 2026 is DORA’s enforcement maturity phase: Register of Information accuracy is the primary enforcement trigger, and inaccurate ROI submissions are generating formal supervisory letters

The European Supervisory Authorities published their first annual DORA ICT incident report on June 3, 2026. It covers 3,383 major incidents reported by EU financial entities during 2025.

That’s not just an EU regulatory milestone. If you run operational risk at a financial institution — whether you’re subject to DORA or not — this is the first large-scale empirical data set on what actually causes major ICT incidents in financial services. And what it shows challenges assumptions that are baked into how most firms allocate risk management resources.

Here’s what the data says and what it should change in your program.

The Numbers at a Glance

3,383 major ICT incidents. Across all EU financial sectors — banks, insurers, investment firms, payment institutions — in 2025. That averages out to 282 per month, or roughly nine or ten per day across the full DORA reporting universe.

This is the first time regulators have had access to standardized, structured incident data from this breadth of financial sector participants. The methodologies are still evolving, but the scale makes it the most significant empirical operational risk data set in regulatory history for financial services.

One-third had cross-border impact. About 33% of major incidents extended beyond the country in which they were initially reported. In roughly 8% of cases, more than 10 countries were affected by a single incident. Financial market infrastructure is interconnected enough that local failures routinely become cross-border events — a finding that should inform how firms think about concentration risk in shared infrastructure dependencies.

Two-thirds caused minimal disruption. About two-thirds of major incidents resulted in no or minor disruption to clients and transactions. The ESAs credited timely detection and effective incident response measures. This is actually the most encouraging finding in the report: when organizations have functioning incident management programs, the majority of major incidents don’t translate into major client impact.

The discipline is identifying what failed in the one-third that did cause significant disruption.

The Finding That Should Change Your Risk Priorities

The most operationally significant finding in the DORA report isn’t the headline count. It’s the cause breakdown.

What’s causing major ICT incidents in EU financial services:

That cybersecurity number is the one that challenges how most financial institutions allocate operational risk resources. Cyber threats dominate risk conversations, consume disproportionate control investment, and drive most operational risk frameworks — but they account for roughly one in ten major incidents in the DORA data.

System failures are five times more common.

This doesn’t mean cyber risk doesn’t matter. A single significant cyberattack can cause far more damage than dozens of system failures, and the severity distributions are fundamentally different. But if your operational resilience program is overwhelmingly cyber-focused while your system failure and change management controls are thin, the data is telling you where your program is misallocated.

This finding validates what the software supply chain BCP testing framework identified: CrowdStrike-type failures — change management problems that cascade through vendor dependencies — belong in every financial institution’s scenario library alongside cyberattacks. DORA’s first year of incident data confirms this at scale. The dominant operational risk failure mode is not the attacker. It’s the update.

The Third-Party Finding: Your Vendor Program Is on the Hook

Almost one-third of major DORA incidents originated from failures attributable to third parties — ICT providers, other financial entities, and infrastructure providers.

That framing is important. It’s not just one category of vendor. It’s cloud providers, software-as-a-service platforms, data center operators, market infrastructure, and other financial entities in the same transaction chain. The ESAs’ takeaway is explicit: the results “highlight the need for robust third-party risk management, effective oversight of outsourced services and close coordination with service providers during incident response and remediation.”

What “close coordination” requires in practice is not what most TPRM programs actually provide:

Contract rights that function in an incident. Most vendor contracts include SLA language and incident notification provisions, but many don’t hold up under stress testing. If a critical vendor goes down at 2am, do your agreements give you the right to incident notifications within specified timeframes? Do you have a contractual path to join the vendor’s incident command channel? Do you have explicit rights to a post-incident report with root cause analysis? Our DORA Article 28 third-party risk framework covers the contractual minimums in detail.

Escalation contacts that are actually current. Third-party incident escalation contacts are among the fastest things that go stale in a TPRM program. The named technical contact at your cloud provider changes. The security operations team contact at your core processor gets reorganized. Quarterly confirmation that vendor escalation contacts are still accurate is basic operational hygiene that most programs skip.

Runbooks for vendor failure scenarios. Does your incident response playbook include explicit steps for a major cloud provider outage, a critical SaaS vendor going dark, or a market data feed that doesn’t come back up? Most IR playbooks are written around internal failures and cyberattacks — not vendor failures where the institution can’t remediate directly and must manage business continuity while waiting on the vendor.

Real-time monitoring metrics. The third-party incident KRI framework covers vendor availability metrics, mean time to notify, and SLA deviation as leading indicators that a vendor relationship is drifting toward incident risk. Tracking these metrics in a dashboard — rather than finding out about availability issues through client complaints — is the difference between a managed incident and a regulatory notification.

The DORA incident data is telling supervisors — and practitioners — that nearly one-third of the risk sits in vendor relationships. If your TPRM program is primarily focused on onboarding diligence and annual risk assessments but light on operational monitoring and incident coordination, you’re managing that one-third with tools that weren’t designed for it.

What This Means for US Institutions

DORA applies directly to EU-licensed financial entities. If your institution is US-focused with no EU operations, you’re not directly subject to the regulation. But you’re not off the hook from the implications.

Three reasons the DORA incident data matters for US-only firms:

1. US regulatory frameworks are converging on the same requirements. FFIEC examination expectations on third-party operational resilience closely track DORA’s framework. The multi-regulator notification sequencing requirements under FFIEC, CIRCIA, and OCC guidance impose similar documentation and escalation timeframes to DORA’s Article 19 incident notification. The underlying supervisory logic is the same even when the regulatory text differs.

2. US technology vendors serving EU financial clients. US companies that provide ICT services to EU financial entities may face contractual DORA requirements as “ICT third-party service providers” regardless of where they’re located. If your firm provides cloud services, data analytics, software platforms, or managed IT services to an EU bank or insurer, your EU client’s DORA obligations flow through your contract. You may already be a DORA counterparty without realizing it.

3. The incident taxonomy is universal. System failures, change management gaps, third-party dependencies — these aren’t EU-specific failure modes. The DORA report is the first large-scale, structured empirical record of what actually causes major ICT failures in financial services. US institutions should treat it as the best available industry benchmark even in the absence of a US-specific equivalent. The OCC, FDIC, and Federal Reserve don’t yet publish equivalent aggregated incident data. DORA gives you the closest thing to it.

The 2026 Enforcement Context

The ESA incident report was published in the same quarter that DORA enforcement entered what legal experts describe as a “maturity phase.”

In 2025, supervisory activity under DORA was primarily dialogue — reviewing documentation, raising questions about compliance gaps, providing informal guidance on interpretation. In 2026, that approach shifted toward formal compliance assessments, cross-checking of Register of Information submissions, and in some cases remediation orders where gaps are material.

The Register of Information is the enforcement chokepoint. The ROI is a structured, standardized inventory of all ICT third-party arrangements that financial entities submit to national supervisors annually. Inaccurate or incomplete ROI submissions are the most common reason firms are receiving supervisory letters in the current cycle.

The cross-border incident data in the DORA report creates a specific enforcement angle: supervisors can now point to empirical evidence that 8% of major incidents affected more than 10 countries, and ask whether firms have comprehensive visibility into the ICT third-party arrangements that created that exposure. An ROI that misses major cloud dependencies or managed services relationships is directly contradicted by the incident data.

If your EU subsidiaries submitted an ROI that doesn’t accurately reflect the full scope of ICT third-party arrangements — especially cloud providers, data center operators, and managed service providers — the next submission cycle is the time to fix it before supervisors find the gap themselves.

Building Your Response

For firms directly subject to DORA:

• Cross-reference your Register of Information against the actual third-party relationships surfaced in your last major incident or near-miss. ROI gaps frequently surface in post-incident reviews when teams realize a vendor that caused disruption wasn’t in the inventory.
• Test third-party incident escalation procedures for your top-5 critical vendors: run a tabletop where the vendor goes dark with no advance notice and verify that escalation contacts, runbooks, and contractual notification rights work as expected.
• Review your incident classification procedures against DORA criteria. Organizations frequently discover in their first year of reporting that they were under-classifying incidents — which creates both regulatory exposure and gaps in their own incident data.

For US firms applying the lessons:

• Add a system failure or change management failure scenario to your BCM testing calendar. The DORA data shows system failures at 51% — the dominant incident cause — but most BCP testing focuses on disaster scenarios rather than internal failures. The software supply chain BCP scenarios are a good starting framework.
• Assess the intensity of your third-party operational monitoring against the empirical finding that nearly 30% of major incidents originate with vendors. Onboarding diligence doesn’t tell you whether a vendor is drifting toward an incident. Continuous monitoring does.
• Verify that post-incident documentation for vendor-caused failures is as rigorous as it is for internal or cyber incidents. Incident reports for vendor failures are often thinner, which creates gaps when regulators ask for root-cause analysis.

For cyber incidents specifically, the cyber incident documentation requirements for insurance claims and regulatory notification overlap substantially with what the DORA incident reporting framework requires. Firms investing in thorough incident documentation processes get value across both frameworks.

So What?

The DORA incident report is the first time practitioners have access to structured, large-scale empirical data on what actually causes major ICT incidents in financial services. The headline findings — system failures dominate, cyber is a smaller piece than assumed, third-party failures drive nearly a third of incidents — should inform how you build and prioritize your operational risk program.

Firms that respond to this data by strengthening system failure and change management controls alongside their cyber programs, and by upgrading their vendor incident coordination from reactive to proactive, are building resilience against the actual distribution of risk — not the assumed distribution.

The distribution has been measured. Your job now is to build your program against it.

If your TPRM program needs a structural upgrade — vendor risk tiers, contract provisions, operational monitoring KRIs, and incident coordination playbooks for vendor failure scenarios — the Third-Party Risk Management Kit ($69) covers all of it in a format ready for practitioner use.

Sources:

• ESAs publish the first report on DORA major ICT-related incidents | ESMA
• Lessons From the European Supervisory Authorities’ First DORA Major Incident Report | Ropes & Gray
• EU Report on Major ICT Incidents Under DORA: Emerging Risks and Practical Implications | DLA Piper
• ESAs publish first annual report on major ICT-related incidents under DORA | Ganado Advocates
• DORA major ICT-related incidents report logs 3,383 disruptions | Cryptonomist