DORA Incident Reporting: Timelines and Requirements
DORA establishes a harmonized framework for detecting, classifying, and reporting major ICT-related incidents across the EU financial sector. Unlike previous fragmented approaches, DORA creates consistent reporting obligations with strict timelines that apply to all in-scope financial entities.
Understanding these requirements is critical because the clock starts ticking the moment you become aware of an incident. Missing reporting deadlines can result in regulatory penalties on top of the incident itself.
Key Takeaways
| Point | Summary |
|---|---|
| Three-stage reporting | Initial notification, intermediate report, and final report required |
| Strict timelines | Initial notification within 4 hours of classification, 24 hours of detection maximum |
| Classification criteria | Multiple factors determine whether an incident is "major" |
| Client notification | Affected clients must be informed when their financial interests are impacted |
| Competent authority | Reports go to your primary financial supervisor |
Quick Answer: DORA requires financial entities to report major ICT-related incidents in three stages: an initial notification within 4 hours of classifying the incident as major (but no later than 24 hours after detection), an intermediate report within 72 hours, and a final report within one month. Incidents are classified as major based on criteria including the number of clients affected, duration, data losses, and impact on critical functions.
What Is a Major ICT-Related Incident?
Not every ICT disruption requires regulatory reporting. DORA defines specific criteria for classifying incidents as "major" and therefore reportable.
Classification Criteria
An incident is considered major if it meets the thresholds for at least one of the following criteria:
| Criterion | Consideration |
|---|---|
| Clients affected | Number and percentage of clients impacted |
| Duration | How long the incident persists or service is degraded |
| Geographic spread | Whether the incident has cross-border implications |
| Data losses | Impact on data availability, integrity, or confidentiality |
| Service criticality | Whether critical or important functions are affected |
| Economic impact | Direct and indirect financial losses |
| Transactions affected | Number and value of transactions impacted |
Significant Cyber Threats
In addition to incidents, DORA requires reporting of significant cyber threats. A cyber threat is considered significant if:
- It could materially impact the financial entity
- It could trigger a major ICT-related incident
- It could affect multiple financial entities or the financial system
Threat reporting enables supervisory authorities to issue warnings and coordinate sector-wide responses.
The Three-Stage Reporting Timeline
DORA mandates a structured three-stage reporting process that allows authorities to track incidents as they unfold.
Stage 1: Initial Notification
| Element | Requirement |
|---|---|
| Deadline | Within 4 hours of classification as major; within 24 hours of detection at latest |
| Trigger | Classification of incident as major |
| Content | Basic incident details, initial impact assessment, systems affected |
The initial notification must include:
- Date and time of detection
- Date and time of classification as major
- Initial assessment of incident type and cause
- Systems and services affected
- Initial impact assessment
- Initial actions taken
Stage 2: Intermediate Report
| Element | Requirement |
|---|---|
| Deadline | Within 72 hours of initial notification |
| Trigger | Significant status updates or when requested by authorities |
| Content | Updated impact assessment, root cause analysis (if available), recovery status |
The intermediate report must include:
- Updated impact assessment
- Root cause analysis (preliminary if final not available)
- Number of clients and transactions affected
- Data losses and impact on data integrity
- Recovery measures taken and ongoing
- Communication with affected parties
- Any cross-border implications
Additional intermediate reports must be submitted when significant status updates are available.
Stage 3: Final Report
| Element | Requirement |
|---|---|
| Deadline | Within 1 month of the last intermediate report |
| Trigger | Completion of root cause analysis or resumption of regular activities |
| Content | Complete root cause analysis, total impact, remediation measures, lessons learned |
The final report must include:
- Complete root cause analysis
- Total impact (clients, transactions, data, financial losses)
- Detailed timeline of events
- Recovery actions taken
- Remediation measures implemented
- Lessons learned and improvements identified
- Communication undertaken
Timeline Summary
Detection → Classification → Initial → Intermediate → Final
(max 24 hrs) (4 hrs) (72 hrs) (1 month)Who Receives the Reports?
Competent Authority
Reports are submitted to your primary competent authority:
| Entity Type | Competent Authority |
|---|---|
| Credit institutions | National banking supervisor (ECB for significant banks) |
| Investment firms | National securities regulator |
| Insurers | National insurance supervisor |
| Payment institutions | National payment supervisor |
Cross-Border Coordination
When incidents have cross-border implications, competent authorities coordinate through the ESAs (EBA, EIOPA, ESMA) and European Systemic Risk Board.
ECB Role
For significant credit institutions under direct ECB supervision, reports go to the ECB. The ECB may share relevant information with national authorities.
Client Notification
DORA requires financial entities to notify clients when a major incident affects their financial interests.
When Client Notification Is Required
You must notify clients without undue delay when:
- A major ICT-related incident has occurred
- The incident may adversely affect their financial interests
- Client action may be needed to mitigate impact
Notification Content
Client communications should include:
- Nature of the incident (without compromising security)
- Potential impact on their services or data
- Measures taken to address the incident
- Actions clients should consider taking
- Contact point for further information
Communication Channels
Use established communication channels appropriate to the urgency:
- Website notifications for general awareness
- Direct communication (email, app notifications) for affected clients
- Customer service briefing for incoming inquiries
Incident Management Process
Detection and Analysis
Before you can report, you must detect and analyze:
| Phase | Activities |
|---|---|
| Detection | Identify potential incidents through monitoring and alerts |
| Analysis | Assess scope, impact, and root cause |
| Classification | Determine if classification criteria are met |
| Documentation | Record timeline, evidence, and decisions |
Classification Decision
The classification decision triggers reporting obligations. Document:
- Date and time of classification decision
- Criteria met (which thresholds triggered)
- Evidence supporting classification
- Approver of classification decision
Ongoing Monitoring
Throughout the incident:
- Track impact changes
- Document recovery progress
- Identify information for updates
- Prepare client communications
Weekend and Holiday Handling
Significant Institutions
Significant or systemically important institutions must report within standard timelines regardless of weekends or holidays.
Other Entities
For other regulated financial entities:
- Deadlines falling on non-working days extend to 12:00 pm the next working day
- This applies to intermediate and final reports
- Initial notification obligations still apply within working hours
Common Challenges
Third-Party Incidents
When an ICT third-party provider experiences an incident affecting your services:
- The reporting obligation remains with you, not the provider
- Your timeline starts when you become aware, not when the provider discovered it
- Ensure contracts require timely incident notification from providers
Incident Upgrade
If an incident initially classified as non-major is later upgraded:
- A new classification decision is made
- Initial notification is due within 4 hours of the upgrade
- Reference the original incident in reporting
Multiple Incidents
When multiple related incidents occur:
- Each distinct incident requires separate reporting
- Related incidents may be reported together if they share a common cause
- Aggregated reporting may be appropriate in some cases
Common Questions
What happens if we miss a reporting deadline?
Late reporting constitutes a breach of DORA and may result in supervisory action. Document any reasons for delay and communicate proactively with your competent authority. Repeated late reporting will attract enhanced scrutiny.
How do these requirements relate to GDPR breach notification?
Incidents involving personal data may trigger both DORA and GDPR breach notification obligations. The requirements are separate: DORA reporting goes to financial supervisors, GDPR notifications go to data protection authorities. Coordinate your response to meet both sets of deadlines. For organizations also pursuing SOC 2 compliance, incident response documentation overlaps significantly with DORA requirements.
Must we report incidents at ICT third-party providers?
You must report major incidents affecting your operations, regardless of whether the root cause is internal or at a third-party provider. Ensure your contracts require providers to notify you promptly of incidents affecting your services.
Is there a standard reporting format?
The ESAs have developed technical standards specifying reporting templates and content requirements. Use the formats prescribed by your competent authority.
Do we need to report significant cyber threats?
Yes. Significant cyber threats that could trigger major incidents should be reported voluntarily to enable supervisory coordination and sector-wide response.
How Bastion Helps
Bastion supports financial entities in developing and implementing incident reporting capabilities:
- Incident classification: Development of classification criteria and decision trees
- Response procedures: Incident response plan development aligned with DORA timelines
- Reporting templates: Preparation of report templates and content guides
- Process integration: Integration of DORA reporting with existing incident management
- Training: Staff training on incident handling and reporting obligations
- Testing: Tabletop exercises to validate reporting processes
Ready to strengthen your incident reporting capabilities? Talk to our team
Sources
- DORA Articles 17-23 - ICT-related incident management, classification, and reporting
- ESA RTS on Major Incident Reporting - Technical standards on incident classification and reporting
- EU Regulation 2025/302 - Implementing regulation on incident reporting content and timelines