guide

ICT Incident Reporting Under DORA: The Complete Timeline and Requirements

DORA Atlas EditorialMarch 21, 202611 min read

The Four-Hour Clock

Imagine this scenario: at 14:32 on a Thursday, your security operations center detects anomalous database activity on a system supporting your core banking platform. By 15:15, the scope is clear — unauthorized queries have exposed account balance data for approximately 11,000 retail customers across three EU member states. The system is isolated by 15:40.

Under DORA, your clock started at 14:32. You have until approximately 18:32 — four hours — to submit an initial incident notification to your national competent authority. Not a full analysis. Not a root cause determination. But a structured notification using a prescribed template, with enough information for the supervisor to assess systemic relevance and determine whether the incident requires cross-border coordination.

This is the reality of DORA's Pillar II: ICT-related incident management, classification, and reporting. It replaces the patchwork of national incident reporting regimes with a harmonized EU framework that is simultaneously more prescriptive and more demanding than any prior requirement.

Art. 3(8) defines an ICT-related incident as "a single event or a series of linked events unplanned by the financial entity that compromises the security of the network and information systems, and have an adverse impact on the availability, authenticity, integrity or confidentiality of data, or on the services provided by the financial entity."

The definition is intentionally broad. It captures:

Cyberattacks (ransomware, DDoS, data exfiltration, advanced persistent threats)
System failures (database corruption, application crashes, infrastructure outages)
Third-party service disruptions (cloud provider incidents, payment network failures)
Human errors with ICT impact (misconfigurations, accidental data deletion, failed deployments)
Natural events affecting ICT (power outages, facility damage affecting data centers)

Critically, the definition includes events that affect confidentiality — a data breach is an ICT-related incident under DORA even if no service disruption occurs.

Classification: The Seven Criteria of Article 18

Not every ICT-related incident triggers a reporting obligation. Art. 18(1) establishes classification criteria for determining whether an incident qualifies as "major" — and only major incidents must be reported. The European Supervisory Authorities have further specified these criteria in Regulatory Technical Standards (RTS), but the regulation itself defines seven assessment dimensions:

1. Number of clients affected (Art. 18(1)(a)). How many clients, financial counterparts, and transactions are impacted? The RTS define thresholds based on entity type and size — a systemically important institution will have lower absolute thresholds than a smaller entity, reflecting the principle that broader impact has greater supervisory relevance.

2. Duration of the incident (Art. 18(1)(a)). How long did the incident affect service availability, integrity, or confidentiality? Both the outage duration and the time to full resolution are relevant. An incident lasting two hours may be minor; one lasting two days almost certainly qualifies as major.

3. Geographic spread (Art. 18(1)(a)). Does the incident affect multiple member states? Cross-border incidents have inherently higher supervisory significance due to coordination requirements between national authorities.

4. Data losses (Art. 18(1)(b)). Is data availability, authenticity, integrity, or confidentiality compromised? The nature and sensitivity of affected data matters — loss of personal financial data is assessed differently from loss of non-sensitive operational data.

5. Criticality of services affected (Art. 18(1)(c)). Does the incident affect critical or important functions as defined in Art. 3(22)? An incident affecting your core banking platform is assessed differently from one affecting a non-critical internal tool.

6. Economic impact (Art. 18(1)(d)). What are the direct and indirect financial costs? Direct costs include incident response, recovery, and regulatory penalties. Indirect costs include customer compensation, reputational damage, and business opportunity loss.

7. Cross-border impact. Does the incident have implications for financial stability or other financial entities? Incidents with potential systemic effects trigger heightened supervisory attention.

An incident meeting the threshold on any single criterion — or through a combination of criteria at lower individual levels — can be classified as major. The assessment is not a simple checklist; it requires judgment informed by the RTS thresholds and the entity's own business impact analysis.

The Three Reporting Phases

Once an ICT-related incident is classified as major, Art. 19 activates a three-phase reporting obligation:

Phase 1: Initial Notification (Within 4 Hours)

