DORA
Guide

DORA Incident Reporting 2026: 4h, 72h & 1-Month Deadlines for Major ICT Incidents

·13 min read
FR

FinancialRegulations.EU Team

Regulatory Intelligence

DORA
incident-reporting
cybersecurity
operational-resilience

Once you have classified an ICT-related incident as major under Article 18 of DORA, the reporting clock starts. The reporting framework under Chapter III of Regulation (EU) 2022/2554 requires three sequential reports to your National Competent Authority (NCA), each with a defined deadline and specific content requirements.

This guide sets out the reporting timeline, what each report must contain, where reports go, and what operational infrastructure you need in place before the next major incident.

The Three-Report Framework

ReportDeadlinePurpose
Initial Notification4 hours after classification as major (max 24 hours after detection)Alert the NCA that a major incident is underway; provide initial facts
Intermediate Report72 hours after the initial notificationUpdate on incident status, root cause analysis progress, containment measures, revised impact
Final Report1 month after the intermediate reportComplete post-incident analysis: root cause, total impact, remediation, lessons learned

The Trigger: Classification as "Major"

The reporting timeline begins when an incident is classified as major — not when the incident first occurs. This distinction matters for two reasons:

  1. Classification takes time: Gathering the facts needed to apply the seven criteria (client numbers affected, data loss confirmed, economic impact estimated) requires investigation. The 4-hour clock does not start from the moment a system first shows signs of disruption.

  2. But detection cannot be ignored: The 24-hour outer limit runs from the moment of detection, regardless of classification. If you detect an incident at 06:00 and classify it as major at 12:00, your initial notification must be submitted by 10:00 the following day at the very latest — and preferably by 16:00 (4 hours after classification at 12:00).

In practice: The 4-hour window after classification is tight. Financial entities should pre-configure their incident response procedures so that classification triggers an immediate escalation to the compliance/reporting function, with the initial notification submitted without further delay.

Need to check your DORA compliance?

Try free analysis

Report 1: Initial Notification

Deadline

Within 4 hours of classifying the incident as major, and no later than 24 hours after detection.

If classification happens close to the 24-hour detection mark (e.g., an incident is detected at 08:00 and classification is only confirmed at 22:00), the initial notification must be filed promptly after classification even if this is less than 4 hours after classification.

Required Content

The initial notification provides first-notice information only. The NCA does not expect complete facts at this stage. The notification must include:

  1. Identity of the reporting entity: LEI, NCA-registered identifier, legal name, home Member State
  2. Date and time of detection: When the entity first became aware of the incident
  3. Date and time of classification: When the incident was formally classified as major
  4. Nature of the incident: High-level description (cyberattack, system failure, third-party provider outage, human error, etc.)
  5. Classification criteria met: Which of the seven Article 18 criteria caused the incident to be classified as major (and why)
  6. Services and functions affected: Which critical or important functions are disrupted, and which services are unavailable to clients
  7. Immediate containment measures: What actions have been or are being taken to limit the spread or impact
  8. Estimated client impact: Approximate number of clients affected (if known)
  9. Cross-border impact: Whether other EU Member States are affected

What you are not expected to provide in the initial notification: root cause analysis, complete economic impact figures, final remediation plan. These come in subsequent reports.

Submission Channel

Reports are submitted to your home NCA through the channel specified by that authority:

NCAReporting channel
AFM (Netherlands)AFM incident reporting portal
BaFin (Germany)BaFin MELDEWESEN portal
CSSF (Luxembourg)CSSF eDesk / supervisory reporting system
CBI (Ireland)Central Bank ONR (Online Notification & Reporting) system
AMF (France)AMF Extranet

NCAs are required to forward major incident reports to the relevant European Supervisory Authority (EBA for banks and payment institutions, ESMA for investment firms and fund managers, EIOPA for insurance and pension funds) within 24 hours of receiving the initial notification.

For significant institutions supervised directly by the ECB, reports must also be submitted to the ECB (as joint supervisor with the national NCA) on the same timeline.

Practical Preparation

Before the next incident:

  • Identify and test access credentials for your NCA's reporting portal
  • Pre-populate static fields in the initial notification template (entity name, LEI, NCA contact)
  • Establish escalation triggers: who makes the decision to classify as major, and who submits the notification

Report 2: Intermediate Report

Deadline

Within 72 hours of the initial notification.

If you submitted the initial notification at 14:00 on Monday, the intermediate report is due by 14:00 on Thursday.

Required Content

