Skip to content
Legiscope
Menu
Financial Regulation

DORA Incident Reporting: Timelines and Requirements

A detailed guide to DORA incident reporting under Articles 17-23, covering classification criteria, three-stage reporting timelines, competent authorities, and how it differs from GDPR breach notification.

DORA incident reporting requires financial entities to distinguish ordinary ICT incidents from major incidents and to notify the correct authority on time. Regulation (EU) 2022/2554, the classification rules in Delegated Regulation 2024/1772, and the reporting rules in Delegated Regulation 2025/301 must be read together. An incident log needs separate timestamps for occurrence, awareness, classification and submission.

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.

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.

Article 18 is supplemented by Delegated Regulation (EU) 2024/1772. The decision is not simply “any two criteria”. Under Article 8 of that delegated regulation, an incident must affect critical services as described in Article 6, and either meet the special malicious unauthorised-access threshold in Article 9(5)(b), or meet at least two of the other materiality thresholds.

Apply the threshold structure

The clients, financial counterparts and transactions criterion contains several alternatives, including more than 10% of clients using the affected service or more than 100,000 affected clients. Use the denominator for the affected service, not automatically the entire bank’s customer base. Relevant clients or counterparties can also matter even when a percentage is not reached.

Duration and service downtime are one criterion with alternative thresholds: incident duration longer than 24 hours, or downtime longer than two hours for ICT services supporting critical or important functions. Do not count these two alternatives as two separate criteria. Incident duration runs from occurrence to resolution; where occurrence cannot be established, the rule provides for detection and estimates based on available evidence.

The other criteria cover reputational impact, geographical spread, data losses and economic impact. Geographic impact must be assessed in the affected Member States; a provider’s international footprint alone is not enough. The economic threshold is costs and losses exceeding, or likely to exceed, €100,000, assessed under the delegated regulation. It is not a percentage of regulatory capital.

For data losses, examine availability, authenticity, integrity and confidentiality and the impact on business objectives or regulatory requirements. The distinct successful, malicious and unauthorised-access threshold may be met where access may result in data losses. Assess GDPR notification separately: a personal data breach does not automatically require a DPA report if it is unlikely to result in a risk to people.

Track recurrence and the evidence behind classification

For entities subject to Article 8(2), assess recurring incidents monthly. Incidents occurring at least twice within six months, with the same apparent root cause, can collectively meet the major-incident criteria. That recurrence provision excludes microenterprises and Article 16(1) entities. Keep the affected critical function, each applicable threshold, calculations, assumptions and assessment time in the record so a later reclassification is explainable.

What Are the Three-Stage DORA Incident Reporting Timelines?

Article 19 establishes the reporting duty. Delegated Regulation (EU) 2025/301, Article 5 sets the time limits; Implementing Regulation 2025/302 supplies forms and procedures. Record each deadline’s own starting point rather than calculating all three from detection.

Stage 1: Initial notification within 4 hours

Submit the initial notification as early as possible, within four hours of major classification and normally no later than 24 hours after awareness of the ICT incident, subject to the later-classification rule below. 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.

If an incident is classified as major only after more than 24 hours have passed since awareness, Article 5(2) requires initial notification within four hours of that later classification. Preserve the evidence explaining when the threshold was met; this is not permission to delay assessment.

Stage 2: Intermediate report within 72 hours

The intermediate report is due within 72 hours of the initial notification, even if status or handling has not changed. Report updated impact, classification and response information. An updated intermediate report is required without undue delay when regular activities have been recovered and business is back to normal. Do not omit a required stage merely because the incident was resolved quickly; follow the prescribed submission procedure.

Stage 3: Final report within one month

The final report is due within one month of the intermediate report or, where relevant, the latest updated intermediate report. It contains root-cause and impact information, costs and losses, and remediation. Check Article 5’s limited weekend/public-holiday arrangements against the entity’s category; they are not a general business-hours exemption. If a deadline cannot be met, inform the authority within the prescribed limit and explain the delay.

A practical example: awareness at 08:00 and major classification at 10:00 normally produce a 14:00 latest initial-notification deadline. An initial filing at 12:00 starts the 72-hour intermediate clock at 12:00, not at detection or classification. Preserve timezone offsets and submission receipts, including failed portal attempts and use of any authorised fallback channel.

Who Must Be Notified?

Identify the competent authority under Article 46 for the particular financial entity and use its current reporting channel. For banking-union credit institutions, follow the relevant ECB or national authority arrangements rather than assuming every euro-area bank has the same recipient. Insurance, securities, payments and crypto-asset entities have their respective designated authorities. The UK PRA is not an EU DORA competent authority.

Maintain an entity-by-entity routing sheet with the authority, portal credentials, backup submitter, template version and fallback contact. The ESAs’ incident-reporting materials include operational instructions dated 16 September 2026; these support data quality and are expressly staff-level instructions, not a new legal interpretation.

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 also involves a personal data breach, separately assess the GDPR duties for the entity’s role. A controller must notify the data protection authority under Article 33 unless the breach is unlikely to result in a risk to people; a processor must inform its controller without undue delay. A DORA filing does not replace a required GDPR notification to the supervisory authority. Record the risk assessment even when authority notification is not required.

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(3) requires financial entities to establish procedures for identifying the root causes of ICT-related incidents and to address those causes to prevent recurrence.

