Incident Reporting

Incident reporting is one of the most operationally demanding requirements introduced by the Digital Operational Resilience Act (DORA). Defined primarily in Articles 17 through 23, DORA creates a harmonized incident reporting framework across the entire EU financial sector. Before DORA, incident reporting requirements varied significantly between member states and across different financial sub-sectors. DORA replaces this fragmented landscape with a single, unified approach that applies to banks, insurance companies, investment firms, payment institutions, crypto-asset service providers, and all other financial entities within its scope.

The foundation of DORA incident reporting is the classification system for ICT-related incidents. Article 18 establishes six specific criteria that financial entities must evaluate to determine whether an incident qualifies as major: the number of clients and financial counterparts affected, the duration of the incident, the geographic spread across member states, the data losses in terms of availability, authenticity, integrity, or confidentiality, the criticality of the services affected, and the economic impact both in direct and indirect terms. The European Supervisory Authorities (ESAs) have published Regulatory Technical Standards (RTS) further specifying quantitative and qualitative thresholds for each criterion. An incident is classified as major if it breaches the materiality thresholds on at least two of these six criteria.

Once an incident is classified as major, a strict multi-stage reporting timeline begins. 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 first becomes aware of the incident. This initial report must contain essential identification information including the nature of the incident, the date and time of detection, and a preliminary assessment of impact. The purpose is to ensure supervisors are aware of significant disruptions as early as possible, even before the full picture is clear.

The intermediate report must follow within 72 hours of the initial notification. This report provides substantially more detail, including updated impact assessments, the root cause if already identified, communication actions taken toward clients and the public, and the status of mitigation measures. If the situation materially changes between the initial and intermediate reports, entities should provide additional updates. The intermediate report serves as the primary mechanism for supervisors to monitor ongoing response efforts and coordinate cross-border information sharing where necessary.

The final report is due within one month of the intermediate report. This comprehensive document must contain the full root cause analysis, a detailed timeline of the incident from detection through resolution, the total impact assessment including financial losses and the number of affected transactions or clients, all remediation measures taken and their effectiveness, and the lessons learned along with planned improvements to prevent recurrence. The final report is the most important document from a supervisory perspective, as it demonstrates the entity's capacity for thorough analysis and continuous improvement.

The competent authorities receiving these reports vary by jurisdiction and entity type. In Germany, BaFin serves as the primary competent authority for most financial entities. The ESAs have developed standardized reporting templates to ensure consistency across jurisdictions and facilitate information sharing between national competent authorities. These templates are designed to be machine-readable, enabling supervisors to aggregate data and identify sector-wide trends or systemic risks emerging from correlated incidents.

Beyond mandatory major incident reporting, DORA Article 19 introduces a voluntary notification mechanism for significant cyber threats. Financial entities are encouraged to report cyber threats that they assess could materially impact their critical functions, even if no actual incident has occurred. This voluntary reporting helps build a sector-wide threat intelligence picture and enables competent authorities to issue warnings to other entities that may be vulnerable to similar threats. While voluntary, entities that consistently participate in threat sharing demonstrate a mature approach to operational resilience that supervisors view favorably.

Comparing DORA incident reporting with NIS2 Directive requirements reveals both overlaps and important distinctions. NIS2, which applies to essential and important entities across many sectors, also mandates incident reporting with an early warning within 24 hours, an incident notification within 72 hours, and a final report within one month. Financial entities that fall under both DORA and NIS2 should note that DORA is considered lex specialis for the financial sector, meaning DORA requirements take precedence. However, understanding the NIS2 framework is valuable because ICT third-party providers serving financial entities may be subject to NIS2, and coordination between the two reporting regimes may be necessary.

Building an effective incident response capability requires far more than just having reporting templates ready. Financial entities should establish a dedicated incident response team with clearly defined roles and responsibilities, including an incident commander, technical investigators, communications leads, legal counsel, and a regulatory reporting coordinator. The incident response plan should be documented, regularly tested through tabletop exercises and simulations, and integrated with the broader business continuity and disaster recovery plans. Detection capabilities must include security information and event management (SIEM) systems, endpoint detection and response (EDR) tools, and network monitoring solutions that can identify anomalous activity before it escalates into a major incident.

Automation plays an increasingly important role in meeting DORA's tight reporting timelines. Manual processes for incident classification and report generation are prone to delays and errors, especially during the stress of an active incident. Modern incident management platforms can automatically correlate alerts, assist with classification against DORA's six criteria, pre-populate reporting templates with technical data from monitoring systems, and track reporting deadlines. Integration between incident management tools and regulatory reporting systems ensures that initial notifications can be submitted within the 4-hour window without diverting attention from the actual response effort.

The lessons learned process required in the final report should not be treated as a mere formality. Effective post-incident reviews analyze not only the technical root cause but also the organizational, procedural, and human factors that contributed to the incident or hindered the response. These reviews should result in concrete, time-bound improvement actions that are tracked to completion and verified for effectiveness. Over time, the accumulation of lessons learned drives meaningful improvements in an organization's operational resilience posture and provides valuable evidence during supervisory assessments that the entity takes incident management seriously.