Art. 19(4)(a) requires an initial notification to the competent authority "without undue delay, and in any case within 4 hours from the moment the ICT-related incident has been classified as a major ICT-related incident." The four-hour clock starts at classification, not at detection — but the RTS expect classification to occur promptly after detection, typically within hours.

The initial notification contains:

Basic identification (entity, contact person, date/time of detection)
Preliminary classification against Art. 18 criteria
Description of the incident and affected services
Preliminary impact assessment (number of clients affected, geographic scope)
Status of containment and initial response measures
Indication of whether the incident is ongoing or resolved

This is not a root cause analysis. It is a structured early warning designed to enable supervisory coordination. The four-hour window exists because regulators need to assess systemic risk quickly — an incident affecting one bank's payment processing may indicate a broader infrastructure issue affecting multiple institutions.

Phase 2: Intermediate Report (Within 72 Hours)

Art. 19(4)(b) requires an intermediate report within 72 hours of the initial notification (or within 72 hours of classification, where the initial notification was submitted within the four-hour window). The intermediate report substantially expands on the initial notification:

Updated impact assessment with quantified data (exact client count, transaction volumes affected, financial impact estimate)
Technical description of the incident, including attack vectors or failure modes identified
Containment and recovery actions taken
Current status of service restoration
Updated classification assessment (the incident may have escalated or de-escalated)
Communication actions taken (customer notification, market disclosure)
Whether the incident has cross-border implications

If the incident is still ongoing at the 72-hour mark, the intermediate report should reflect the current state and indicate expected resolution timelines.

Phase 3: Final Report (Within 1 Month)

Art. 19(4)(c) requires a final report within one month of the intermediate report submission. This is the comprehensive post-incident analysis:

Complete root cause analysis (technical, procedural, and organizational causes)
Full impact quantification (clients, transactions, financial losses, data compromised)
Complete timeline from detection through resolution
Detailed remediation measures implemented and planned
Lessons learned and changes to the ICT risk management framework (linking back to Art. 6 and Art. 13)
Assessment of whether the incident revealed systemic weaknesses
Updates to business continuity plans and recovery capabilities if applicable

The final report is not a formality. Art. 13 specifically requires that lessons from ICT incidents feed back into the entity's risk management framework, business continuity plans, and training programmes. Supervisors will examine whether final report findings resulted in concrete remediation — not just documented lessons.

The Reporting Flow: Who Receives What

DORA creates a centralized reporting architecture that channels information from entities to national supervisors to EU-level authorities:

Financial Entity
    │
    ▼ (Initial + Intermediate + Final)
National Competent Authority (NCA)
    │
    ├─▶ ECB (for significant institutions under SSM)
    │
    ▼ (Aggregated intelligence)
