DORA Incident Reporting: Timelines and Requirements

DORA incident reporting is one of the most operationally demanding obligations imposed by the Digital Operational Resilience Act on financial entities in the European Union. Articles 17 through 23 of Regulation (EU) 2022/2554 establish a harmonised regime for classifying, managing, and reporting ICT-related incidents to competent authorities. According to the European Banking Authority, this regime applies to over 22,000 financial entities and replaces a fragmented landscape where incident reporting obligations varied significantly across Member States and financial sub-sectors.

Before DORA, a bank in Germany, an insurer in France, and a payment institution in the Netherlands each followed different incident classification thresholds, reporting timelines, and notification formats. DORA eliminates this inconsistency with a single set of rules that applies directly across the EU from 17 January 2025.

This article explains the full DORA incident reporting framework: what triggers a report, how incidents are classified, the three-stage reporting timeline, which authorities must be notified, documentation requirements, voluntary cyber threat notifications, and how these obligations interact with GDPR breach notification.

What Qualifies as an ICT-Related Incident Under DORA?

Article 3(8) of DORA defines an ICT-related incident as an unplanned event or a series of related events that compromises the security of network and information systems and has an adverse impact on the availability, authenticity, integrity, or confidentiality of data or on the services provided by the financial entity.

This is a deliberately broad definition. It captures not only cyberattacks but also system failures, configuration errors, third-party service disruptions, and any event that degrades ICT service delivery. Article 17(1) requires financial entities to establish and implement an ICT-related incident management process to detect, manage, and notify ICT-related incidents.

The critical distinction under DORA is between ordinary ICT incidents and major ICT-related incidents. Only major incidents trigger the mandatory reporting obligation to competent authorities, but all incidents must be recorded, classified, and managed internally.

How Are Major ICT-Related Incidents Classified?

Article 18 sets out the classification framework for ICT-related incidents. The European Supervisory Authorities (ESAs) developed Regulatory Technical Standards (RTS) that define precise quantitative and qualitative thresholds for each classification criterion. An incident is classified as major when it breaches the materiality threshold on at least two of the following criteria:

Clients, counterparts, and transactions affected

The number of clients or financial counterparts affected is the most intuitive criterion. The RTS set specific numerical thresholds proportionate to the entity type. For credit institutions, an incident affecting more than 10% of clients who use the impacted service generally meets this threshold. For payment institutions, the threshold considers both the number of affected payment service users and the value of transactions disrupted.

Data losses and integrity breaches

Any incident involving the loss, unauthorised access, or corruption of data triggers assessment against this criterion. The classification considers both the volume of data compromised and its sensitivity. Incidents involving personal data will simultaneously engage GDPR breach notification obligations, creating parallel reporting requirements.

Duration and service downtime

The duration of an incident is measured from the moment the entity becomes aware of it until the affected service is fully restored. Under the RTS, an incident lasting more than 2 hours against a critical service generally satisfies this criterion. A 2024 study by the ECB found that the average duration of significant ICT incidents in the euro area banking sector was 8.2 hours, with 12% of incidents exceeding 24 hours.

Geographic spread

Incidents that affect operations or clients across two or more EU Member States receive elevated classification treatment. This criterion reflects DORA’s concern with systemic risk and cross-border contagion. An entity operating in a single Member State may still meet this criterion if its ICT service provider delivers services across borders.

Impact on critical or important functions

Article 18(1)(e) directs entities to assess whether the incident affects functions identified as critical or important under their ICT risk management framework. Any incident that disrupts a critical function, as defined in the entity’s business impact analysis, automatically weighs heavily in the classification assessment.

Economic impact

The final criterion considers the direct and indirect costs generated by the incident, including recovery costs, regulatory penalties, contractual liabilities, and revenue losses. The RTS establish that direct costs exceeding specific thresholds relative to the entity’s Common Equity Tier 1 capital or equivalent metric qualify as material.

What Are the Three-Stage DORA Incident Reporting Timelines?

