DORA Incident Reporting Playbook: Templates and Timelines

Introduction to Pillar 2: ICT-Related Incident Reporting

Pillar 2 of DORA (Articles 17-23) establishes a harmonised incident reporting framework for the EU financial sector. Before DORA, incident reporting obligations varied significantly across Member States and financial subsectors. DORA creates a consistent, standardised approach to incident detection, classification, and reporting to competent authorities.

The reporting framework has two components: mandatory reporting of major ICT-related incidents and voluntary notification of significant cyber threats. Both are critical to achieving DORA's objective of enhancing supervisory insight into the digital operational resilience of the financial sector.

This playbook provides a complete operational guide for implementing DORA incident reporting. It covers the classification criteria that determine whether an incident is "major," the specific timelines and content requirements for each reporting stage, practical template structures, and the relationship with parallel reporting obligations under NIS2.

Incident Management Process

Before addressing reporting obligations, the entity must have a robust incident management process. Article 17 requires financial entities to define, establish, and implement an ICT-related incident management process to detect, manage, and notify ICT-related incidents.

Process Requirements

• Detection: Mechanisms to promptly detect anomalous activities and ICT-related incidents, including automated alerts and security event monitoring
• Triage: Procedures for initial assessment of severity, scope, and potential impact to enable rapid classification decisions
• Escalation: Defined escalation paths based on incident severity, with clear authority for classification decisions
• Management: Procedures for coordinating response activities, tracking progress, and maintaining communication
• Recording: Logging and documentation of all ICT-related incidents, including those not classified as major, to support trend analysis and learning

Roles and Responsibilities

Define clear roles for the incident reporting lifecycle:

• Incident Handler: First responder responsible for initial detection, recording, and triage
• Incident Coordinator: Senior technical resource responsible for coordinating response and escalation
• Classification Authority: Designated individual or committee authorised to classify incidents as major
• Reporting Officer: Designated individual responsible for submitting reports to the competent authority
• Management Escalation: Senior management and board notification pathway for major incidents
• External Communication: Designated spokesperson for client and public communication

Incident Classification Criteria

Article 18 establishes the classification framework for ICT-related incidents. The RTS on incident classification provides quantitative thresholds that determine whether an incident qualifies as "major."

Classification Criteria

Financial entities must classify ICT-related incidents based on six criteria:

Classification Decision Logic

An incident is classified as major if it meets the quantitative thresholds for at least two of the six criteria, or if it meets the threshold for a single criterion where the impact is particularly severe (as specified in the RTS). The RTS provides a decision tree to guide classification, including secondary criteria for borderline cases.

Classification Speed

The speed of classification directly impacts reporting compliance. Recommendations:

• Implement automated classification triggers using monitoring tools and SIEM correlation rules
• Pre-define classification authority delegation (e.g., SOC lead can classify during out-of-hours)
• Maintain a decision matrix with pre-calculated thresholds specific to your entity
• Run regular classification exercises to build team confidence and speed
• Document the classification decision and rationale contemporaneously

Initial Notification (4 Hours) and Initial Report (24 Hours)

Once an incident is classified as major, the reporting clock starts. Article 19 specifies two immediate reporting obligations.

Initial Notification — Within 4 Hours

The initial notification is a brief, high-level alert to the competent authority. Its purpose is to inform the authority that a major incident has occurred. Content requirements include:

• Entity identification and reporting contact details
• Date and time of detection
• Date and time of classification as major
• Brief description of the incident
• Classification criteria met
• Preliminary impact assessment (clients, services, geographical scope)
• Indication of whether the incident is ongoing or resolved

Initial Report — Within 24 Hours

The initial report provides more detailed information. Building on the initial notification, it must include:

• Updated incident description with technical details
• Detailed impact assessment across all six classification criteria
• Affected ICT systems and services
• Affected business functions (critical/important designation)
• Response actions taken and planned
• Communication actions taken (clients, staff, other entities)
• Preliminary root cause hypothesis (if available)
• Estimated time to resolution
• Cross-border impact assessment

Practical Tips for Meeting the 4-Hour Window

• Prepare pre-filled notification templates with static entity information
• Establish a direct communication channel with the competent authority (e.g., secure email, regulatory portal)
• Designate backup reporting officers for weekends, holidays, and overnight hours
• Automate where possible — some fields can be populated from SIEM and ITSM tools
• Accept that initial notifications will be based on incomplete information — accuracy improves through subsequent reports

