Key takeaways

• DORA incident classification runs through three stages: confirming an ICT incident occurred, assessing it against the six Article 18 criteria, and checking it against the RTS materiality thresholds.
• A major ICT-related incident requires an initial notification within roughly four hours of classification, and no later than 24 hours after the organization becomes aware of it.
• The first ESAs report on major ICT-related incidents recorded 3,383 cases for 2025, with about a third carrying a cross-border impact.
• A classification policy, an asset map linking critical functions to ICT systems, a documented reporting procedure, ready templates, and tabletop tests determine whether a bank can meet DORA’s reporting windows when an incident happens.

A financial institution has roughly four hours to tell its regulator that something has gone seriously wrong, from the moment of classifying the incident as major. That is the operational reality DORA has created for banks, insurers, and financial market infrastructures across the EU. The first report from the European Supervisory Authorities on major ICT-related incidents already shows the scale of the challenge: 3,383 major incidents were recorded for 2025, and about a third of them had an impact reaching across borders. For a Head of Engineering or Head of Compliance, the practical question has shifted. Incidents will happen. The question is whether the organization can classify correctly and report on time, under pressure, with incomplete information.

This guide walks through how DORA defines a major ICT-related incident, what the three-stage reporting timeline requires, what is realistic to prepare within the first four hours, how to build the internal process before an incident occurs, and where organizations most often lose time or get the classification wrong.

How DORA classifies a major ICT incident

DORA moves away from the simple, single-line severity matrices many organizations used before. In place of the familiar Severity 1, 2, 3 model sits a multidimensional assessment of whether an event qualifies as a major ICT-related incident subject to mandatory reporting.

Classification runs through three stages. First, identification: has an ICT incident occurred? Second, qualification: how does the event score against the six criteria set out in Article 18 of DORA? Third, quantification: does the event cross the specific materiality thresholds defined in the Commission Delegated Regulation (EU) 2024/1772, the regulatory technical standard on the classification of ICT-related incidents and cyber threats.

The six Article 18 criteria cover distinct dimensions of impact. Clients, financial counterparts, and transactions capture how many people or entities were affected. Duration and service downtime measure how long the incident lasted and how long the service was fully or partially unavailable. Geographical spread distinguishes an incident contained to one country from one touching clients, branches, group entities, or ICT providers across multiple member states. Data loss covers any breach of availability, authenticity, integrity, or confidentiality of data, including client and counterpart data. Criticality of services asks whether the incident affects ICT systems supporting critical or important functions, regulated financial services, or involves successful, malicious, unauthorized access. Economic impact totals the direct and indirect costs: lost funds, recovery expenses, overtime, legal and forensic advisory, compensation, lost revenue, communication costs, and any contractual penalties. Reputational impact sits inside the first criterion and should be assessed through concrete signals such as media coverage, client complaints, regulatory attention, or the risk of losing significant clients or counterparts, rather than on intuition alone.

Crossing a single quantitative threshold rarely decides the outcome on its own. Under the RTS, an incident becomes major when it affects a critical or important function and meets one of two scenarios: it crosses the threshold for data loss or for successful, malicious, unauthorized access to network and information systems that could lead to data loss, or it crosses at least two other materiality thresholds. The main thresholds are affected clients above 10% of those using the service or above 100,000 in absolute terms, financial counterparts above 30% of those active on the affected service, transactions above 10% of the average daily number or value, incident duration beyond 24 hours, service downtime beyond 2 hours for critical or important functions, geographical impact reaching at least two EU member states, and economic losses exceeding or likely to exceed EUR 100,000.

An incident that looks small on the surface, touching a limited group of clients, can still be classified as major if it hits a critical function and combines two or more of these thresholds, for example a meaningful downtime alongside cross-border reach or a data loss.

The operational recommendation is simple to describe and demanding to build in practice: a dedicated classification worksheet, a DORA calculator in practice, that does more than tally thresholds. Its real job is creating an audit trail recording the exact time of detection and classification, the data sources used, the estimates applied, and the person who made the call. That record serves as the evidence of due diligence a supervisor will look for when reviewing how the decision was made under time pressure.

