One of the most operationally demanding aspects of DORA is the incident reporting framework. When a major ICT incident occurs, regulated entities face a strict three-stage reporting timeline with tight deadlines. Missing a deadline, submitting an incomplete report, or failing to classify an incident correctly can attract supervisory scrutiny and potential sanctions.
This guide explains each reporting stage, the classification criteria, and how to build an operational process that meets the requirements.
What qualifies as a major ICT incident?
Not every ICT disruption triggers DORA reporting. Financial entities must assess incidents against classification criteria defined in the Joint RTS on incident classification (published by EBA, EIOPA, and ESMA). An incident is classified as major if it meets one or more thresholds across the following criteria:
- Clients and financial counterparts affected — number of clients impacted or percentage of total client base exceeding defined thresholds
- Duration and downtime — length of the incident and the duration of service unavailability
- Geographical spread — whether the incident affects operations in multiple EU member states
- Data losses — any loss of data availability, integrity, or confidentiality
- Reputational impact — incidents with significant media coverage or reputational consequences
- Economic impact — gross direct costs exceeding defined thresholds
It is important to note that the classification decision must be made as quickly as possible — the reporting clock starts at classification, not at the point when all facts are established.
The three-stage reporting timeline
Stage 1: Initial notification — within 4 hours of classification
Within 4 hours of classifying an incident as major (and no later than 24 hours after first becoming aware of it), the entity must submit an initial notification to its competent authority.
The initial notification is intentionally brief. At this stage you may not have full information, and regulators understand that. It should include:
- Classification of the incident as major
- Date and time of first detection
- Nature of the incident (e.g. ransomware, system failure, third-party outage)
- Initial impact assessment — services affected and estimated number of clients
- Whether the incident is ongoing
The 4-hour clock starts at classification, not detection. However, entities must classify as quickly as possible — the 24-hour backstop applies regardless of when classification occurs.
Stage 2: Intermediate report — within 72 hours
The intermediate report provides more detail as the picture becomes clearer. It must be submitted within 72 hours of classifying the incident as major.
It should cover:
- Updated description of what happened and the root cause, if known
- Measures already taken to contain or mitigate the incident
- Estimated impact — financial, operational, reputational
- Whether the incident is resolved or still ongoing
- A revised timeline of events
If the incident is fully resolved before 72 hours have elapsed, the intermediate report may be combined with the final report (see below).
Stage 3: Final report — within 30 days
The final report is due within one month of submitting the initial notification, or within 30 days of the incident being resolved, whichever is later.
The final report must include:
- Complete root cause analysis
- Full impact assessment, including quantification of costs where possible
- All measures taken to resolve the incident
- Cross-border impact analysis if operations in multiple member states were affected
- Lessons learned and any resulting changes to controls or procedures
The final report is the document regulators will scrutinise most closely. The root cause analysis must be thorough, and the lessons-learned section should demonstrate that the entity has taken concrete steps to prevent recurrence.
Which authorities do you report to?
Entities report to their national competent authority (NCA) — the regulator responsible for supervising them under their sector-specific legislation. For example:
- Banks report to their national banking regulator (e.g. CBI in Ireland, BaFin in Germany, DNB in the Netherlands)
- Payment institutions report to their national payment services regulator
- Investment firms report to their national securities authority
The European Supervisory Authorities (EBA, EIOPA, ESMA) have published standardised reporting templates that entities should use when submitting reports to their NCA.
Voluntary reporting of significant cyber threats
In addition to mandatory incident reporting, DORA Article 19(2) allows entities to voluntarily notify competent authorities of significant cyber threats that have not yet materialised into incidents — for example, an active threat actor campaign targeting the sector. This is encouraged but not mandatory, and regulators have indicated they view proactive notification positively.
Building an operational process that meets the deadlines
The key operational challenge is speed — 4 hours is very little time to draft and submit a notification when your teams are simultaneously managing a live incident.
Effective organisations prepare by:
- Pre-defining classification criteria and making them accessible to on-call teams — ideally embedded in the ITSM ticketing workflow
- Maintaining draft notification templates pre-populated with entity and authority information
- Establishing a clear chain of communication: who decides on major classification? who drafts? who approves? who submits?
- Running annual tabletop exercises simulating major incidents, including the reporting workflow
- Ensuring contact details for NCAs are maintained and up to date at all times
Regulatory expectation: the classification decision and initial notification should not require a lengthy escalation chain. The process should be documented, understood, and practised before an incident occurs.
The audit trail requirement
DORA requires that entities maintain complete and accurate records of all ICT-related incidents, including the classification rationale, all communications with competent authorities, and all internal actions taken. This audit trail must be available for supervisory inspection at any time.
This makes incident management a documentation challenge as well as an operational one — every action, decision, and communication needs to be timestamped and retained.