Intermediate Report (72 Hours)

The intermediate report, due within 72 hours of classification, provides an updated and more comprehensive view of the incident as the response progresses.

Content Requirements

• Updated incident status (ongoing, contained, resolved)
• Revised impact assessment with quantified data where available (client numbers, financial impact, data records affected)
• Updated root cause analysis — preliminary findings from investigation
• Recovery actions completed and underway
• Updated estimated time to full resolution
• Additional classification criteria met since initial report
• Containment measures implemented
• Impact on other financial entities or market infrastructure
• Communication with clients and external stakeholders

Multiple Intermediate Reports

For prolonged incidents, additional intermediate reports may be required. The competent authority may request updated intermediate reports at defined intervals or when significant new information emerges. Entities should proactively provide updates when material changes occur rather than waiting for requests.

Final Report (1 Month After Resolution)

The final report is due within one month of the incident being resolved. It is the comprehensive record of the incident and its handling.

Content Requirements

• Complete incident timeline from detection through full resolution
• Confirmed root cause analysis with evidence
• Final quantified impact assessment across all classification criteria
• Total duration of the incident (from detection to full recovery)
• Effectiveness assessment of response and recovery actions
• Lessons learned and areas for improvement
• Remediation actions taken and planned (with timelines)
• Updates to the ICT risk management framework resulting from the incident
• Communication summary (regulatory, client, public)
• Cost summary (direct costs, recovery costs, regulatory costs, business impact)

Final Report Quality

The final report is the primary document competent authorities use to assess how the entity managed the incident. High-quality final reports demonstrate:

• Thorough root cause analysis — not just what happened, but why
• Honest assessment of what worked well and what did not
• Concrete, measurable remediation actions with assigned ownership and deadlines
• Evidence that lessons learned are feeding back into the ICT risk management framework
• Clear connection between the incident and any framework or control enhancements

Reporting Timeline Summary

Reporting Template Structure

The ITS on incident reporting content, timelines, and templates specifies the format and data fields for each report type. Below is a summary of the key template sections that entities should prepare.

Initial Notification Template

• Section A — Entity Identification: Legal name, LEI, entity type, competent authority, reporting contact name and details
• Section B — Incident Overview: Incident reference number, detection date/time, classification date/time, incident type (cyber attack, system failure, third-party failure, etc.)
• Section C — Preliminary Impact: Classification criteria met, estimated clients affected, services impacted, geographical scope
• Section D — Status: Ongoing/resolved, initial actions taken

Initial Report Template (extends notification)

• Section E — Technical Details: Affected ICT systems, attack vector (if applicable), indicators of compromise, affected network segments
• Section F — Business Impact: Affected business functions (critical/important designation), service degradation description, client communication status
• Section G — Response Actions: Containment measures, recovery actions initiated, resource mobilisation, external support engaged
• Section H — Estimated Resolution: Estimated time to containment, estimated time to full recovery, dependencies for resolution

Intermediate Report Template (extends initial report)

• Section I — Updated Impact: Quantified client impact, financial loss estimate, data records affected, cross-border assessment
• Section J — Investigation Progress: Preliminary root cause, investigation methodology, evidence collected, external forensics engaged
• Section K — Recovery Progress: Systems restored, services resumed, remaining recovery activities, revised timeline

Final Report Template (comprehensive)

• Section L — Complete Timeline: Chronological account of the incident from initial indicator through full recovery
• Section M — Root Cause Analysis: Confirmed root cause, contributing factors, control failures identified
• Section N — Final Impact Assessment: Definitive figures for all six classification criteria
• Section O — Lessons Learned: What worked well, what needs improvement, framework changes required
• Section P — Remediation Plan: Specific actions, ownership, timelines, KPIs for tracking

Voluntary Significant Cyber Threat Notifications

Article 19(2) establishes a voluntary notification framework for significant cyber threats. While not mandatory, these notifications serve critical sector-wide functions and are strongly encouraged by competent authorities.

When to Notify

Consider voluntary notification when you identify:

• Active targeted threats against your entity or the broader financial sector
• New attack techniques, tactics, or procedures (TTPs) not previously observed in the financial sector
• Vulnerabilities in widely used financial sector software or infrastructure
• Supply chain compromises affecting ICT providers serving financial entities
• Indicators of compromise (IoCs) that may be relevant to other financial entities
• Threat intelligence suggesting imminent, coordinated attacks on the financial sector