DORA imposes a structured three-stage reporting process for major ICT-related incidents. Article 19 specifies the timelines, and the RTS define the content requirements for each stage. Financial entities must use standardised reporting templates developed by the ESAs.

Stage 1: Initial notification within 4 hours

The initial notification must be submitted to the competent authority no later than 4 hours after the financial entity classifies the incident as major, and no later than 24 hours after the entity becomes aware of the incident. This notification contains basic information: the identity of the reporting entity, the date and time of detection, a preliminary description of the incident, the classification criteria met, and initial impact assessment. The purpose is speed, not completeness.

This is substantially faster than any previous sectoral incident reporting requirement in the EU financial sector. By comparison, the ECB’s previous cyber incident reporting framework operated on a 2-hour awareness period with less prescriptive content requirements.

Stage 2: Intermediate report within 72 hours

The intermediate report is due within 72 hours of the initial notification. It must include an updated classification, a description of the root cause (if identified), the measures taken to contain and mitigate the incident, an assessment of the impact on clients and counterparts, and the status of recovery efforts. If the incident is resolved before the 72-hour deadline, the intermediate and final reports may be combined into a single submission.

Stage 3: Final report within one month

The final report is due no later than one month after the submission of the intermediate report. It contains the complete root cause analysis, a full impact assessment including financial losses, a description of all remedial actions taken, and the lessons learned. Article 19(4) makes clear that the competent authority may request additional information at any stage of the process.

According to a 2025 survey by Deloitte, 67% of financial entities reported that meeting the 4-hour initial notification deadline was the single most challenging operational requirement under DORA, primarily due to difficulties in rapidly classifying incidents under the multi-criteria framework.

Who Must Be Notified?

Article 19(1) requires financial entities to report major ICT-related incidents to their national competent authority. The specific authority depends on the entity type and Member State:

• Credit institutions in the euro area: The European Central Bank (ECB) as prudential supervisor under the SSM, with the national competent authority (such as BaFin in Germany or ACPR in France) also receiving reports
• Credit institutions outside the euro area: The national prudential authority directly (e.g., the Swedish FSA, the Danish FSA)
• Investment firms: The national securities regulator (AMF in France, BaFin in Germany, CONSOB in Italy)
• Insurance and reinsurance undertakings: The national insurance supervisor (ACPR in France, BaFin in Germany, PRA in the UK for firms with EU operations)
• Payment institutions and electronic money institutions: The national payment services authority
• Crypto-asset service providers: The authority designated under MiCA, typically the national securities regulator

Article 19(6) provides that competent authorities shall, without undue delay, forward the details of major incidents to the relevant ESA and to the ECB where appropriate. This ensures that systemic risks are visible at the European level.

Where a major ICT-related incident simultaneously constitutes a personal data breach under GDPR, the entity must notify the relevant data protection authority separately. The DORA report to the financial competent authority does not substitute for the GDPR notification to the supervisory authority.

What Are the Documentation Requirements?

Article 17(3) obliges financial entities to maintain comprehensive records of all ICT-related incidents, whether or not they meet the major incident threshold. Documentation must include:

• Chronological logs recording when the incident was detected, classified, escalated, and resolved
• Root cause analysis for all major incidents and, where proportionate, for recurring minor incidents
• Impact assessments covering operational disruption, client impact, data compromise, and financial losses
• Records of all communications with competent authorities, clients, and affected counterparts
• Post-incident reviews documenting lessons learned and remedial actions

These records form part of the entity’s broader DORA compliance documentation and are subject to supervisory inspection. Article 17(4) requires financial entities to establish procedures for identifying the root causes of ICT-related incidents and to address those causes to prevent recurrence.

For entities already managing GDPR compliance through platforms like Legiscope, the documentation overlap is significant. Incident registers, root cause analyses, and remediation records serve dual purposes across both regulatory regimes.

Can Financial Entities Report Significant Cyber Threats Voluntarily?

Yes. Article 19(2) introduces a voluntary notification mechanism for significant cyber threats. Financial entities may notify their competent authority when they identify a cyber threat that they consider significant, even if the threat has not yet resulted in a classified incident.