When must you notify the competent authority under DORA?

Reporting a major ICT incident under DORA happens in three stages: the initial notification, the intermediate report, and the final report. This structure comes from Article 19(4) of DORA, with exact deadlines defined in the Commission Delegated Regulation (EU) 2025/301.

The initial notification must go out as soon as possible after classification, generally within four hours of classifying the incident as major and no later than 24 hours from becoming aware of it. At this stage the organization shares the basics: what happened, when it was detected and classified, which DORA criteria were met, the preliminary scope of impact, and who is handling communication with the authority.

The intermediate report follows no later than 72 hours after the initial notification was submitted. Any material update, particularly once regular operations are restored, should be shared without undue delay. This stage fills in the picture: affected services and processes, impact on clients or transactions, mitigation actions taken, and, where relevant, indicators of compromise and the role of any ICT provider involved.

The final report is due no later than one month after the intermediate report, or after its last update. This is where the fuller picture belongs: root cause analysis, verified impact, costs and losses, remediation actions, and measures to prevent recurrence.

The operating principle behind all three stages is that compliance begins before a complete root cause analysis is available. The first submission is meant to be fast and reliable, built on the best information available at that moment.

What the DORA initial notification requires and what is realistic in four hours

The most common mistake in DORA incident reporting is expecting the first submission to read like a full post-incident report. The initial notification answers three questions: what do we know right now, why was this classified as major, and what actions have already started. It covers the basic facts: a description of the event, the detection and classification timestamps, the preliminary scope of impact, which DORA criteria were triggered, the status of affected services, whether business continuity or disaster recovery plans were activated, and the contact point for the authority.

Within the first four hours, estimates are realistic and a complete picture will come later. The organization should be able to name which services or processes are affected, whether a critical or important function is involved, and an approximate view of the impact on clients, transactions, or data, while flagging which figures still need confirmation. A complete forensic analysis, a finished root cause investigation, a final valuation of losses, or a conclusive legal and regulatory assessment are all beyond what this stage requires.

The intermediate report tightens that operational picture. It confirms or corrects earlier estimates, identifies the affected infrastructure components, describes mitigation actions, reports on service restoration status, and covers the impact on clients or their financial interests, along with indicators of compromise and any ICT provider’s role where relevant.

The final report is the stage of full closure. It carries verified data on the scale of the incident, confirmed costs and losses, the root cause, corrective and preventive actions, and the resulting conclusions for ICT risk management. The initial notification conveys what is known and what is being done. The intermediate report shows how the situation is developing. The final report explains what caused it, what the impact was, and what is changing as a result.

How to build the internal process before an incident happens

The process for collecting, classifying, and submitting DORA incident reports has to be built before an incident, not during one. The starting point is a single shared procedure spanning SOC and IT, security, business continuity, compliance, legal, communications, business owners, and vendor management, with the goal of gathering data quickly, classifying the incident, and documenting every decision along the way.

Five practical building blocks make that possible.

1. Classification policy. Translates the six Article 18 criteria and the RTS thresholds into clear internal rules, specifying precisely who decides when an incident is major and when.

2. Asset mapping. Links critical and important functions to the specific ICT services, systems, providers, and business owners behind them. Without that map it is difficult under time pressure to judge whether an outage touches a critical service and what its real impact is.

3. Reporting procedure. Defines the steps for the three-stage submission process and assigns clear ownership for counting affected clients, downtime, costs, and cross-border impact.

4. Ready templates and named roles. Covers report forms, client communications, and designated contacts for the supervisory authority and their backups, supported by a classification log that records why and on what data each status decision was based.

5. Tabletop tests. Simulate a major incident scenario. A procedure on paper alone leaves the organization unable to confirm that the team can pull together scattered data from IT, the business, and vendors within the required window and produce a credible first report.