Notification Content

• Threat description and assessed severity
• Indicators of compromise (IoCs) — IP addresses, hashes, domains, email addresses
• Attack techniques, tactics, and procedures (TTPs) observed or expected
• Potential impact on the financial sector
• Recommended defensive actions
• Confidence level of the threat assessment

Benefits of Voluntary Notification

• Demonstrates proactive risk management to supervisors
• Contributes to sector-wide resilience through shared intelligence
• Builds a constructive relationship with the competent authority
• May receive reciprocal threat intelligence from the authority
• Aligns with Pillar 5 (Information Sharing) objectives

Relationship to NIS2 Incident Reporting

Many financial entities also fall within the scope of the NIS2 Directive (Directive (EU) 2022/2555) as essential or important entities. DORA and NIS2 both require incident reporting, creating potential for overlap.

Lex Specialis Principle

DORA takes precedence over NIS2 for financial entities under the lex specialis principle (Article 1(2) of DORA and Recital 28 of NIS2). This means:

• Financial entities in scope of DORA report incidents under DORA's framework, not NIS2
• NIS2 incident reporting requirements do not apply separately to these entities
• The DORA competent authority shares relevant incident reports with the NIS2 single point of contact or CSIRT

Comparison of Timelines

Practical Implications

While DORA takes precedence, entities should:

• Maintain awareness of NIS2 requirements in case of changes to the lex specialis application
• Coordinate with NIS2 contacts to ensure information flows between authorities are functioning
• Consider adopting an integrated incident reporting process that satisfies both frameworks where overlap exists
• Be aware that NIS2 CSIRTs may contact the entity for additional information shared through competent authority channels

Testing Your Incident Reporting Playbook

A playbook that has never been tested is a liability, not an asset. Regular testing validates that your reporting processes work under pressure.

Testing Programme

• Tabletop Exercises (Quarterly): Walk through incident scenarios with all key stakeholders, focusing on classification decisions, escalation triggers, and reporting timelines
• Reporting Drills (Semi-Annually): Simulate a major incident and produce actual notification and report documents within the required timelines
• Communication Channel Testing (Annually): Verify that reporting channels to the competent authority are functional and contact details are current
• Cross-Functional Exercises (Annually): Include IT, Security, Legal, Communications, and senior management in full-scale incident simulation

Key Metrics to Track

• Time from detection to classification (target: <2 hours)
• Time from classification to initial notification (target: <4 hours)
• Completeness of initial report within 24 hours
• Quality score of final reports (using post-exercise review)
• Number of classification errors identified and corrected

The 4-hour initial notification window leaves little room for ambiguity. The most common failure mode we observe is not the quality of the report, but the speed of classification. Invest in building classification confidence and speed through regular exercises.

Frequently Asked Questions

What is a major ICT-related incident under DORA?

A major ICT-related incident is one that meets certain severity thresholds defined by DORA classification criteria, including impact on clients, financial losses, duration, geographical spread, data losses, and criticality of affected services. An incident is typically classified as major if it meets thresholds for at least two of the six criteria, or a single criterion with severe impact.

What are the DORA incident reporting timelines?

DORA requires four reporting stages: initial notification within 4 hours of classifying an incident as major, initial report within 24 hours with detailed information, intermediate report within 72 hours with status updates and preliminary root cause analysis, and final report within one month of incident resolution with comprehensive root cause analysis and lessons learned.

Do we need to report cyber threats under DORA?

DORA establishes a voluntary notification framework for significant cyber threats under Article 19(2). Financial entities may notify their competent authority of significant cyber threats they deem relevant to the financial system. While voluntary, participation is strongly encouraged and demonstrates proactive risk management to supervisors.

How does DORA incident reporting relate to NIS2?

DORA takes precedence over NIS2 for financial entities under the lex specialis principle. Financial entities in scope of DORA report incidents under DORA's framework. Competent authorities under DORA share relevant incident reports with NIS2 authorities (CSIRTs and single points of contact) to avoid double-reporting burden on financial entities.

Who do we report DORA incidents to?

DORA incidents are reported to the relevant competent authority that supervises the financial entity — typically the national banking supervisor, insurance supervisor, or securities regulator depending on the entity type. The competent authority then forwards relevant reports to the relevant ESA (EBA, EIOPA, or ESMA) and, where applicable, the ECB.