Your payment platform goes down for 3 hours. Is it a major incident under DORA? Your cloud provider has a data breach affecting 50 client records. Do you need to notify the regulator within 4 hours?
These questions shouldn't require a committee meeting to answer. DORA Article 18 sets out exactly 7 criteria for classifying ICT-related incidents — but the materiality thresholds are buried across multiple RTS documents, and the decision logic isn't immediately obvious from reading the regulation alone.
Here's a clear breakdown of each criterion, the thresholds that matter, and a decision framework you can apply in minutes rather than hours.
The 7 Classification Criteria
DORA Article 18 requires financial entities to classify ICT-related incidents based on seven specific criteria. The Commission Delegated Regulation further defines the materiality thresholds for each. Here is what each criterion covers and where the thresholds sit:
Clients, Counterparts, and Transactions Affected
This criterion measures the breadth of impact on the people and entities who depend on your services. It covers direct clients, financial counterparts, and the volume of transactions disrupted.
Materiality Thresholds
- • ≥10% of all clients using the affected service
- • ≥30% of counterparts involved in the affected process
- • ≥100,000 clients affected in absolute terms
Duration and Service Downtime
How long the incident persists and how long services are unavailable or degraded. The thresholds differ based on whether the affected function is classified as critical.
Materiality Thresholds
- • >2 hours of downtime for critical or important functions
- • >24 hours of downtime for other (non-critical) functions
Geographical Spread
The geographic extent of the incident's impact, measured by how many EU Member States are affected. Cross-border incidents carry higher regulatory significance.
Materiality Threshold
- • Impact in >2 EU Member States
Data Losses
Any compromise to the availability, authenticity, integrity, or confidentiality of data. This is one of the most important criteria because certain types of data loss act as a standalone trigger for major classification.
What It Covers
- • Loss of data availability (data inaccessible)
- • Loss of data authenticity (data origin uncertain)
- • Loss of data integrity (data modified or corrupted)
- • Loss of data confidentiality (data exposed or exfiltrated)
Important: A breach of data integrity or confidentiality is a standalone major incident trigger — it does not need any other criterion to be exceeded.
Criticality of Services Affected
Whether the incident impacts services that the entity has identified as supporting critical or important functions. This is not just another criterion — it serves as a gateway.
Gateway criterion: If the incident does not affect services supporting critical or important functions, it cannot be classified as major regardless of how many other criteria are exceeded.
Economic Impact
The direct and indirect financial costs arising from the incident. This includes recovery costs, lost revenue, regulatory fines, contractual penalties, and any other financial consequences.
Assessment Approach
- • No fixed EUR threshold — assessed proportionally to the entity's size and revenue
- • Includes both direct costs (remediation, recovery) and indirect costs (lost business, reputational damage)
Reputational Impact
The extent to which the incident affects the entity's reputation. Unlike the other criteria, this is primarily a qualitative assessment.
Indicators to Consider
- • Media coverage (press, social media, industry publications)
- • Volume and severity of client complaints
- • Regulatory attention or inquiries triggered by the incident
When Does It Become "Major"?
Having seven criteria is one thing. Knowing how they combine to produce a classification decision is another. The decision logic is not simply "check all seven boxes." There is a specific hierarchy and combination logic that determines whether an incident crosses the major threshold.
Are critical or important services affected?
This is the gateway question. Check whether the incident impacts any service your entity has identified as supporting a critical or important function.
NO → Not a major incident
Stop here. Log internally, no regulatory notification required. The gateway criterion is not met.
YES → Continue to Step 2
Is there a data integrity or confidentiality breach?
Check whether the incident caused any compromise to the integrity or confidentiality of data. This includes unauthorized access, data exfiltration, or data corruption.
YES → MAJOR INCIDENT
Data integrity/confidentiality breach is a standalone trigger. Classify as major and begin notification process.
NO → Continue to Step 3
Do 2 or more other criteria exceed their thresholds?
Evaluate the remaining criteria — clients affected, duration, geographical spread, economic impact, and reputational impact. Count how many exceed their respective materiality thresholds.
YES (2+ exceeded) → MAJOR INCIDENT
Multiple thresholds breached with critical services affected. Classify as major and begin notification process.
NO (0-1 exceeded) → Not a major incident
Standard incident. Log it, investigate it, remediate it — but no regulatory notification required.
Reporting Timelines
Once an incident is classified as major, the clock starts ticking on three mandatory reports. The timelines are strict, and regulators expect classification to happen quickly — "without undue delay" in the regulatory language, which in practice means within hours of detection, not days.
Initial Notification — Within 4 Hours
Submit the initial notification to your competent authority within 4 hours of classifying the incident as major, and no later than 24 hours from detection of the incident. This report confirms the incident, provides initial details, and indicates the expected severity.
Intermediate Report — Within 72 Hours
Submit a more detailed report within 72 hours of the initial notification. This includes updated impact assessment, root cause analysis (if known), containment actions taken, and any changes to the classification criteria since the initial report.
Final Report — Within 1 Month
Submit the final report within 1 month of the incident. This is the comprehensive post-incident analysis including confirmed root cause, full impact assessment, remediation actions completed, and lessons learned.
The classification gap matters. Regulators expect you to classify incidents "without undue delay." If your internal process takes 48 hours to determine whether something is major, and then you start the 4-hour notification clock, you are already non-compliant. The expectation is that classification happens within hours of detection, not days.
Three Worked Examples
Theory is useful, but real-world scenarios are where classification decisions get tested. Here are three common situations and how they play out against the criteria:
Scenario A: Payment Gateway Down for 4 Hours
Your payment processing platform experiences a complete outage starting at 14:00. Service is restored at 18:00. During the outage, 35% of daily transactions could not be processed.
Result: MAJOR INCIDENT
Gateway criterion met (critical service). Two additional criteria exceeded (duration + clients affected). Classify as major and submit initial notification within 4 hours of classification.
Scenario B: Phishing Attack Compromises 3 Employee Mailboxes
An employee clicks a phishing link, and the attacker gains access to 3 corporate email accounts. The security team detects the compromise within 2 hours, resets credentials, and begins forensic investigation. No client-facing systems are affected.
Result: NOT A MAJOR INCIDENT
The gateway criterion is not met. Regardless of other factors, this cannot be classified as a major incident under DORA. Log the incident internally, conduct a thorough investigation, remediate, and document lessons learned. No regulatory notification required.
Scenario C: Cloud Provider Breach Exposes Client PII
Your cloud service provider notifies you that a vulnerability in their platform was exploited, and an unauthorized third party accessed a database containing personal data of 50 clients. The breach has been contained, but client data was exfiltrated.
Result: MAJOR INCIDENT
Gateway criterion met (critical service). Data confidentiality breach is a standalone major trigger — no need to check other criteria. Classify as major immediately and submit initial notification within 4 hours. Note: GDPR notification obligations likely apply in parallel.
Building Your Classification Process
Understanding the criteria and thresholds is the foundation. But classification only works if you can apply it consistently and quickly under pressure. When an incident hits at 02:00 on a Saturday, you need a process that anyone on the incident response team can follow without ambiguity.
Pre-define your critical services. The single most important preparatory step is maintaining an up-to-date register of which services support critical or important functions. This is the gateway criterion, and you cannot assess it during an incident if you haven't done the mapping beforehand. Revisit this mapping quarterly, and after any significant organizational or technology change.
Build a decision tree or scoring tool. Convert the three-step decision logic above into a structured tool — whether that's a spreadsheet calculator, a web form, or a laminated card next to the incident management procedure. The goal is to reduce classification from a judgment call to a data-driven process that takes minutes, not meetings.
Train your incident responders. Everyone who might be the first to handle an ICT incident needs to understand the 7 criteria, the gateway logic, and the reporting timelines. Run tabletop exercises that include the classification step. It's one thing to read about thresholds; it's another to apply them under the pressure of a live incident.
Document every classification decision. Whether the result is "major" or "not major," record the assessment against each criterion and the reasoning. This creates an audit trail that demonstrates due diligence to your regulator. If you classify something as not major and the regulator later disagrees, a well-documented decision process is your strongest defense.
The difference between a well-handled incident and a regulatory problem isn't whether incidents happen — every financial entity will face ICT incidents. It's whether you can classify and report them within the required timeframes. Build the process now, before you need it.