Relevant ESA ([EBA](https://www.eba.europa.eu/) / ESMA / EIOPA)
    │
    ▼ (Cross-sector analysis)
EU Systemic Risk Board / ENISA

Art. 19(6) empowers the competent authority to request additional information or clarification after receiving any report. Art. 19(7) allows the ESAs to access incident reports to perform aggregate cross-border analysis.

Art. 21 establishes a centralized EU reporting hub. The hub, managed by the relevant ESA, enables automated routing of incident reports and facilitates cross-border coordination. Financial entities report to their NCA; the NCA channels to the hub; the hub enables EU-wide visibility. The practical implementation timeline for the hub has been phased, with initial capabilities focusing on standardized data exchange formats.

Art. 23 adds a specific layer for payment service providers and electronic money institutions. Payment-related incidents — those affecting payment services — are already subject to the PSD2 incident reporting regime. DORA Art. 23 harmonizes these requirements:

Payment-related major ICT incidents must be reported under DORA's framework
The competent authority forwards relevant details to the EBA and ECB
Payment service users must be notified "without undue delay" when the incident has or is likely to have an impact on their financial interests (Art. 23(2))
The notification must include "all appropriate measures" that users can take to mitigate adverse effects

For payment institutions, this means a single reporting pathway replaces the fragmented PSD2 incident reporting landscape — but with the added obligation of the four-hour initial notification timeline.

Voluntary Cyber Threat Notification: Article 19(2)

Beyond mandatory major incident reporting, Art. 19(2) encourages financial entities to voluntarily notify their competent authority of significant cyber threats — even when those threats have not yet materialized into an incident. This is distinct from mandatory reporting: it is a threat intelligence sharing mechanism designed to enable early warning across the sector.

Voluntary notifications are:

Non-binding (no penalty for non-submission)
Anonymized when shared with other entities or authorities (Art. 19(3))
Protected from use in enforcement proceedings against the submitting entity

The practical value is significant. A bank detecting reconnaissance activity targeting a specific vulnerability in a widely-used banking platform can notify the NCA, which can alert other institutions — potentially preventing the threat from becoming a major incident elsewhere.

Building the Operational Workflow

Theory aside, the four-hour initial notification requirement demands an operational workflow that activates automatically when an incident is detected. Manual processes — email chains to assemble impact data, spreadsheet-based classification, Word document report drafting — cannot reliably produce a structured notification within four hours, especially when the incident itself is consuming operational attention.

A DORA-compliant incident reporting workflow requires:

1. Automated classification triage. When an incident is detected, immediately assess against Art. 18 criteria. This requires pre-mapped data: which services are critical (from your Art. 11 BIA), which customer segments are affected (from your service catalog), and what data classifications apply (from your asset register). Without these pre-mapped dependencies, the classification exercise alone can consume the entire four-hour window.

2. Structured report generation. The initial notification follows the RTS template. Pre-populating entity identification, contact details, and affected service descriptions — rather than drafting from scratch under pressure — saves critical time.

3. Parallel containment and reporting. The incident response team focuses on containment. A separate reporting function, activated by classification, focuses on the regulatory notification. These are parallel workstreams, not sequential.

4. Escalation and governance. Major incident classification should automatically trigger notification to senior management, the management body (per Art. 5 board accountability), legal, communications, and the compliance officer responsible for regulatory reporting.

5. Evidence chain. Every step — detection, triage, classification decision, notification submission, containment action, recovery step — must produce a timestamped, attributed record. The final report requires a complete timeline, and supervisors will expect the evidence to be contemporaneous, not reconstructed retrospectively.

6. Lessons learned integration. The final report is not the end of the lifecycle. Art. 13 requires post-incident reviews that feed back into the ICT risk management framework. Remediation actions identified in the final report should be tracked as deviations with corrective action plans, deadlines, and verification — creating a closed loop from incident to improvement.

Purpose-built operational resilience platforms such as Valendir that integrate incident lifecycle management with asset registries, BIA data, and regulatory reporting templates can compress this workflow from hours of manual coordination into structured, evidence-rich submissions that satisfy both the letter and the spirit of DORA's reporting requirements.

The Supervisory Perspective

NCAs are not collecting incident reports as a filing exercise. They use them for three purposes:

Systemic risk assessment. Aggregate incident data reveals patterns — common attack vectors, vulnerable infrastructure, correlated failures — that inform supervisory priorities and macro-prudential oversight.

Proportionality calibration. An entity's incident history influences the NCA's assessment of its operational resilience maturity and the intensity of future supervisory engagement.

Cross-border coordination. Incidents affecting multiple member states trigger coordination between NCAs, the ESAs, and potentially the ECB under the SSM. The initial notification timeline exists because coordination takes time, and delayed notification delays protective action.

The quality of your incident reports — not just their timeliness — shapes the supervisory relationship. Reports that demonstrate structured classification, thorough impact analysis, genuine root cause investigation, and concrete remediation build supervisory confidence. Reports that read as pro forma compliance exercises invite deeper examination.

This guide reflects DORA Regulation (EU) 2022/2554 and associated RTS/ITS as applicable in Q1 2026. Readers should consult their NCA's implementation guidance for jurisdiction-specific reporting procedures and submission channels.