The Digital Operational Resilience Act (DORA) requires financial entities to establish structured processes for identifying, classifying, documenting, and reporting major ICT-related incidents. Meeting these obligations requires more than responding to incidents as they occur. 

 

Organizations need clearly defined reporting procedures, governance processes, evidence collection mechanisms, and coordination between security, compliance, and operational teams.

 

The importance of effective incident reporting is reflected in the first annual overview published by the European Supervisory Authorities (EBA, EIOPA, and ESMA). Based on incident reports submitted under DORA, financial entities reported 3,383 major ICT-related incidents across the EU, with approximately one-third having a cross-border impact. 

 

The findings highlight how interconnected financial services have become and why regulators are placing greater emphasis on timely and consistent incident reporting.

 

This guide explains the DORA incident reporting requirements, reporting timelines, and practical steps financial institutions can take to build an effective reporting process.

 

 

Which ICT incidents must be reported under DORA?

 

Not every ICT-related incident triggers a reporting obligation under DORA. Financial entities are required to report incidents that meet the criteria for a major ICT-related incident.

 

Determining whether an incident is reportable requires a structured assessment of its impact. Organizations should evaluate factors such as the number of affected clients, the duration of the disruption, the services impacted, financial losses, data exposure, and potential reputational consequences.

 

This assessment should not be performed for the first time during an active incident. Financial institutions should establish documented classification criteria in advance so response teams can consistently determine whether reporting obligations apply.

 

Here’s how you can classify incidents for assessment:

 

Classification criterion	What should be assessed?	Example
Service disruption	Whether the incident affects critical or important services and the extent of the disruption.	An outage prevents customers from accessing online banking or payment services.
Affected clients and transactions	The number of customers, users, or financial transactions impacted by the incident.	A system failure disrupts a significant volume of customer transactions.
Data impact	Whether personal, financial, or other sensitive information has been exposed, altered, or lost.	Unauthorized access to customer account information.
Duration of the incident	How long critical services remain unavailable or degraded.	Core systems remain inaccessible for several hours or longer than established recovery objectives.
Economic and operational impact	The financial losses, operational disruption, or resource burden resulting from the incident.	A cyberattack causes business interruption and requires significant recovery efforts.
Cross-border impact	Whether the incident affects customers, services, or operations in multiple jurisdictions.	An outage impacts services provided across several EU member states.

 

You should assess these factors collectively rather than in isolation. An incident may not appear significant when viewed through a single criterion, but a combination of service disruption, customer impact, and operational consequences may elevate it to the level of a major ICT-related incident.

 

To streamline decision-making during an active incident, establish an internal classification framework aligned with DORA’s criteria. This helps security, risk, and compliance teams consistently determine whether reporting obligations apply and ensures major incidents are escalated without delay.

 

Understanding the DORA incident reporting timeline

 

One of the most challenging aspects of DORA compliance is meeting the reporting deadlines while an incident is still unfolding. Organizations need a repeatable process that allows information to be gathered, reviewed, approved, and submitted quickly.

 

1. Initial notification

 

Once an ICT-related incident has been classified as major, the reporting process begins.

 

The initial notification must be submitted within 4 hours of classifying the incident as major and no later than 24 hours after becoming aware of it.

 

At this stage, organizations are not expected to have a complete understanding of the event. The purpose of the initial notification is to alert regulators to a significant incident and to provide available information on its nature, impact, and current status.

 

To meet this deadline, establish predefined escalation procedures, reporting contacts, and approval workflows before an incident occurs.

 

2. Intermediate report

 

As investigations progress, organizations are expected to provide additional information through an intermediate report. This report should include updated details regarding the scope of the incident, affected services, root cause analysis activities, containment measures, and recovery efforts.

 

The intermediate report must generally be submitted within 72 hours of the initial notification. If new information becomes available, additional updates may be required to ensure regulators maintain visibility into the situation.

 

Because investigations are often ongoing at this stage, maintain accurate records and ensure incident information is continuously updated throughout the response process.

 

 

3. Final report

 

