Under the Digital Operational Resilience Act, the moment you classify a major ICT-related incident, a reporting clock measured in hours starts to run. DORA incident reporting is the obligation on EU financial entities to notify their competent authority in a defined initial, intermediate, and final sequence — and to get the first submission out in roughly four hours. This guide covers what makes an incident major, when the clock starts, and what each report has to say. It sits inside the wider discipline of cyber incident management.
DORA incident reporting is the requirement for EU financial entities to report a major ICT-related incident to their competent authority through a set sequence — an initial notification roughly four hours after classification, an intermediate report as the situation stabilizes, and a final report with root-cause analysis.
Not every ICT wobble is reportable. DORA — the EU's Digital Operational Resilience Act — draws a hard line between an ordinary ICT incident and a major ICT-related incident, and only the latter triggers the mandatory reporting sequence. Classification is a defined step, assessed against a set of criteria: how many clients and financial counterparts are affected and how relevant they are, any data losses touching the availability, integrity, authenticity, or confidentiality of data, the duration and service downtime, the geographical spread across member states, and the economic impact and criticality of the services hit.
The practical point is that classification is a decision you have to make quickly and defend later. Get it wrong in one direction and you report noise; get it wrong in the other and you miss a statutory deadline. That is why the classification step deserves the same rigor as the technical response — it is the pivot the whole reporting obligation turns on, and it is the moment every clock begins.
A costly misconception is that the deadline runs from when the incident began. It does not. Under DORA the clock starts at classification — the moment you determine an incident is major. From that point, call it T-zero, reporting runs in a defined sequence to your competent authority:
The figure to internalize is the first one. Roughly four hours from classification is not long to assemble a coherent, regulator-ready notification while the incident is still live — which is exactly why knowing your obligations, recipients, and templates in advance pays off. For the full cross-regime picture, our incident clocks guide lays DORA, NIS2, and GDPR side by side.
This is the EU baseline; national transposition varies. It's informational, not legal advice — verify the specifics that bind you with qualified counsel.
The obligation sits with the financial entity — banks, payment and e-money institutions, investment firms, insurers, crypto-asset service providers, and the many other in-scope entities — reporting to its designated competent authority. When the incident originates at an ICT third-party provider, the financial entity generally remains responsible for reporting: the provider's outage is still your major incident if it disrupts your services. That makes third-party visibility part of incident reporting, not a separate concern — you cannot report on time about a provider you cannot see into.
DORA also expects a complete register of ICT third-party arrangements, so the population of providers that could cause a reportable incident is known in advance rather than reconstructed under pressure. See the DORA solution page for how whole-register classification supports both the register and the clock, and how it connects to sound third-party risk management upstream.
One incident can trip several regimes at once. A ransomware event at a payments processor can be a DORA major incident, a NIS2 significant incident, and a GDPR personal-data breach simultaneously — three clocks, three formats, three recipients, all counting from the same moment. Managing that is a coordination problem more than a technical one, and it is the heart of cyber incident management.
For financial entities the relationship between the two cyber regimes matters especially, because DORA operates as the more specific rule for ICT risk and incident reporting. We work through how they interact in DORA vs NIS2.
Polestead's Critical Incident Intelligence Center maps your business profile to the regimes that bind you, and on classification it starts every clock at once — producing the next-step plan, the DORA initial, intermediate, and final schedule, and each regulator-ready report in parallel.
How CIIC works →It is the obligation on EU financial entities to report a major ICT-related incident to their competent authority in a defined sequence: an initial notification roughly four hours after classification, an intermediate report as the situation develops, and a final report with root-cause analysis.
At classification — the moment you determine an incident is major — not when the incident began. The initial notification is due roughly four hours after that classification, so fast, accurate classification directly protects the deadline.
An initial notification roughly four hours after classification, an intermediate report as the situation stabilizes and the picture updates, and a final report with root-cause analysis once the incident is resolved.
Yes. One incident can be a DORA major incident, a NIS2 significant incident, and a GDPR personal-data breach at the same time, each with its own clock and format. This is the EU baseline; national transposition varies, and this is informational, not legal advice.