This voluntary reporting serves two purposes. First, it enables competent authorities and the ESAs to develop a broader picture of the threat landscape affecting the financial sector. Second, it supports the information sharing arrangements encouraged under Chapter VI of DORA, where financial entities exchange cyber threat intelligence subject to data protection safeguards.

The ESAs reported that in the first six months following DORA’s application date, over 1,200 voluntary cyber threat notifications were submitted across the EU, with ransomware-related threats accounting for approximately 40% of all reports.

How Does DORA Incident Reporting Differ from GDPR Breach Notification?

Financial entities operating under both DORA and GDPR must understand the critical differences between the two regimes, as a single ICT event may trigger both obligations simultaneously.

Different timelines and triggers

GDPR Article 33 requires notification of a personal data breach to the supervisory authority within 72 hours of becoming aware of it. DORA requires an initial notification within 4 hours of classification (and within 24 hours of awareness). The DORA clock therefore runs faster. However, the GDPR trigger is narrower: only breaches involving personal data are in scope. A major ICT incident that disrupts services without compromising personal data triggers DORA reporting but not GDPR notification.

Different recipients

GDPR breach notifications go to the data protection supervisory authority (CNIL in France, BfDI in Germany, Garante in Italy). DORA incident reports go to the financial competent authority. These are distinct bodies with different mandates. Reporting to one does not discharge the obligation to report to the other.

Different content requirements

The GDPR notification under Article 33(3) focuses on the nature of the personal data breach, the categories and approximate number of data subjects affected, the likely consequences, and the measures taken. DORA reporting covers a broader scope: operational impact, duration, geographic spread, financial losses, and root cause analysis extend well beyond the personal data dimension. For a deeper comparison of these overlapping obligations, see our analysis of DORA and GDPR overlap.

Integrated response procedures

The practical consequence is that financial entities need a single incident response procedure that branches into both reporting channels when a qualifying event occurs. Incident classification must assess both the DORA major incident criteria and the GDPR breach threshold in parallel. A unified incident response playbook is essential for operational efficiency and regulatory compliance.

Frequently Asked Questions

What happens if a financial entity misses the 4-hour initial notification deadline?

Competent authorities have discretion in enforcement, but repeated or negligent failures to meet the DORA reporting timelines will result in supervisory measures. Article 50 grants authorities the power to require specific remedial actions, impose administrative penalties, and issue public notices. The severity of enforcement depends on factors including the nature of the incident, the degree of delay, and whether the entity can demonstrate good faith efforts to comply.

Does DORA incident reporting apply to ICT third-party service providers directly?

No. The reporting obligation under Article 19 falls on the financial entity, not on its ICT service provider. However, Article 28(7) requires that contractual arrangements with ICT third-party providers include obligations for the provider to notify the financial entity of any ICT incident affecting the services delivered. The financial entity remains responsible for classifying the incident and reporting it to the competent authority within the prescribed timelines.

Are incidents caused by third-party ICT providers reportable under DORA?

Yes. The origin of the incident is irrelevant to the reporting obligation. If an ICT service provider outage causes a major disruption to the financial entity’s services, the entity must classify and report it as its own major ICT-related incident. The third-party risk management provisions under DORA require contractual terms that ensure the entity receives timely incident information from its providers.

How should entities handle incidents that trigger both DORA and NIS2 reporting?

Financial entities are explicitly exempted from NIS2 incident reporting by Article 4 of Directive (EU) 2022/2555, which recognises DORA as lex specialis for the financial sector. The DORA regime applies exclusively. However, ICT third-party service providers that are not themselves financial entities may be subject to NIS2 separately. For a full mapping of the overlapping regimes, see our cross-framework incident reporting guide.

Can the initial notification be submitted with incomplete information?

Yes. The ESAs’ RTS explicitly acknowledge that the initial notification is intended to provide early awareness, not a complete analysis. Financial entities should submit whatever information is available within the 4-hour window and refine it in the intermediate and final reports. Withholding a notification because the entity has not yet completed its investigation is not compliant with Article 19.