Seconds matter: Understanding DORA’s real-time response requirements

What is DORA?

On 17 January 2025, Regulation (EU) 2022/2554, commonly referred to as DORA (Digital Operational Resilience Act), finally came into effect.

The financial and insurance sectors’ increasing reliance on digital technologies makes operational resilience a critical area for regulators. In response, the EU introduced DORA to establish a comprehensive and unified regulatory framework.

The aim of DORA is to ensure that all financial/insurance entities within its scope can withstand, respond to, and recover from ICT-related disruptions and threats.

One of DORA’s most impactful components is its structured approach to incident reporting. Beyond the primary regulation, the Regulatory Technical Standards (RTS) – developed by the European Supervisory Authorities (ESAs) – have introduced detailed guidance on how incidents have to be classified, reported and communicated to authorities. This article explores these requirements and what organizations need to do to comply.

 

Why incident notification matters

In today’s interconnected digital ecosystem, a single cyber incident can have a cascading effect across markets, institutions, and even national economies. Quickly and effectively communicating incidents is essential not only for the individual institution’s crisis management, but also for systemic risk containment and regulatory oversight.

DORA mandates a consistent and timely process for reporting significant ICT-related incidents, promoting greater situational awareness and regulatory coordination across the EU.

 

Incident notification requirements under DORA

Under DORA, financial and insurance entities have to:

• identify and classify ICT-related incidents;
• report major incidents to competent authorities; and
• share information where relevant with clients and stakeholders, especially if the incident could impact their operations.

The key innovation of DORA is the introduction of a standardized, multi-step incident notification process, enhanced by the RTS for accuracy, timeliness and comparability across institutions.

 

Classifying major ICT incidents

According to the RTS, a major ICT-related incident is one that meets one or more criteria across several dimensions, including:

• Client impact: Affects a large number of users.
• Duration and service downtime: Disrupts normal operations for a prolonged period.
• Geographical spread: Affects a wide area, spreading in other member states.
• Economic impact: Causes material losses.
• Data losses: Involves disruption of the availability, authenticity, confidentiality or integrity of data.
• Criticality of services affected: Concerns the entity’s critical infrastructure.

Entities have to implement an internal classification methodology aligned with the impact assessment thresholds defined in the RTS. This is essential to determine whether an incident qualifies as “major” and is therefore notifiable. When an incident is the result of successful, malicious and unauthorized access, it always qualifies as a major incident, regardless of other thresholds.

Once the incident has been identified as major, DORA establishes a three-stage incident reporting system:

1. Initial Notification – Within 4 hours of determining that an incident is major and no later than 24 hours from the discovery of the incident, the entity has to send an initial report to the competent authority. It should include basic facts: type of incident, services affected, estimated impact, and initial mitigation actions.
2. Intermediate Report – Within 72 hours of the initial notification, entities have to provide more detailed information. This includes root cause analysis (if available), full impact scope, and ongoing recovery measures.
3. Final Report – Within 1 month, or as soon as a full post-incident review is complete, the entity has to submit a final report. It should contain:
• root cause and incident timeline
• recovery effectiveness
• lessons learned
• preventative and corrective measures

Entities have to ensure they comply with these timings even if they don't have all the requested information or if the situation hasn't changed between submitting one report and another. In these circumstances, DORA requires entities to submit additional updated reports as soon as the missing information becomes available or the situation changes. Financial entities can outsource their incident reporting obligations to a third-party ICT service provider. Though they will still be responsible for the obligations.

 

Interaction with other legal frameworks

DORA’s incident notification obligations are designed to complement existing frameworks, such as:

• NIS2 Directive (on critical infrastructure cybersecurity) – which doesn't really apply to insurance companies
• GDPR (on personal data breach notifications)
• EBA Guidelines on ICT and security risk management

Entities subject to multiple regimes have to ensure they have harmonized and coordinated reporting mechanisms to avoid duplication and reporting fatigue. The RTS encourages financial firms to use automated tools and centralized internal systems to detect, classify and report incidents.

 

The practical impact of DORA on financial entities

DORA has serious ramifications for insurance companies and financial institutions.

To be “DORA-ready,” insurance and financial institutions should focus on:

• Incident response planning: Ensure existing frameworks align with DORA’s definitions, thresholds, and timelines.
• Tooling and automation: Adopt systems capable of real-time incident detection and report generation.
• Staff training: Operational, IT, and compliance teams have to understand their roles in the notification workflow.
• Testing and simulation: Regularly test response and reporting capabilities through tabletop exercises or cyber drills.

While January 17 has already passed, having a full operational system is not something to take for granted. Companies have to constantly improve their overall structure, especially with regard to security and incident notification.