DORA Incident Reporting

DORA establishes a three-stage reporting process for major ICT-related incidents under Article 19. The initial notification must be submitted to the competent authority within 4 hours of the incident being classified as major, and no later than 24 hours from the point the entity becomes aware of the incident. This initial report must contain the essential facts: what happened, when it was detected, which services are affected, and the estimated impact. The purpose is rapid awareness — not comprehensive analysis.

The intermediate report must be submitted within 72 hours of the initial notification, or sooner if the situation has materially changed. This report must update the initial notification with additional information: root cause analysis progress, the actual (rather than estimated) impact, the containment and mitigation measures taken, and any indicators of compromise identified. If the incident is resolved by the time of the intermediate report, the entity may combine the intermediate and final reports.

The final report must be submitted no later than one month after the intermediate report. This comprehensive document must include the root cause analysis, the chronology of the incident, the total impact assessment (including financial losses), the remediation measures implemented, and the lessons learned. The final report is the document that supervisory authorities will use to assess the entity's resilience posture and response effectiveness. Incomplete or superficial final reports will attract follow-up supervisory actions.

Beyond mandatory major incident reporting, Article 19(2) permits financial entities to voluntarily notify competent authorities of significant cyber threats that they consider relevant to the financial system, even if the threat has not materialised into an incident. This voluntary mechanism is designed to enhance collective intelligence across the financial sector and enable proactive supervisory responses.

Voluntary notifications can cover threat intelligence about emerging attack vectors, observed reconnaissance activity targeting financial infrastructure, or vulnerabilities discovered in widely used ICT components. The reporting threshold for voluntary notifications is intentionally lower than for mandatory major incident reports — the entity needs only to consider the threat potentially significant. There is no penalty for over-reporting through the voluntary channel, and competent authorities have indicated that they actively encourage this information sharing.

The practical value of voluntary notification depends on a functioning feedback loop. Competent authorities that receive threat intelligence should anonymise it and share relevant findings with other supervised entities. The ESAs have indicated that voluntary notification data will feed into sector-wide risk assessments and stress testing scenarios. For financial entities, participating in voluntary notification builds goodwill with supervisors and demonstrates a mature, proactive approach to threat management that can be advantageous during supervisory reviews.

Entities should establish internal criteria for what constitutes a "significant" threat warranting voluntary notification and should document the decision process regardless of whether a notification is ultimately submitted. This creates an auditable record of threat awareness and assessment capability.

Building an effective DORA incident reporting workflow requires integrating several operational capabilities: detection, classification, escalation, drafting, submission, and follow-up. The workflow should be documented in the ICT incident response policy, tested through simulation exercises, and reviewed at least annually.

The detection phase feeds into a triage function that applies the Article 18 classification criteria. At this point, the incident manager must make a binary determination: is this a major incident or not? If yes, the 4-hour clock starts and the initial notification template must be populated with available information. The template should be pre-structured with fields matching the ITS reporting form, and pre-populated with static entity information (LEI, entity name, competent authority details, primary contact) to minimise the time required to complete it.

During the response phase, a designated reporting officer (distinct from the incident commander) should continuously update the intermediate report as new information becomes available. This parallel-track approach — one stream managing the incident, another managing the regulatory reporting — prevents reporting obligations from competing with response activities for attention and resources. The intermediate report should be reviewed by legal and compliance functions before submission to ensure accuracy and consistency with the initial notification.

The final report is a substantive analytical document that should be treated as a deliverable of the post-incident review process. It must demonstrate that the entity understands what happened, why it happened, what the impact was, and what structural improvements have been made or are planned. Financial entities should resist the temptation to submit boilerplate final reports — supervisory authorities use these reports to assess institutional resilience, and a weak final report can trigger on-site inspections or enhanced supervisory measures.

Regular simulation exercises — at minimum annually — should test the entire workflow end-to-end, including populating templates under time pressure, contacting the competent authority's reporting desk, and coordinating between incident response, communications, legal, and compliance teams. These exercises should be documented and their findings fed into the continuous improvement cycle required by Article 15.