DORA's incident reporting regime has always been largely cause-neutral on paper. The Regulation defines an ICT-related incident by its effect: an unplanned event that compromises network and information systems and has an adverse impact on the availability, authenticity, integrity or confidentiality of data, or on the services a financial entity provides.  A "major" incident is one with a high adverse impact on the systems that support a firm's critical or important functions. The detailed test, in Delegated Regulation (EU) 2024/1772, first asks whether critical services were affected. If they were, the incident is considered major when it crosses two or more materiality thresholds of other criteria: impacted clients, counterparts and transactions, reputational impact, duration and service downtime, geographic spread, data losses, and economic impact. Only one threshold is specific to attacks: successful, malicious, and unauthorised access that may lead to data loss makes an incident major on its own. 

On 3 June 2026, the European Supervisory Authorities (the EBA, EIOPA and ESMA) published data showing what that design captures in practice. Their first annual report under Article 22(2) of DORA, 2025 Report on major ICT-related incidents (JC 2026 16), covers the major ICT-related incidents reported across the EU financial sector in 2025, the first full year of DORA reporting. 

Financial entities reported 3,383 major incidents in 2025, an average of 282 a month. More than 60% occurred in the credit sector and a further 16% in payments. The ESAs are explicit that the count is not a risk indicator on its own: the concentration reflects market structure, the fact that banks and payment firms have reported major incidents under PSD2 since 2018, and the highly digital, customer-facing nature of their services. 

The analysis covers only incidents with a final report submitted by a 5 February 2026 cutoff, so roughly 15% of incidents notified during the year were excluded. And several reporting fields allow more than one selection per incident, so percentages describe how often a factor appeared rather than a clean split of causes. 

By type of incident, system failures were reported for 51% of major incidents, external events for 27% and payment-related incidents for 18%. Cybersecurity-related incidents accounted for 10%. The root-cause data tells the same story: half of major incidents were caused by a system failure or malfunction, 32% by external events, 19% by process failures and 12% by human error. The ESAs' own explanation for the prevalence of system failures is that the complexity of digital infrastructure exposes financial entities to more software issues. 

The supervisors read the low share of cyber-related incidents as a sign that security safeguards are working, pointing to the EBA's Autumn 2025 Risk Assessment, in which the share of banks reporting a successful cyberattack that led to a major incident fell from 35% to 28%. The practical consequence for firms is that the bulk of DORA's major-incident reporting workload is generated by operational failures, not by attackers. 

The report attributes 29% of major incidents to failure on the side of a third party, a category that includes ICT providers, other financial entities and infrastructure providers. The ESAs state that dependencies on third-party providers, including those not designated as critical, are an area of supervisory attention, and that firms need to strengthen their third-party risk management frameworks. 

They also describe how shared providers multiply incidents. In the credit sector, many smaller entities within the same group rely on the same large providers for core banking, payment processing and connectivity, so a single failure can generate dozens of related major incidents. Around a third of all major incidents (1,056) had a cross-border impact, and in about 8% of major incidents more than ten countries were affected. The ESAs note that more than two-thirds of these widely spread incidents were linked to system or process failures. 

Most incidents were contained. Two-thirds caused no or only minor disruption to clients and transactions, and fewer than 18% affected other financial counterparties. The ESAs credit timely detection and effective response rather than the incidents being small. 

The remediation pattern was consistent across sectors: rapid technical fixes to restore service, followed by longer-term measures such as better monitoring and alerting, improvements to testing and change-management procedures, configuration changes and correction of affected data, with coordination with external providers where a third party was the cause. In their conclusions, the ESAs say the prevalence of system and process failures highlights the importance of robust ICT governance, change management, testing and resilience arrangements. 

Reported costs were low, and the ESAs treat that with caution. Almost 40% of incidents reported no direct or indirect costs, around 10% reported less than €1,000, and a further 15% left the field blank. The report points out that under EBA Q&A 2025_7439, staff time clearly allocated to handling an incident should count as a cost, so these results may reflect incorrect reporting rather than genuinely cost-free incidents. 

The June report said the ESAs would offer competent authorities further guidance on major incident reporting, focus on incidents left open, and link incident data to the DORA Register of Information (the record firms must keep of all their contracts for ICT services from third-party providers) to better identify incidents originating at critical ICT third-party providers. Two publications in September show the direction of travel. 

16 September 2026: DORA Incident Reporting - Operational Instructions. The ESAs published fourteen points on how the major-incident templates should be completed, aimed at better data quality and more consistency across jurisdictions. They are issued by ESA staff on a best-efforts basis, agreed with competent authorities, and are not a legal interpretation; they address how existing fields are filled in rather than changing deadlines or thresholds. Several of them address problems the June report had identified: 

• Open incidents. After the initial notification and first intermediate report, supervisors expect at least one intermediate report a month until the final report is submitted. 

• Double counting. Incident identifiers must stay unchanged from initial notification to final report. 

• Classification. "Critical services affected" should always be listed among the criteria that made an incident major. 

• Cost. The economic-impact field now points reporting firms to the same staff-cost Q&A the June report cited. 

• Third-party origin. Where an incident originates from a third-party provider or another financial entity, Field 2.8 should be reported in a standard format: the provider's full legal name, its LEI or EUID, the type of code, and any other relevant information. 

That last point matters most for third-party risk. Consistently naming the provider behind each incident, with a legal entity identifier, produces the structured data needed to link incident reports to the Register of Information. 

23 September 2026: Autumn 2026 Joint Committee risk update (JC 2026 29). Drawing on DORA incident data for 2026 up to May, the ESAs report that system failures still account for most ICT incidents. In an EBA survey on dependencies on non-EU/EEA providers, around 80% of banks identified ICT service provider dependencies as their biggest challenge. Among the policy recommendations: continue monitoring dependencies on "critical and other technology service providers," and strengthen software quality and cybersecurity practices. The same update is clear that cyber and data security remain the most significant drivers of operational risk overall, and it flags the threat from frontier AI models. The supervisors are not downgrading cyber; they are recording that the major-incident workload is mostly operational. 

None of this changes what DORA requires. It does give firms a clearer, regulator-published picture of where their reporting burden comes from. Third-party oversight should be proportionate to third parties' actual share of major incidents, not limited to the providers formally designated as critical. Change management, testing and configuration control belong in the same frame as security controls, because they sit behind most of the incidents firms are reporting. Since supervisors now expect final reports to identify the originating provider by legal name and identifier, firms need to be able to trace an incident's root cause to a specific vendor, and ideally a specific defect, quickly and consistently. 

BugZero focuses on the category this data keeps pointing to: operational defects in third-party vendor software. These are non-security bugs that are not CVEs and do not appear in the National Vulnerability Database, but can still take down production systems. BugZero's Operational Defect Database centralises multi-vendor defect data, maps each applicable defect to the devices, systems and applications in a firm's environment, and assigns a Bug Risk Score, all delivered inside ServiceNow through a certified app. The aim is to let IT teams act on known vendor defects before they become reportable incidents and, when an incident does occur, to give risk and compliance teams an evidence base for root-cause and remediation discussions with supervisors and auditors. 

• Joint Committee of the ESAs, 2025 Report on major ICT-related incidents (JC 2026 16), 3 June 2026 

• ESAs, DORA Incident Reporting - Operational Instructions, 16 September 2026 

• Joint Committee of the ESAs, Update on Risks and Vulnerabilities in the EU Financial System - Autumn 2026 (JC 2026 29), 23 September 2026 

• Regulation (EU) 2022/2554 (DORA) 

• Commission Delegated Regulation (EU) 2024/1772