guide

DORA Incident Classification: The 4-Hour Clock Starts Now

DORA Atlas EditorialAugust 13, 202510 min read

The Reporting Timeline That Changes Everything

Before DORA, ICT incident reporting in European financial services was a patchwork. The ECB's SSM cyber incident reporting framework required notification "within 2 hours" for significant incidents — but only for banks under direct ECB supervision. PSD2 mandated "without undue delay" for major operational and security incidents affecting payment services. National frameworks varied further: BaFin in Germany required "immediate" notification; the CSSF in Luxembourg specified "without delay and within 4 hours."

DORA replaces this patchwork with a unified, cross-sector framework that applies to all 22,000 in-scope financial entities — from global systemically important banks to 30-person payment institutions. The reporting timeline is precise, mandatory, and unforgiving.

The Three-Phase Reporting Timeline

Figure 1: DORA's three-phase incident reporting timeline. The 4-hour initial notification window is the most operationally demanding constraint.

Phase	Deadline	Content Required	Who Must Report
Initial notification	4 hours after classification; max 24 hours after detection	Nature of incident, affected services, initial impact assessment, remediation actions underway	All entities for major incidents
Intermediate report	72 hours from initial notification	Updated impact assessment, root cause analysis (preliminary), recovery timeline, customer communication summary, quantified impact	All entities for major incidents
Final report	1 month from incident	Complete root cause analysis, full quantified impact, remediation completed, lessons learned, framework changes implemented	All entities for major incidents

The 4-hour clock is the critical constraint. From the moment an incident is classified as "major" under the RTS criteria, the institution has 4 hours to prepare and submit an initial notification to its NCA. The 24-hour backstop ensures that classification delays cannot be used to extend the timeline indefinitely — if an incident is detected but not yet classified, the initial notification is due within 24 hours of detection regardless.

For institutions without automated classification capabilities, this timeline is operationally brutal. During a live incident — when the SOC is triaging, engineering is firefighting, and management is demanding updates — diverting resources to prepare a regulatory notification within 4 hours requires pre-planned templates, pre-authorized submission workflows, and pre-defined classification criteria that minimize human judgment under pressure.

The Classification Decision Tree

DORA Article 18 establishes the classification criteria. The associated RTS (Commission Delegated Regulation) specifies the thresholds. The classification determination is binary: an incident is either "major" (triggering mandatory reporting) or not.

Primary Classification Criteria

An ICT-related incident is classified as major if it meets the thresholds for two or more of the following criteria:

Criterion	Threshold for "Major"	Measurement Guidance
Clients affected	> 10% of clients using the affected service, or > 100,000 clients in absolute terms	Unique clients impacted, not transactions; includes indirect impact through downstream services
Transactions affected	> 10% of average daily transaction volume, or > specified monetary threshold	Total transactions that failed, were delayed, or were processed incorrectly
Duration	> 2 hours for critical/important functions	Wall-clock time from detection to full restoration of normal service
Geographic spread	Impact in > 2 EU member states	Where affected clients are located, not where systems are hosted
Data loss	Any loss of availability, authenticity, integrity, or confidentiality of data	Includes both actual data loss and confirmed unauthorized access
Economic impact	Direct and indirect costs exceeding specified threshold	Recovery costs, regulatory costs, customer compensation, lost revenue, reputational damage
Critical function impact	Affects a critical or important function (Art. 3(22))	As identified in the entity's own business impact analysis

Automatic Major Classification Triggers

Certain incidents are automatically classified as major regardless of whether they meet two criteria:

Successful malicious unauthorized access to the entity's network or information systems (regardless of data exfiltration)
Data breaches involving confidential or restricted data of any volume
Core banking/payment system downtime exceeding 4 hours
Complete unavailability of all customer-facing digital channels

The Classification Workflow

Figure 2: Incident classification decision flow. Automatic triggers bypass the two-criteria threshold and immediately classify the incident as major.

Minute 0-15: Detection. Automated monitoring detects service degradation, security alert, or system failure. SOC validates the alert and confirms a genuine incident.

