DORA Major ICT Incident Reporting: 4-Hour, 72-Hour, and 1-Month Notification Requirements Explained

Why DORA incident reporting is operationally demanding

The DORA incident reporting regime is the most time-pressured compliance obligation in EU financial services law. The 4-hour initial notification for major ICT incidents is the strictest reporting timeline in the EU regulatory landscape — stricter than NIS2 (24 hours), GDPR (72 hours), and DORA's own intermediate and final report timelines. Miss the 4-hour window and you have a direct DORA breach, regardless of what happened in the incident itself.

This guide explains how to build a DORA-compliant incident reporting process that will actually work under real incident conditions.

Step 1: Major incident classification — what triggers the reporting clock

The reporting obligations only apply to major ICT-related incidents. The major incident classification criteria are specified in Commission Delegated Regulation (EU) 2024/1772. The thresholds vary by entity type, but for most financial entities the key criteria include:

Absolute classification triggers (any one = major incident)

Service duration — critical service unavailable for more than: 2 hours (payment services, trading venues, CCPs), 4 hours (credit institutions, investment firms), or 24 hours (insurance, UCITS/AIFMs)
Client impact — incident affects more than: 5,000 retail clients or 10% of professional clients (or lower thresholds for specific entity types)
Data integrity/confidentiality — loss, corruption, or unauthorised access to personal data or confidential financial data
Reputational impact — incident results in material media coverage, regulatory enquiries, or client complaints above NCA-defined thresholds
Economic impact — direct economic loss exceeding €100,000 (or total economic impact exceeding €500,000, including business disruption costs)
Geographic spread — incident affects financial market participants across two or more EU member states

Assessment methodology

Every ICT incident that is not immediately trivial must be formally assessed against the classification criteria. The assessment must be documented. Best practice: create an Incident Classification Record as a standard artefact that is completed for every ICT incident above a defined severity threshold. The record documents:

Incident ID and timestamp of first awareness
Incident description and affected systems
Assessment against each classification criterion (met/not met/uncertain)
Classification decision (major/not major/assessment ongoing) with timestamp
Assessor name and authority level
If major: 4-hour notification clock start time

If classification is uncertain at the time of initial assessment, DORA allows a 24-hour window to reach a classification decision — after which, the 4-hour notification clock starts. Entities should not use the 24-hour window as a buffer; if there is a reasonable basis to classify as major, notify.

Step 2: 4-hour initial notification

Once an incident is classified as major (or 24 hours have elapsed without classification), the entity must submit an initial notification to its NCA within 4 hours.

What must the 4-hour notification include?

The content requirements are specified in Commission Implementing Regulation (EU) 2024/2690 (the ITS on incident reporting templates). The initial notification must include:

Entity identification (name, LEI, entity type, NCA contact name)
Incident classification (major incident declaration + criteria met)
Incident description (brief, factual: what happened, when, how discovered)
Affected ICT systems and services
Estimated client impact (number of clients affected, services unavailable)
Actions taken so far (containment measures implemented)
Actions planned (immediate next steps)
Contact person for follow-up queries

The notification must be submitted through the NCA's designated channel. Most EU NCAs have established secure submission portals or email addresses for DORA notifications. Identify your NCA's submission channel now — do not wait for an actual incident to research this.

Managing the 4-hour clock

The 4-hour window sounds manageable. In practice, under real incident conditions, it is extremely demanding. Consider the timeline:

T+0: Incident detected by automated monitoring
T+15 min: Alert triaged by on-call engineer
T+30 min: CISO/incident commander engaged and incident declared
T+60 min: Initial classification assessment completed
T+90 min: Legal and compliance notified, notification decision made
T+120 min: Notification drafted, reviewed, and approved by management authority
T+150 min: Notification submitted to NCA

That leaves very little room for delays. The entities that successfully submit within 4 hours are those that have pre-approved notification templates, pre-identified NCA submission channels, and a clear escalation chain with named individuals who can approve and submit the notification without seeking additional sign-offs.

Step 3: 72-hour intermediate report

Within 72 hours of the initial notification, the entity must submit an intermediate report. This is a more detailed document providing an updated picture of the incident. Required content:

Updated incident description with timeline of events
Root cause hypothesis (or confirmed root cause if known)
Affected systems — confirmed list
Updated client impact assessment — confirmed numbers
Containment and mitigation measures applied
Services restored / still impacted
Regulatory and legal implications identified
Actions planned for full resolution
Updated contact details

A key challenge with the intermediate report: the entity is often still actively managing the incident when the 72-hour deadline arrives. This requires a parallel track — one team focused on incident resolution, another on producing the regulatory report. For smaller entities, this means the same people doing both, which is why pre-prepared templates are essential.

Step 4: 1-month final report

Within one month of submitting the intermediate report, the entity must submit a final report. This is the most detailed document and the one NCAs scrutinise most closely:

Confirmed root cause analysis (methodology and conclusions)
Full timeline of the incident from first indicators to resolution
Final confirmed impact (clients, services, economic, reputational)
Regulatory and legal consequences (if any)
Lessons learned — specific and actionable, not generic
Preventive measures implemented or planned with timelines
Assessment of whether ICT risk management framework adequately addressed the incident
Any changes to policies, procedures, or controls as a result

NCAs will compare final reports against initial and intermediate notifications for consistency. Material discrepancies between initial estimates and final impact figures are noted but generally accepted if explained. What NCAs criticise is superficial root cause analysis ('human error' without depth) and generic lessons learned ('we will improve monitoring') without specific actions.

NCA submission channels by country

For reference (verify directly with your NCA — channels may change):

Germany (BaFin) — DORA major incident reporting via BaFin's electronic reporting portal
France (ACPR) — via ACPR secure messaging system (SURFI)
Ireland (Central Bank) — via the Central Bank's regulatory reporting portal
Netherlands (DNB) — via DNB's supervisory reporting system
Luxembourg (CSSF) — via CSSF eDesk
Other EU NCAs — most have designated DORA email addresses published on their websites; check your home member state NCA's DORA page

Voluntary notification for significant cyber threats (Art. 19(2))

DORA Art. 19(2) allows (but does not require) financial entities to voluntarily notify their NCA when they become aware of a significant cyber threat — even if no incident has yet occurred. This is a valuable provision for entities that detect active attack campaigns, zero-day exploitation in their software stack, or intelligence suggesting imminent targeting.

Voluntary notifications are viewed positively by NCAs as evidence of a proactive security posture. They also give NCAs the opportunity to share threat intelligence across the sector, which benefits all entities.

Building a DORA-compliant incident reporting process

Seven components every entity needs:

Incident Classification Record template — with all major incident criteria pre-populated for assessment
4-hour notification template — pre-approved by legal and compliance, fillable in under 30 minutes
72-hour intermediate report template — with section headings and guidance notes
1-month final report template — including root cause analysis framework
NCA contact list — submission portal/email, contact name, phone number for urgent submissions
Escalation chain — who has authority to approve and submit each notification type, with backups for each role
Rehearsal schedule — at least annual tabletop exercise specifically testing the DORA reporting timeline

ComplyKit's DORA Technical Standards Compliance Checklist assesses your incident management and reporting capability against DORA Art. 11–19 requirements, alongside all other DORA pillars, and generates a scored compliance report with NCA-ready remediation guidance. Free, no account required.