DORA Year One: What 3,383 Major ICT Incidents Reveal

The European Supervisory Authorities have published the first annual report on major ICT-related incidents reported under DORA, and the EU financial sector now has its first hard numbers on what the regulation produces in practice: 3,383 major incidents in 2025, the first full year of application. The headline figure matters, but the detail matters more. Behind every one of those reports sits a chain of people who had to notice that something was wrong, classify it correctly, and escalate it fast enough to meet some of the tightest reporting deadlines in EU law.

When DORA took effect in January 2025, much of the attention went to governance, testing and training obligations, which we examined in our earlier look at DORA awareness obligations for financial entities. Eighteen months in, the supervisory data shows where the framework is being stress-tested first: incident detection, classification and reporting.

What the First DORA Incident Report Shows

On 3 June 2026, the EBA, EIOPA and ESMA jointly published the first annual report on DORA major ICT-related incidents. The key findings for 2025:

• 3,383 major incidents were reported by financial entities across the EU, roughly 0.18 incidents per entity.
• The majority came from the credit and payments sectors, where transaction volumes and customer-facing dependencies are highest.
• About one third of the incidents had cross-border impact, underlining why the EU pushed for a harmonized reporting framework rather than 27 national ones.
• System failures and external events were the main drivers, and the report places renewed emphasis on third-party risk management.

An average of 0.18 major incidents per entity may sound reassuringly low, but averages hide the concentration. Incidents cluster in the sectors that process the most transactions, and the figure only counts events that crossed the thresholds for a major classification. Beneath it sits a much larger volume of minor disruptions and near-misses that never reached a supervisor, but still consumed detection and triage capacity inside each firm.

The cross-border share is the finding supervisors will act on. When one in three major incidents spills across national boundaries, often because a shared provider or payment rail is involved, the case for consistent classification and fast escalation gets stronger, not weaker.

The Four-Hour Clock Starts With a Human Decision

The DORA reporting cascade is unforgiving. Once an incident is classified as major, the initial notification must reach the competent authority within 4 hours of classification, and no later than 24 hours from the moment the entity becomes aware of the incident. An intermediate report follows within 72 hours, and the final report within one month. Alongside the incident pipeline, the Register of Information covering ICT third-party arrangements is due annually by 30 April.

Every one of those deadlines depends on a step no regulation can automate: someone has to notice. Awareness, in the legal sense, often begins with a help-desk agent fielding an unusual pattern of complaints, a payment operations analyst spotting failed settlement batches, or a developer seeing anomalous authentication traffic. If front-line staff do not recognize the early signs of an ICT incident, or do not know exactly who to alert, the awareness clock starts running silently while the organization is still debating whether anything happened at all.

This is where security awareness training earns a permanent place in the resilience conversation. Staff who have practiced recognizing anomalies and escalating them, including through realistic phishing simulation exercises rather than an annual slideshow, shorten the gap between first signal and classification. Documented training completion also doubles as evidence when a supervisor asks how the entity ensures its people can identify and report ICT incidents, a question that first-year supervisory reviews have already put to firms.

A 4-hour notification deadline is not a technology problem. It is a recognition and escalation problem, and both of those live with people.

19 Critical ICT Providers Are Now Under Direct EU Oversight

The incident report is not the only milestone shaping year two. On 18 November 2025, the ESAs designated the first 19 critical ICT third-party providers (CTPPs) under Article 31(9) of DORA, bringing them under direct EU-level oversight through dedicated Lead Overseers. The first comprehensive examinations of these providers are expected during 2026.

For financial entities, designation of a provider does not transfer responsibility. Contract registers, exit strategies and concentration-risk assessments remain the obligation of each firm. What changes is the systemic picture: when an incident hits a widely used critical provider, dozens or hundreds of entities see their reporting clocks start simultaneously. The first annual report already flags external events and third-party dependencies as major drivers, so entities should assume that some of their most demanding reporting scenarios will originate outside their own perimeter, in services they consume but do not control.

Practical consequence: incident-response playbooks need a third-party trigger path. The team that manages a vendor relationship must know that a provider outage or breach notification can constitute awareness for DORA purposes, and must feed it into the same classification process as an internal alert.

Threat-Led Testing Every Three Years

The testing pillar hardened during the same period the report covers. The regulatory technical standards on threat-led penetration testing, adopted as Delegated Regulation (EU) 2025/1190 and published in the Official Journal on 18 June 2025, have applied since 8 July 2025. Financial entities designated for TLPT must run threat-led penetration tests at least every three years, built on scenarios that mirror real adversary behavior.

Threat-led testing routinely includes social engineering, because real attackers rely on it. Entities whose workforce has been conditioned by regular simulated attacks tend to perform measurably better in these exercises, and the trend data from those simulations gives testers and supervisors a baseline that a one-off exercise cannot provide. Firms preparing for their first TLPT cycle in 2026 and 2027 should treat the human attack surface as part of the scope from day one, not a footnote.

What This Means for Your Organization

The first year of DORA incident data turns abstract obligations into concrete expectations. Five actions follow directly from the findings:

• Rehearse the 4-hour path. Run tabletop exercises that start from a realistic first signal, a help-desk ticket or a vendor email, and time how long classification actually takes.
• Train recognition, not just policy. Front-line staff in payments, support and operations need to know what an ICT incident looks like from their seat, and exactly who to call.
• Wire third parties into detection. Vendor notifications must reach your classification team as fast as internal alerts, especially for services delivered by the newly designated CTPPs.
• Keep evidence as you go. Training records, simulation results and escalation logs answer supervisory questions that 2026 reviews are already asking.
• Plan the TLPT cycle now. The three-year clock is running, and social engineering resilience is part of what gets tested.

The 3,383 incidents of 2025 are the baseline, not the peak. Year two will show which entities treated the first report as a benchmark to improve against, and which treated it as someone else's statistics.