Minute 15-60: Initial triage. Incident response team assesses scope: which services are affected, how many customers are impacted, what is the geographic spread. This is assessment, not investigation — the goal is to determine whether classification criteria are likely met, not to identify root cause.

Minute 60-120: Classification decision. Based on triage data, the incident commander applies the classification criteria. If two or more major thresholds are met, or an automatic trigger is present, the incident is classified as major. The 4-hour reporting clock starts at the moment of classification.

Minute 120-360 (4-hour deadline): Initial notification. The pre-authorized regulatory reporting function prepares and submits the initial notification using pre-drafted templates populated with triage data. The notification includes: incident identifier, affected entity, date/time of detection, date/time of classification, nature and type of incident, affected services, initial impact assessment, and remediation actions underway.

What Goes in Each Report

Initial Notification (Hour 4)

The initial notification is intentionally lightweight — the regulator understands that detailed information is not available 4 hours into an incident. The goal is awareness, not analysis.

Required elements:

Entity identification (LEI, name, NCA reference)
Incident date/time (detection and classification)
Incident type (e.g., system outage, cyber attack, data breach, third-party failure)
Affected services and functions (list)
Initial impact estimate (clients affected, geographic scope)
Classification criteria met (which two or more thresholds triggered)
Immediate actions taken and underway
Expected next update timeline

Common mistakes in initial notifications:

Waiting for root cause before submitting (the 4-hour clock does not pause for investigation)
Over-specifying impact (initial estimates are expected to be approximate; revisions are normal in intermediate reports)
Omitting affected function classification (critical vs. important matters for supervisory response)

Intermediate Report (Hour 72)

The intermediate report provides the NCA with a substantive understanding of the incident. By 72 hours, the institution should have a preliminary root cause, quantified impact, and credible recovery timeline.

Required elements:

Updated incident description with root cause analysis (preliminary)
Quantified impact: number of clients affected, transactions impacted, financial loss estimate
Geographic scope confirmation
Recovery actions completed and timeline for remaining actions
Customer communication summary (what customers were told, when, through which channels)
Third-party involvement (if the root cause is a third-party provider failure)
Risk assessment: likelihood of recurrence, residual risk, compensating controls

Final Report (Month 1)

The final report is the definitive regulatory record. It must be comprehensive, evidence-based, and forward-looking.

Required elements:

Complete root cause analysis with causal chain
Full quantified impact (direct costs, indirect costs, customer compensation, regulatory costs)
Complete timeline from detection to full resolution
All remediation actions taken, with evidence
Framework changes: what was changed in ICT risk management, business continuity, or third-party governance as a result
Lessons learned: what worked, what failed, what will be done differently
Testing plan: how the remediation will be validated (links to Pillar III resilience testing)

The Operational Reality: Why Most Institutions Fail the 4-Hour Test

Industry assessments consistently show that the majority of financial institutions cannot reliably meet the 4-hour initial notification deadline. The reasons are structural, not incidental.

Common Failure Points

Failure Point	Root Cause	Mitigation
Detection delay	Monitoring gaps; alert fatigue; no 24/7 SOC coverage	Invest in automated anomaly detection; reduce alert noise; consider managed SOC
Classification ambiguity	Criteria require judgment; thresholds not pre-operationalized	Pre-calculate client/transaction thresholds; build automated classification scoring
Approval bottleneck	NCA notification requires senior approval; approvers unavailable out-of-hours	Pre-authorize incident commander to submit initial notifications; implement delegation chains
Template unavailability	Reporting templates not pre-drafted; staff unfamiliar with NCA portal	Maintain pre-populated templates; conduct quarterly reporting drills
Data unavailability	Client count, transaction volume, geographic scope not queryable in real time	Build real-time impact dashboards; pre-calculate baselines for threshold comparison
Coordination overhead	Incident response, customer communication, and regulatory reporting compete for the same staff	Separate regulatory reporting function from incident response; designate specific reporter role

The Reporting Drill: Practice Before You Need It

