DORA Incident Reporting

DORA Incident Reporting: What You Need to Know

Articles 17 through 23 of DORA (EU Regulation 2022/2554) establish a harmonised incident reporting regime for the entire EU financial sector. For the first time, all financial entities, regardless of whether they are banks, insurers, payment providers, or crypto-asset service providers, follow the same classification criteria, reporting timelines, and reporting channels for ICT-related incidents.

This is a significant shift from the previous fragmented landscape where different sectoral directives imposed different reporting requirements. DORA creates a single rulebook for incident management and reporting in the financial sector.

The ICT Incident Management Process (Art. 17)

Art. 17 requires financial entities to define, establish, and implement an ICT-related incident management process. This process must cover:

• Early warning indicators to trigger detection of ICT-related incidents
• Procedures for identifying, tracking, logging, categorising, and classifying incidents
• Roles and responsibilities for different incident types and scenarios
• Communication plans to staff, external stakeholders, clients, and media
• Procedures for reporting major ICT incidents to senior management and the management body
• Incident response procedures, including containment and forensic analysis

The incident management process must be tested regularly as part of the resilience testing programme under Art. 25. For details on testing requirements, see our Resilience Testing page.

Classification of ICT-Related Incidents (Art. 18)

Art. 18 defines the criteria for classifying ICT-related incidents. Financial entities must classify incidents based on the following dimensions:

The ESAs have published Regulatory Technical Standards (RTS) that provide specific thresholds for when an incident must be classified as "major." These thresholds make the classification criteria operational and reduce ambiguity. An incident is classified as major when it meets the criteria across multiple dimensions, such as affecting critical services, lasting beyond a certain duration, or impacting a threshold number of clients.

Reporting Deadlines and Procedure (Art. 19)

Once an ICT-related incident is classified as major, the reporting clock starts. Art. 19 establishes a three-stage reporting procedure:

Stage 1: Initial Notification (within 4 hours)

Within 4 hours of classifying the incident as major (and no later than 24 hours after detection), the financial entity must submit an initial notification to the competent authority. This notification must contain essential information about the incident type, a preliminary assessment of the impact, and an indication of whether the root cause has been identified.

Stage 2: Intermediate Report (within 72 hours)

Within 72 hours of the initial notification, the entity must submit an intermediate report. This includes an updated classification, description of the incident's impact, indicators of compromise where available, and actions taken to contain and resolve the incident. If the incident is resolved before the 72h deadline, this may serve as the final report.

Stage 3: Final Report (within 1 month)

Within one month of the intermediate report, a comprehensive final report must be submitted. This report must include: the root cause analysis, a description of the remediation measures taken, the actual impact (financial and operational), and a statement on whether any follow-up measures are needed to prevent recurrence.

Reporting Channels and Authorities

Reports must be submitted to the competent authority responsible for the reporting entity. In the EU, this is typically the national supervisory authority:

• Germany: BaFin (Bundesanstalt fur Finanzdienstleistungsaufsicht) for banks, insurers, and investment firms
• EU level: EBA (banks), EIOPA (insurance), ESMA (markets) coordinate at the European level and receive aggregated reports
• ECB: Directly supervised institutions report through the SSM (Single Supervisory Mechanism)

Art. 20 establishes harmonised reporting content and templates. The ESAs have developed Implementing Technical Standards (ITS) specifying the data fields, formats, and submission channels. Entities should familiarise themselves with these templates and integrate them into their incident response workflows before an incident occurs.

Voluntary Cyber Threat Reporting (Art. 19(2))

Beyond mandatory incident reporting, Art. 19(2) allows financial entities to voluntarily notify competent authorities of significant cyber threats that they consider relevant to the financial system, even when those threats have not resulted in an actual incident.

Voluntary reporting is an important mechanism for collective defence. When one entity detects a sophisticated threat campaign, sharing that information with the supervisor enables early warnings to other entities. This aligns with the broader information-sharing goals of DORA Pillar 5 (Art. 45).

Supervisory Feedback and Follow-Up (Art. 21-22)

Art. 21 requires competent authorities to provide feedback and guidance to the reporting entity after receiving an incident report. This may include anonymised information on similar threats, guidance on remediation, or additional reporting requests. Art. 22 provides for the centralisation of reporting at the EU level through a single hub, reducing reporting burden for cross-border entities.

Practical Preparation for Incident Reporting

The tight reporting deadlines require significant preparation. Here are the essential steps to ensure your entity can meet the requirements:

• Pre-configure reporting templates: Have templates ready for all three reporting stages so the response team only needs to fill in incident-specific details under pressure
• Define clear escalation paths: Establish who classifies an incident as major, who approves the initial notification, and who submits it to the authority
• Automate detection and triage: The 4-hour classification deadline requires automated or semi-automated triage. Manual review of every alert is not feasible
• Run tabletop exercises: Simulate a major incident end-to-end, from detection through classification to authority notification. Practice at least quarterly
• Maintain authority contacts: Know exactly which portal or channel to use, and maintain access credentials and backup contacts

A structured approach to incident reporting is also critical for avoiding DORA penalties. Late or incomplete reporting can result in administrative sanctions.

Connection to Other DORA Pillars

Incident reporting does not exist in isolation. It is deeply intertwined with the other DORA requirements:

• ICT Risk Management: The detection capabilities required by Art. 10 feed directly into incident identification. Without effective detection, you cannot classify and report in time. See our ICT Risk Management guide.
• Third-Party Risk: Incidents at ICT third-party providers may trigger your reporting obligations. Contracts under Art. 30 must include the provider's obligation to notify you of incidents promptly. See our Third-Party Risk page.
• Resilience Testing: Testing your incident management process is a required part of the resilience testing programme under Art. 25.