Patroklos PatroklouLast updated: 21 October 2026
Quick answer: DORA major incident reporting requires EU financial entities to classify ICT-related incidents and report major ones to their competent authority in three stages: an initial notification within 4 hours of classifying the incident as major (and no later than 24 hours after becoming aware of it), an intermediate report within 72 hours, and a final report within one month.
Since 17 January 2025, every financial entity in scope of the Digital Operational Resilience Act (DORA) has had to report major ICT-related incidents using harmonised criteria, timelines and templates. The volume is significant: supervisors received thousands of reports in the first year.
This guide explains how DORA major incident reporting works in practice, from classification through the three reports, how it interacts with GDPR and NIS2, and a step-by-step playbook a CISO can adopt. It reflects the rules and supervisory publications as of autumn 2026.
What is DORA major incident reporting?
It is the obligation in Article 19 of DORA for financial entities to report major ICT-related incidents to their relevant competent authority, using a set structure of initial, intermediate and final reports. It sits within Chapter III of the regulation, which also requires an incident management process (Article 17) and a classification method (Article 18).
The detailed rules come from three legal acts, all available on EUR-Lex:
- Regulation (EU) 2022/2554 (DORA), Articles 17 to 23.
- Delegated Regulation (EU) 2024/1772, which sets the classification criteria and materiality thresholds.
- Delegated Regulation (EU) 2025/301, which sets the content and time limits of reports, together with Implementing Regulation (EU) 2025/302 on the standard templates. Both entered into force on 12 March 2025.
Scale matters here. The ESAs’ first report on DORA major ICT-related incidents, published on 3 June 2026, counted 3,383 major incidents reported during 2025. About a third had cross-border impact and only around 10% were cybersecurity-related. System failures and external events were the main causes.
What makes an ICT incident “major” under DORA?
An incident is major when it affects critical services and either involves successful, malicious, unauthorised access to network and information systems that may result in data losses, or meets the materiality thresholds of at least two other classification criteria. That is the rule set by the classification RTS.
The classification RTS (EU) 2024/1772 builds on the criteria in Article 18(1) of DORA:
| Criterion | Example materiality threshold |
|---|---|
| Clients, financial counterparts and transactions | More than 10% of clients using the affected service, or more than 100,000 clients affected |
| Reputational impact | Media attention, complaints, regulatory non-compliance or loss of clients |
| Duration and service downtime | Incident lasting longer than 24 hours, or critical service downtime longer than 2 hours |
| Geographical spread | Impact in two or more Member States |
| Data losses | Impact on availability, authenticity, integrity or confidentiality of data |
| Economic impact | Costs and losses over EUR 100,000 |
| Critical services affected | Always required for a major incident |
The RTS also covers recurring incidents: smaller incidents with the same apparent root cause can together count as one major incident. Microenterprises and entities under the simplified ICT risk framework are exempt from that recurring rule.
Common mistake: Waiting for full certainty before classifying. The four-hour clock starts at classification, but the 24-hour outer limit runs from awareness. Delaying the classification decision does not buy extra time; it only risks missing the 24-hour limit.
What are the DORA reporting deadlines?
There are three reports, each with its own deadline under Article 5 of Delegated Regulation (EU) 2025/301.
| Report | Deadline | Main content |
|---|---|---|
| Initial notification | Within 4 hours of classification as major, and no later than 24 hours after becoming aware of the incident | Basic facts, classification criteria met, affected services and early impact |
| Intermediate report | Within 72 hours of the initial notification, and again without delay when regular activities are recovered | Updated impact, status of recovery, detailed classification information |
| Final report | No later than one month after the latest intermediate report | Root cause analysis, actual impact figures, remediation and lessons learned |
Is there a weekend and holiday exception?
Yes, for some entities. Where a deadline falls on a weekend or bank holiday, entities may submit by noon on the next working day. The exception does not apply to credit institutions, central counterparties, operators of trading venues, or entities designated as essential or important under NIS2. Competent authorities can also withdraw it from other significant entities.
In practice: Treat the weekend exception as a backstop, not a plan. If you are a bank or a NIS2 essential entity, your on-call rota must be able to classify and file a report at 3am on a Sunday.
Who receives the report, and who else must you tell?
Reports go to your relevant competent authority, and in some cases further. Article 19 also requires you to inform clients where an incident affects their financial interests.
- Competent authority: the national authority that supervises you. Where several authorities supervise an entity, the Member State designates one for reporting.
- ECB: for significant credit institutions, national authorities forward reports to the ECB.
- CSIRTs: Member States may require reports to also go to the national CSIRT under NIS2.
- Clients: where a major incident affects clients’ financial interests, you must inform them without undue delay of the incident and the measures taken.
You may outsource the reporting task to a third-party provider, but Article 19(5) keeps full responsibility with you. Entities can also voluntarily notify significant cyber threats that they believe are relevant to the financial system, service users or clients.
How does DORA reporting interact with GDPR and NIS2?
DORA replaces NIS2 incident reporting for in-scope financial entities, but it does not replace GDPR. If a major ICT incident also involves personal data, you may need two separate notifications.
| Regime | Trigger | First deadline | Recipient |
|---|---|---|---|
| DORA | Major ICT-related incident | 4 hours from classification, max 24 hours from awareness | Financial competent authority |
| GDPR Art. 33 | Personal data breach likely to result in risk | 72 hours from awareness, where feasible | Data protection supervisory authority |
| NIS2 Art. 23 | Significant incident (non-DORA entities) | 24-hour early warning | CSIRT or competent authority |
For a financial entity, the DORA and GDPR tracks run in parallel with different thresholds and regulators. If you also support non-financial group companies, our guide to the NIS2 incident reporting cascade covers that side. For personal data, see our GDPR compliance page.
Change may be coming. The Commission’s Digital Omnibus proposal of 19 November 2025 includes a single entry point for incident reporting across several laws, including DORA and GDPR. As of September 2026 it is still before the European Parliament and Council, according to the Parliament’s Legislative Train, so current obligations apply unchanged. Commentators also note the proposal would not change the underlying deadlines and thresholds.
A step-by-step playbook for DORA major incident reporting
Use this playbook to turn the rules into a repeatable process. Every step should have a named owner and a backup.
- Detect and log. Record every ICT-related incident as required by Article 17, with a timestamp for when you became aware.
- Assess critical services first. Check whether any critical or important function is affected. If not, the incident cannot be major.
- Test the criteria. Check for malicious unauthorised access with potential data loss, then check each materiality threshold. Record your reasoning.
- Classify and timestamp. Record the classification time; the four-hour clock starts here.
- File the initial notification. Use the ITS template, submit via your authority’s channel and keep proof of submission.
- Check parallel obligations. Decide on GDPR notification, client communication and any group or NIS2 reporting.
- Submit the intermediate report within 72 hours, and update it when services recover.
- Complete root cause analysis and file the final report within one month.
- Close the loop. Feed lessons into your ICT risk management framework and post-incident review under Article 13.
Pre-built workflows make the clock easier to meet. Enactia’s AI-powered GRC platform includes incident and data breach management with timed notification workflows, and links incidents back to affected assets, risks and vendors. To test it against your own playbook, start your 14-day free trial.
What goes wrong most often?
Most reporting failures come from preparation gaps rather than bad intentions. The ESAs’ finding that system failures and external events drove most 2025 incidents points to the same weak spots.
- No up-to-date map of critical services. Without it, the first classification step stalls.
- Third-party blind spots. Many incidents start at an ICT provider. Your contracts and your third-party risk management process should require providers to notify you quickly with the data you need to classify.
- Thresholds not pre-calculated. Know in advance what 10% of clients means for each service.
- Weak evidence. Keep timestamps, decision logs and submissions; supervisors may review late reports.
Your DORA register of information is a useful source for mapping which providers support which critical functions.
Key takeaways
- DORA major incident reporting uses three reports: 4 hours from classification (max 24 hours from awareness), 72 hours, and one month.
- An incident is major only if critical services are affected plus malicious access with potential data loss, or two other thresholds.
- Banks, CCPs, trading venues and NIS2 essential or important entities cannot use the weekend exception.
- GDPR breach notification still applies in parallel where personal data is involved.
- The ESAs counted 3,383 major incidents in 2025, most caused by system failures and external events.
Frequently asked questions
What is the deadline for the initial DORA incident notification?
The initial notification must be submitted within 4 hours of classifying the incident as major, and no later than 24 hours from the moment the financial entity became aware of the incident. These limits come from Article 5 of Delegated Regulation (EU) 2025/301, which supplements Article 19 of DORA.
Does DORA replace NIS2 incident reporting for banks?
For financial entities in scope of DORA, DORA’s incident reporting rules apply instead of NIS2’s, because DORA acts as sector-specific law. Member States may still require copies of DORA reports to be shared with national CSIRTs. GDPR personal data breach notification is not replaced and must be handled separately.
What happens if we miss a DORA reporting deadline?
DORA leaves penalties to Member States, which must give competent authorities powers to impose administrative penalties and remedial measures. Consequences vary by country and supervisor. In practice, document why a deadline was missed, submit as soon as possible, and address the cause in your post-incident review.
Do we have to report significant cyber threats under DORA?
No, notification of significant cyber threats is voluntary under Article 19(2). Financial entities may notify threats they consider relevant to the financial system, service users or clients, using the content set by the RTS. Where a threat is significant, you should also tell potentially affected clients what protective measures they could take.
Can our ICT provider submit DORA incident reports for us?
Yes. Article 19(5) allows financial entities to outsource reporting obligations to a third-party service provider, but the financial entity remains fully responsible for meeting them. Set this out in the contract, including timelines, data access and who approves each submission before it is filed.
Being ready before the clock starts
DORA major incident reporting rewards preparation. Map critical services, pre-calculate thresholds, agree reporting duties with ICT providers, and rehearse the playbook until the four-hour step feels routine. For the wider regulatory picture, see our DORA compliance overview.
To discuss your incident reporting process, contact us or book a demo or start your 14-day free trial.
This article is for general information and is not legal advice.