Incident registers, root cause analyses and remediation records can support both GDPR and DORA decisions, while each regime’s assessment and reporting duties remain distinct.

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.

Keep voluntary threat notifications distinguishable from mandatory major-incident reports. Record why a threat is significant and what information can be shared securely; do not postpone a mandatory report while deciding whether to use the voluntary channel.

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

For a controller, GDPR Article 33 requires authority notification without undue delay and, where feasible, within 72 hours of awareness of a personal data breach, unless it is unlikely to result in a risk to people. DORA normally requires the initial notification as early as possible, within four hours of major classification and no later than 24 hours after awareness of the ICT incident. Under Article 5(2) of Delegated Regulation 2025/301, classification as major after that 24-hour period instead starts a four-hour deadline from classification. Compare the actual awareness and classification timestamps; neither regime’s deadline is invariably earlier. A major ICT incident without a personal data breach can require DORA reporting alone, while an overlapping personal breach still needs its own GDPR risk assessment.

Different recipients

GDPR breach notifications go to the data protection supervisory authority (for example, CNIL in France or the competent federal or state authority in Germany). DORA incident reports go to the financial competent authority. These are distinct bodies with different mandates. Where both notification duties apply, reporting to one does not discharge the duty 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?

The Article 19 duty belongs to the financial entity, even if reporting is outsourced. Provider assistance and relevant notification clauses under Article 30 must supply information early enough for the entity to classify and report. Do not mistake the financial entity’s four-hour reporting limit for a universal statutory four-hour supplier-notification clause.

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 available information by the applicable initial deadline, including the usual 24-hour awareness limit or later-classification rule, 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.

FAQ

What ICT incidents must be reported under DORA?

Article 19 DORA requires reporting of “major ICT-related incidents” to competent authorities. Classification as major depends on impact criteria in the RTS: number of clients affected, duration, geographic spread, data loss, economic impact, and reputational significance.

What are the DORA incident reporting timelines?

Initial notification is as early as possible, within four hours of major classification and normally no later than 24 hours after awareness; Article 5(2) covers later classification. The intermediate report is within 72 hours of the initial notification; the final is within one month of the intermediate or latest updated intermediate report.

Who receives DORA incident reports?

Report through the channel designated by the entity’s competent authority. Authorities handle onward transmission under DORA; do not assume a separate direct EBA filing is universally required of payment service providers.

How does DORA incident reporting differ from GDPR breach notification?

DORA covers major ICT-related incidents affecting in-scope financial entities. GDPR Article 33 covers personal data breaches unless unlikely to result in risk, and Article 34 separately addresses high-risk communication to individuals. A ransomware event may require both routes.

L
Written by
Legiscope
Legiscope

Put this guidance into operation

See how Legiscope connects privacy records, source material and review-controlled work.

Book a tailored demo
Continue reading

Related articles

01Financial Regulation

Best DORA Compliance Software: 6 Tools Compared + Pricing 2026

DORA compliance software automates the five pillars the Digital Operational Resilience Act imposes on EU financial entities: ICT risk management (Articles 5-16), incident classification and reporting…

March 28, 2026
02Financial Regulation

DORA Compliance Guide: Scope, ICT Risk, Incidents and Suppliers

The Digital Operational Resilience Act, Regulation (EU) 2022/2554, has applied since 17 January 2025. It sets EU rules for the digital operational resilience of specified financial entities and an…

March 28, 2026
03Financial Regulation

DORA Compliance Software for Enterprises (2026)

For an enterprise financial group, the best DORA compliance software is an enterprise-grade GRC platform that consolidates the Register of Information across every legal entity, aggregates ICT…

July 7, 2026
04Financial Regulation

DORA Compliance Software for Startups & Fintechs

DORA software for a startup should be selected against the entity’s actual regulatory obligations and operating model. A small headcount does not automatically qualify a payment institution,…

July 7, 2026
05Financial Regulation

DORA Compliance Software: Compare Workflows and Evidence

The Digital Operational Resilience Act (Regulation (EU) 2022/2554) has been enforceable since 17 January 2025. This buying guide compares the evidence and workflows an institution should require; it…

July 6, 2026
06Financial Regulation

DORA for Banks: Obligations and Roadmap

Banks face the most demanding tier of obligations under the Digital Operational Resilience Act (Regulation (EU) 2022/2554). Since 17 January 2025, DORA compliance for banks has been a binding legal…

March 28, 2026
07Financial Regulation

DORA ICT Risk Management Framework Explained

DORA ICT risk management is the most extensive obligation imposed by the Digital Operational Resilience Act on financial entities in the European Union. Articles 5 through 16 of Regulation (EU)…

March 28, 2026
08Financial Regulation

DORA Non-Compliance Costs: A Fintech Risk and Budget Guide

DORA non-compliance can expose a fintech to supervisory intervention, national penalties and expensive operational remediation. It does not create one universal turnover-based fine for every…

March 28, 2026