The intermediate report provides an updated picture as the investigation progresses:

  1. Updated incident description: What is now known about the nature, cause, and scope
  2. Root cause analysis (preliminary): Initial assessment of the underlying cause — even if not yet confirmed. Indicate whether human error, technical failure, cyberattack, or third-party failure is suspected.
  3. Updated classification assessment: Confirm or revise which criteria were met, in light of information gathered since the initial notification
  4. Updated client impact: Revised figures on clients affected; whether impact has been contained or is still expanding
  5. Containment status: What containment measures have been implemented; have they succeeded?
  6. Recovery timeline: Estimated time to full service restoration (if known)
  7. Actions taken: Concrete steps taken since the initial notification — system isolation, failover activation, vendor engagement, forensic investigation initiation
  8. Cross-border coordination: If other Member States' NCAs have been notified (directly or via home NCA forwarding); whether relevant CERT has been engaged
  9. Communication to clients: Whether affected clients have been notified, and through what channel

At this stage, the investigation is typically ongoing. The intermediate report reflects the best available information, not the final picture. NCAs understand this; what they expect is good-faith, accurate reporting of what is known, and transparency about what is not yet confirmed.

If the Incident Is Resolved Before the Intermediate Report

If the major incident is fully resolved before the 72-hour intermediate report deadline, submit a combined intermediate and final report. Mark it as a combined submission and include all the content required for both stages.


Report 3: Final Report

Deadline

Within 1 month of the intermediate report.

This is the longest window — but the final report demands the most substance. By this stage, the incident investigation should be complete, root cause confirmed, and remediation measures implemented or scheduled.

Required Content

The final report is the definitive account of the incident:

  1. Complete incident timeline: From first signs of disruption to full restoration, with timestamps for key events
  2. Root cause determination: Confirmed root cause(s), not preliminary assessment. Was this a software vulnerability, misconfiguration, social engineering, third-party failure, or process breakdown?
  3. Full impact assessment:
    • Total number of clients affected (final figure)
    • Duration of service disruption (actual, not estimated)
    • Data losses confirmed (categories of data, number of records, regulatory consequences)
    • Direct financial losses (recovery costs, contractual penalties, compensation paid)
    • Indirect losses (revenue foregone, reputational impact, opportunity cost)
  4. Third-party involvement: If an ICT third-party service provider was involved, identify the provider (unless prohibited by confidentiality obligations), describe the provider's role, and set out what contractual and operational remediation steps have been taken
  5. Remediation measures: Specific technical and process changes implemented or committed to, with timelines for completion of outstanding actions
  6. Lessons learned: How the entity's ICT risk management framework, incident response procedures, or technical controls are being updated in response to this incident
  7. Regulatory consequences: Whether the incident has triggered any other reporting obligations (GDPR, NIS2, MiFID II transaction reporting, CRR reporting for credit institutions)
  8. Recurrence risk assessment: Assessment of the likelihood of recurrence and the steps taken to reduce that risk

Important: The final report is reviewed by the NCA as an indicator of the financial entity's overall ICT risk culture and management maturity. Superficial final reports — those that attribute incidents to "human error" without structural analysis or that propose no meaningful remediation — attract follow-up supervisory attention.


Voluntary Client Notification

DORA does not mandate client notification for every major incident. However, Article 19(4) states that financial entities should inform their clients of major incidents when the incident affects or may affect the financial interests of those clients.

The practical standard is: if a client cannot access their account, if their transaction has not settled, if their data has been exposed, or if their service is materially disrupted — notify them, promptly and clearly.

Client notifications are separate from NCA reports. The content and channel for client notifications are governed by the contractual relationship and the financial entity's client communications obligations (e.g., MiFID II client disclosure obligations for investment firms).


Reporting for the "Significant Cyber Threat" Category

As noted in our companion article on incident classification, DORA also creates a separate notification category for significant cyber threats that have not yet materialised into incidents.

For cyber threats:

  • Notification to the NCA is voluntary (not mandatory)
  • Notification to affected clients is required if the threat could affect their financial interests — this is mandatory once you assess the threat as significant and client-impacting
  • There are no fixed timelines, but "without undue delay" is the standard

Practical implication: Treat cyber threat notifications as a good-faith supervisory relationship tool. NCAs value early warning of credible threats, particularly those targeting multiple financial entities (e.g., a campaign against custody firms). Sharing threat intelligence builds supervisory goodwill and may result in useful threat intelligence in return.


Building Your DORA Incident Reporting Infrastructure

Complying with the DORA reporting timeline requires operational infrastructure that cannot be built at the time of the incident. The following components should be in place now:

Incident Response Runbook with Reporting Integration

Your incident response runbook must integrate reporting triggers at each classification milestone:

Incident detected
  → Incident response team activated
  → Initial triage and severity assessment
  → Classification assessment (7 criteria)
  → IF classified as MAJOR:
      → Compliance/CCO notified immediately
      → Initial notification preparation begins
      → NCA portal access credentials retrieved
      → Initial notification submitted within 4 hours
  → 72-hour calendar alert set for intermediate report
  → 1-month calendar alert set for final report

Pre-Approved Template Library

Draft templates for all three reports and obtain management approval in advance. Templates should include:

  • All static entity information (LEI, NCA contact, regulatory reference)
  • Structured sections matching NCA portal requirements
  • A checklist of required data elements for each stage
  • Named individuals responsible for drafting, reviewing, and submitting each report

NCA Portal Access and Testing

Test NCA portal access at least annually. Ensure:

  • Multiple nominated individuals have portal credentials (single-person dependency is an operational risk)
  • Portal login credentials are documented in a secure, accessible location (not only on the personal device of one IT staff member)
  • Test submissions (where NCAs offer sandbox/test environments) have been completed

Cross-Functional Escalation Chain

Incident reporting under DORA is not a purely technical matter. The compliance function (not the IT team) is responsible for the regulatory report. The escalation chain must be clear:

  1. IT/SOC: detects incident, assesses technical scope
  2. CISO / IT Risk: applies classification criteria, determines whether major
  3. Compliance / CCO: receives classification decision, triggers NCA notification, oversees report content
  4. Management Body: informed of major incidents promptly (Article 5 board responsibility); final report reviewed by board

NCA Communication Contact

Identify the named contact or reporting mailbox at your NCA. For most NCAs, this is published on the supervisory authority's website. Store this contact in a location accessible during a system outage (not solely in a digital system that may itself be affected by the incident).


Common Errors in DORA Incident Reporting

1. Starting the clock from incident occurrence rather than classification

The 4-hour window runs from classification as major, not from when the disruption first started. However, the 24-hour outer limit runs from detection. Do not over-engineer the classification process at the expense of triggering a late notification.

2. Treating the initial notification as a final report

The initial notification is explicitly a "heads-up" report. Compliance teams sometimes delay submitting the initial notification while waiting for confirmed root cause or complete client impact figures. This is wrong — submit the initial notification with what you know, flag what is uncertain, and update in the intermediate report.

3. Overlooking NIS2 and GDPR parallel obligations

A DORA major incident will often also be a NIS2 significant incident (for entities in scope of NIS2 — noting that financial entities are primarily subject to DORA as lex specialis) and a GDPR personal data breach. Each framework has its own reporting obligation with its own deadline. Map your incident response procedure to handle parallel reporting to multiple authorities where required. The same is true on the third-party side: an outage at a vendor recorded in your Article 28 register may simultaneously trigger DORA and NIS2 obligations depending on how the entity itself is classified.

4. Failing to notify clients when required

Article 19(4) requires client notification where financial interests may be affected. Fund managers who experience extended NAV disruption, settlement failures, or data exposure without notifying investors face both regulatory and contractual liability.

5. Treating incident reporting in isolation from third-party records

Many major ICT incidents originate at, or are amplified by, an ICT third-party provider. Final reports must identify provider involvement (where contractually permitted) and tie the incident back to the contractual arrangement. If your DORA register of information is incomplete or stale, your final report will struggle to map the incident accurately to the affected provider, contract, and supported critical or important function.

6. Final reports with no substantive lessons learned

A final report that concludes "we experienced a system failure, we restored it, no further action needed" will not satisfy DORA's intent. Regulators expect meaningful root cause analysis and concrete remediation measures. If the root cause was a misconfigured firewall rule — say so, and explain what process change prevents recurrence.


Primary Sources


Need to analyse specific DORA incident reporting and classification obligations? financialregulations.eu provides AI-powered answers grounded in the full DORA text, all published RTS and ITS on incident reporting, and NCA-specific guidance from AFM, BaFin, CSSF, and CBI.

Analyse Your DORA Obligations — Free →

Need to check your DORA compliance?

Try free analysis →
FR

FinancialRegulations.EU Team

Regulatory Intelligence

Expert analysis of EU financial regulation — covering MiCAR, DORA, AIFMD, SFDR, and 15+ regulatory frameworks across 7 jurisdictions.

Query DORA obligations instantly

AI-powered analysis of EU financial regulations. No credit card required.

Start Free →

Get EU regulatory insights in your inbox

Weekly updates on MiCAR, DORA, SFDR and more. Unsubscribe anytime.

Related Articles