The most effective mitigation for reporting timeline failures is practice. Quarterly reporting drills — where the incident response team simulates a major incident and completes the full reporting cycle against the actual timeline — expose gaps in process, tooling, and staffing before a real incident does.

Drill structure:

Inject a realistic incident scenario at an unannounced time
Measure: time to detect, time to classify, time to prepare initial notification
Review: template completeness, data accuracy, approval chain speed
Debrief: identify bottlenecks and implement corrections before next drill

Institutions that conduct quarterly drills consistently meet the 4-hour deadline. Institutions that rely on documented procedures without practice consistently do not.

Significant vs. Major: The Notification Threshold

Not every ICT incident requires NCA reporting. DORA distinguishes between "major" incidents (mandatory reporting) and incidents that, while significant internally, do not meet the classification threshold.

However, DORA Article 17(3) requires financial entities to record all ICT-related incidents, not just major ones. The internal incident register must capture every incident regardless of classification, including near-misses and minor disruptions. This register serves two purposes: it provides the data for trend analysis (Art. 17(3)), and it creates the audit trail that demonstrates the classification decision was properly made.

Near-miss reporting — incidents that did not meet major thresholds but came close — is increasingly expected by NCAs. An incident that affected 9.5% of clients (just below the 10% threshold) is a near-miss that should trigger internal review and potentially proactive supervisory discussion, even though it does not trigger mandatory reporting.

Cross-Border Incidents: The Multi-NCA Problem

For financial entities operating across multiple EU member states, a major incident may require notification to multiple NCAs simultaneously. Art. 19(6) addresses this by requiring the ESAs and NCAs to coordinate, but the operational burden falls on the institution.

Practical approach:

Identify the "home" NCA (where the entity is authorized) as the primary notification recipient
Determine whether the incident's geographic scope triggers notification obligations in host member states
Use standardized reporting templates to ensure consistency across NCA submissions
Maintain a contact list for all relevant NCA incident reporting desks, including out-of-hours contacts

Building a Reporting-Ready Organization

Figure 3: A reporting-ready organization separates incident response from regulatory reporting as parallel tracks, supported by pre-incident preparation and validated through quarterly drills.

The institutions that meet DORA's incident reporting deadlines are those that treat reporting as an operational capability, not a compliance exercise.

Pre-classify your services. For each critical and important function, pre-calculate the client count and transaction volume thresholds that would trigger major classification. When an incident occurs, the classification question becomes "does this incident's scope exceed the pre-calculated threshold?" rather than "how many clients does this service have?"

Automate detection-to-classification. Build monitoring rules that automatically flag incidents approaching major classification thresholds. An automated alert that says "this incident currently affects 8% of clients on Service X (threshold: 10%)" enables proactive classification before thresholds are breached.

Pre-draft and pre-authorize. Maintain pre-populated notification templates for each critical service. Pre-authorize the incident commander (or designated regulatory reporting lead) to submit initial notifications without additional approval. The 4-hour window does not accommodate multi-level approval chains.

Invest in real-time impact assessment. The biggest bottleneck in the 4-hour workflow is not drafting the notification — it is determining the impact. Institutions with real-time dashboards showing client counts, transaction volumes, and geographic scope per service can classify and report faster than institutions that must query multiple systems to assemble this data.

Separate reporting from response. The incident response team's job is to fix the problem. The regulatory reporting function's job is to notify the NCA. These should be parallel tracks, not sequential. Designate a specific individual or team whose role during an incident is exclusively regulatory reporting.

The 4-hour clock does not care about your organizational structure. It does not wait for your CISO to wake up, for your legal team to review the notification, or for your board to be briefed. It starts when the classification criteria are met, and it ends 4 hours later. The institutions that are ready for it are those that prepared before the clock started. For the broader incident reporting timeline, see our complete reporting timeline guide. The EBA and ESMA have published RTS/ITS specifying exact classification thresholds and notification formats.

This guide reflects DORA Regulation (EU) 2022/2554 Articles 17-23 and associated RTS on incident classification and reporting. Classification thresholds are based on published RTS; institutions should verify current thresholds with their NCA.