How to Classify a Major ICT-Related Incident Under DORA

Every DORA reporting deadline, the 4-hour initial notification, the 72-hour intermediate report, the one-month final report, depends on one prior decision: Is this incident "major"?

Get that classification wrong (or take too long to reach it) and the reporting clock is already running out before anyone has picked up a template. Article 18 of DORA, backed by the binding RTS on classification (Commission Delegated Regulation 2024/1772), sets out exactly how that decision has to be made, and it's a two-step test, not a gut call.

How to Classify a Major ICT-Related Incident Under DORA: The Complete Criteria Checklist

DORA doesn't require financial entities to report every ICT-related incident to their competent authority, It requires them to correctly identify which incidents are "major" and report only those, within deadlines that start counting the moment classification happens. That makes classification the single highest-stakes judgment call in the entire DORA incident response process. Get it wrong in one direction and you miss a legally binding deadline; get it wrong in the other and you flood your regulator with noise that erodes the credibility of every future report.

Article 18 of DORA and its supporting Regulatory Technical Standard set out a structured, two-step test for making that call, not a subjective severity score.

The Six Criteria Under Article 18(1)

The EU DORA requires financial entities to classify ICT-related incidents and determine their impact against six defined criteria:

1. Clients, financial counterparts and transactions affected: The number and/or relevance of clients or financial counterparts affected, the amount or number of transactions affected, and whether the incident has caused reputational impact.
2. Duration and service downtime: How long the incident lasted, including the length of any service outage.
3. Geographical spread: The areas affected, with particular significance if the incident affects more than two EU Member States.
4. Data losses: Impact on the availability, authenticity, integrity or confidentiality of data.
5. Criticality of the services affected: Including the effect on the financial entity's own transactions and operations.
6. Economic impact: The direct and indirect costs and losses caused by the incident, in both absolute and relative terms.

Where any of these can't be determined with certainty in the moment, the entity is expected to make a reasonable estimate using the information available, rather than delaying classification until every figure is confirmed.

The Two-Step Test That Actually Decides "Major"

This is the part most summaries skip, and it's the part that actually matters operationally. The RTS on classification doesn't just hand you six criteria and ask you to eyeball severity. It defines a specific decision sequence:

Step 1: Did the incident affect a critical or important function? If the incident had no impact on the financial entity's critical services, it cannot be classified as major, regardless of how it scores on the other criteria. This is the gating question that has to be answered first.

Step 2: Does it meet either of two conditions? If critical services were affected, the incident is classified as major if either of the following is true:

• It involved successful, malicious, unauthorised access to network and information systems that may result in data losses, or
• It has had a material impact on two or more of the six criteria listed above, based on the specific materiality thresholds set out in the RTS for each one.

In other words, critical-service impact is the entry condition, and then either a confirmed malicious breach with data-loss potential, or material impact registering on at least two separate criteria, is what pushes an incident over the "major" line. An incident affecting critical services but registering material impact on only one criterion does not automatically qualify. This is precisely the kind of edge case a documented classification procedure needs to resolve consistently, rather than leaving it to whoever is on call that day.

Why the Criteria Interact, Not Just Add Up

A few practical implications fall out of how these criteria are defined:

• Reputational impact is folded into the clients/transactions criterion, not treated as a standalone factor. It's assessed by how much market attention the incident receives, alongside client and transaction numbers.
• Geographical spread specifically flags the two-Member-State threshold. An incident contained within a single country is assessed differently from one crossing into a second EU jurisdiction, which has direct implications for which competent authorities need to be notified.
• Data loss is assessed across four separate dimensions: Availability, authenticity, integrity and confidentiality. This means an incident that merely delays access to data (availability) is evaluated differently from one where data was exfiltrated (confidentiality).
• Economic impact is measured two ways — in absolute terms and relative to the entity's scale. So a cost that would be trivial for a systemically important bank might clear a materiality threshold for a smaller investment firm.

Why This Has to Be a Documented Procedure, Not a Judgment Call

The reason classification criteria show up as one of DORA's mandatory documented artefacts isn't bureaucratic box-ticking. It's that the 4-hour initial notification clock starts running from the moment of classification, and 24 hours from the moment of detection if classification takes too long. A team debating from first principles whether an incident meets "material impact on two or more criteria" while the clock runs has already lost most of the window it needs to notify correctly.

This is exactly the artefact the DORA Incident Response Document Library treats as one of the 15 mandatory documents DORA makes non-negotiable — profiled across 22 fields covering purpose, owner, approver, the specific DORA article, RTS or ITS it maps to, lifecycle stage and dependencies, so the classification procedure exists as a pre-built, rehearsed decision tool rather than something drafted under pressure.

Keeping the Classification Procedure Current

Materiality thresholds, regulatory guidance and an entity's own risk profile all shift over time — a classification procedure written once at DORA go-live and never revisited will drift out of alignment with the RTS it's supposed to implement. The DORA Master Document Register for ICT Incident Response tracks exactly this kind of artefact against its DORA/RTS/ITS mapping, owner, approver, review frequency and current status in one Excel-ready sheet, so a classification procedure has a named owner and a scheduled review date instead of sitting untouched until the next incident exposes that it's stale.