The CrowdStrike outage of July 2024 is a useful reference point. It was an incident at a technology provider rather than a failure of an organization’s own systems, and it illustrated how much weight falls on communication channels with external parties, recovery procedures that are ready to use, and testing severe-but-plausible scenarios before a real crisis arrives.

For providers supporting critical or important functions, contracts must specify in advance the obligation to report anomalies immediately, response times and escalation channels operating around the clock, cooperation in analysis and remediation, and access to the logs and technical information needed for classification and reporting. The financial institution conducts its own classification based on data received from the provider and should proceed with notification without waiting for the provider’s final, complete explanation.

Where the dependency is significant, a joint incident bridge is good practice: a shared, secured operational channel activated during a crisis, allowing IT, security, compliance, legal, and business teams at the institution to work directly alongside the provider’s engineers. Both sides operate from a single timeline, a single version of the facts, and a consistent dataset for reporting purposes.

The most common mistakes in DORA incident reporting

DORA applies from January 17, 2025, which makes it more accurate to describe the operational risks organizations run into during implementation than to point at an established pattern of supervisory findings. The topic is grounded in data, though. The first ESAs report on major ICT-related incidents for 2025 recorded 3,383 cases, roughly a third of them with cross-border impact, and that scale underlines how much classification quality and operational readiness matter in practice.

Five risks show up across implementations.

1. Late classification. Teams wait for full confirmation of the facts instead of reporting on the best available data and estimates, which can be corrected afterward.

2. Siloed process. DORA reporting gets treated as a compliance task rather than as part of incident response, so the report gets built alongside the real crisis instead of being fed in real time by SOC, IT, business continuity, and process owners.

3. One-dimensional assessment. Focusing on a single threshold such as downtime without checking it in parallel against affected clients, transactions, economic impact, or cross-border reach produces a misclassification.

4. Missing audit trail. No formal record of when the organization became aware of the incident, when it was classified, and who made that call on what data. This is one of the first elements a supervisor will check.

5. Vendor dependency. Incomplete or delayed data from ICT service providers, particularly for cloud, cybersecurity, or payment system incidents, puts the classification timeline at risk.

The CrowdStrike outage illustrates why several of these risks tend to appear together: a vendor-driven incident tests classification speed, cross-team coordination, and third-party data dependency all at once.

FAQ

What counts as a major ICT-related incident under DORA?

An incident becomes major when it affects an ICT service supporting a critical or important function and either crosses the threshold for data loss or unauthorized access with potential data loss, or crosses at least two other materiality thresholds, such as client numbers, downtime, transaction volume, or economic impact defined in the RTS.

How much time do you have to send the initial DORA notification?

The initial notification is generally due within four hours of classifying an incident as major, and no later than 24 hours from the moment the organization becomes aware of it. This timeline is set by Article 19(4) of DORA and detailed in the Commission Delegated Regulation (EU) 2025/301.

What should the initial notification include?

It should describe what happened, when the incident was detected and classified, which DORA criteria were triggered, the preliminary scope of impact, the status of affected services, whether BCP or DR plans were activated, and the contact point for the authority. A complete forensic analysis is beyond what this stage requires.

When is the intermediate report due, and what does it add?

The intermediate report is due no later than 72 hours after the initial notification. It confirms or corrects earlier estimates and adds detail on affected infrastructure, mitigation actions, service restoration status, client impact, and, where relevant, indicators of compromise and the ICT provider’s role.

Why do organizations misclassify DORA incidents?

Misclassification usually comes from assessing only one threshold, such as downtime, without checking it against the other five Article 18 criteria in parallel. An incident with limited visible impact can still qualify as major if it touches a critical function and crosses two or more materiality thresholds at once.

Does DORA incident reporting apply when the root cause sits with an ICT provider?

Yes, and the regulatory responsibility stays with the financial institution throughout. Under DORA, a financial entity may delegate certain reporting-related tasks to its ICT provider, but it remains accountable to the supervisor for the timeliness, completeness, and accuracy of every submission. The institution conducts its own classification based on data received from the provider and should proceed with notification without waiting for the provider’s final, complete explanation.