The final report provides a complete account of the incident after recovery activities are complete and investigations conclude. This report should include the confirmed root cause, the full impact of the incident, remediation measures implemented, lessons learned, and any long-term corrective actions designed to prevent recurrence.

 

The final report must be submitted within one month after the intermediate report. For many organizations, this report is among the most valuable outputs of the incident response process because it demonstrates accountability and provides evidence of continuous improvement.

 

How to build a DORA-compliant incident reporting process

 

DORA incident reporting deadlines leave little room for ad-hoc decision-making. To meet regulatory requirements, you need a documented process. The following steps can help you build a reporting process that supports both compliance and operational resilience.

 

Quick link: DORA reglementation: What financial businesses need to know

 

1. Establish incident classification criteria

 

Document how your organization will determine whether an ICT-related incident qualifies as a major incident under DORA. Map DORA’s classification criteria to your business services, systems, and operational thresholds. For example, define which levels of service disruption, customer impact, transaction failure, or data exposure require escalation for compliance review.

 

Create a classification matrix that incident responders can use during an active incident. This eliminates guesswork and helps teams make consistent reporting decisions under pressure.

 

2. Define reporting roles and responsibilities

 

Identify who is responsible for each stage of the reporting process. Security teams assess the technical aspects of the incident, while compliance teams evaluate reporting obligations and prepare regulatory submissions. Legal teams may review disclosures, and executive stakeholders may need to approve reports before submission.

 

Document these responsibilities and escalation paths in advance. During an incident, teams should not be deciding who owns the reporting process.

 

3. Create incident reporting procedures

 

Document the exact steps teams must follow once an incident is identified. Your procedure should cover:

 

• How incidents are reported internally.
• When incidents must be escalated.
• Who performs the DORA classification assessment.
• Who prepares regulatory reports.
• Who reviews and approves submissions.
• How updates are communicated as investigations progress.

 

The procedure should align with the reporting timelines established under DORA and be accessible to all relevant stakeholders.

 

4. Standardize incident documentation

 

Use a consistent incident record for every significant event. Capture information such as:

 

• Date and time of detection.
• Systems and services affected.
• Incident timeline.
• Actions taken.
• Customer impact.
• Regulatory decisions.
• Recovery activities.

 

Collecting this information from the start makes it easier to prepare initial, intermediate, and final reports without scrambling to reconstruct events later.

 

5. Integrate reporting into incident response activities

 

Treat reporting as part of the incident response plan rather than a separate compliance task. As soon as an incident is escalated, begin documenting impact assessments, investigation findings, response actions, and recovery updates. Waiting until the reporting deadline approaches often results in incomplete information and unnecessary delays.

 

Integrate DORA incident reporting activities into existing incident response workflows to ensure information remains accurate throughout the investigation.

 

6. Maintain evidence and decision records

 

Keep records of how incidents were classified, who participated in reporting decisions, what information was submitted, and which corrective actions were implemented.

 

Store investigation records, communications, approvals, and remediation plans in a central location. Regulators may ask organizations to demonstrate how reporting decisions were made and what actions were taken after the incident.

 

7. Test the reporting process

 

Run tabletop exercises that require teams to classify an incident, determine whether reporting obligations apply, prepare an initial notification, and meet DORA incident reporting deadlines.

 

Include security, compliance, legal, and operational stakeholders in these exercises. Testing helps identify gaps in escalation procedures, reporting workflows, and approval processes before a real incident occurs.

 

How CyberArrow supports DORA incident reporting

 

Managing incident reporting through emails, spreadsheets, and disconnected systems can make it difficult to maintain visibility, accountability, and regulatory readiness.

 

CyberArrow helps financial institutions strengthen DORA compliance by enabling organizations to:

 

• Centralize incident reporting workflows.
• Track regulatory reporting obligations and deadlines.
• Maintain evidence and audit trails.
• Document incident investigations and corrective actions.
• Manage risk assessments and remediation activities.
• Generate real-time dashboards and compliance reports.
• Improve collaboration across security, compliance, and risk teams.

 

CyberArrow helps organizations establish a more structured and defensible approach to DORA incident reporting by centralizing governance, risk, and compliance activities.

 

 

FAQs