Common Classification Mistakes

• Skipping the critical-services gate. Teams sometimes jump straight to scoring the six criteria without first confirming the incident touched a critical or important function — the RTS makes this the mandatory first question, not an optional filter.
• Treating "material impact on one criterion" as sufficient. Absent a confirmed malicious breach, the RTS requires material impact on two or more criteria — a single high-scoring criterion alone doesn't clear the bar.
• Confusing detection time with classification time. The clock references both — 4 hours from classification, and no later than 24 hours from detection — so delaying classification doesn't buy extra time against the outer 24-hour limit.
• No documented thresholds per criterion. The RTS sets specific materiality thresholds for each of the six criteria; a procedure that leaves "material" undefined forces a subjective call during the exact moment consistency matters most.
• Forgetting the geographical-spread trigger for cross-border notification. An incident crossing into a second Member State changes which competent authorities need visibility, a detail easy to miss when the team is focused on severity alone.

Getting Started

1. Confirm your classification procedure covers both steps of the RTS test explicitly — the critical-services gate and the two-condition threshold — not just a generic severity scale.
2. Document materiality thresholds per criterion in advance, using the RTS definitions, so classification during a live incident is a lookup rather than a debate.
3. Benchmark your classification artefact against the full mandatory set in the DORA Incident Response Document Library to confirm it's built to the same 22-field standard as DORA's other mandatory documents.
4. Assign an owner and review cadence to the classification procedure in the DORA Master Document Register, so it's revisited as thresholds and guidance evolve.
5. Rehearse the decision, not just the paperwork. A tabletop exercise that runs the team through an ambiguous, borderline incident surfaces gaps in the classification logic that a document review alone won't catch.

Key Terms

• Major ICT-Related Incident: An ICT-related incident classified as major under DORA Article 18, triggering the initial notification, intermediate report and final report obligations.
• Materiality Threshold: The specific quantitative or qualitative bar set in the RTS for each classification criterion, above which impact on that criterion is considered material.
• Critical or Important Function: A function whose disruption would materially impair a financial entity's performance, or its soundness or continuity, and the gating factor in the RTS's classification test.
• Regulatory Technical Standard (RTS) on Classification: Commission Delegated Regulation (EU) 2024/1772, which sets out the detailed criteria and materiality thresholds for classifying ICT-related incidents and significant cyber threats under DORA Article 18.
• Significant Cyber Threat: A cyber threat classified under Article 18(2) based on the criticality of services at risk, clients or counterparts targeted, and geographical spread, distinct from an incident that has already occurred.
• Classification Criteria: The six factors set out in Article 18(1) — clients/transactions affected, duration/downtime, geographical spread, data losses, criticality of services, and economic impact.

Frequently Asked Questions

1. What criteria determine whether an ICT-related incident is "major" under DORA?

Article 18(1) sets out six criteria: clients, financial counterparts and transactions affected (including reputational impact); duration and service downtime; geographical spread; data losses; criticality of the services affected; and economic impact.

2. What is the two-step test for classifying a major incident?

First, the incident must have affected a critical or important function — if not, it cannot be classified as major. Second, if critical services were affected, the incident is major if it involved successful, malicious, unauthorised access to systems that may result in data losses, or if it had a material impact on two or more of the six criteria.

3. Is a single high-impact criterion enough to classify an incident as major?

Not on its own, unless it involves confirmed malicious unauthorised access with potential data loss. Absent that, the RTS requires material impact on at least two of the six criteria before an incident qualifies as major.

4. When does the DORA reporting clock start for a major incident?

The initial notification is due within 4 hours of classifying the incident as major, and no later than 24 hours from becoming aware of it — so a delayed classification decision does not extend the outer 24-hour limit.

5. What happens if an incident affects services that aren't critical or important?

It cannot be classified as major under the RTS test, regardless of how it scores on the other five criteria, since critical or important function impact is the mandatory first gate in the classification sequence.

6. Why does geographical spread matter in DORA's classification criteria?

Geographical spread specifically flags incidents affecting more than two EU Member States, which has direct implications for which competent authorities across jurisdictions need to be notified of the incident.

7. Should classification criteria be a written, pre-approved document rather than a live judgment call?

Yes. Because the reporting clock starts at classification, a pre-documented procedure with defined materiality thresholds per criterion allows a fast, consistent decision during an incident, rather than a first-principles debate that erodes the 4-hour and 24-hour windows.

8. How does DORA's incident classification differ for cyber threats versus incidents that have already occurred?

Article 18(2) classifies cyber threats as "significant" based on the criticality of services at risk, the number or relevance of clients or counterparts targeted, and geographical spread — assessed before the threat materialises, whereas incident classification under Article 18(1) assesses actual impact after the fact.