DORA Major ICT Incident Classification: Criteria and Thresholds Explained

Article 18 of DORA (Regulation (EU) 2022/2554) requires financial entities to classify ICT-related incidents and determine their impact using a set of criteria. Commission Delegated Regulation (EU) 2024/1772 turns those criteria into measurable thresholds and a simple decision rule.

The decision rule

Under Article 8(1) of the Delegated Regulation, an incident is major when it has affected critical services and either:

• a successful, malicious and unauthorised access to network and information systems that may result in data losses has occurred (the threshold in Article 9(5)(b)); or
• two or more of the other materiality thresholds in Article 9(1) to (6) are met.

A common mistake: only point (b) of the data-losses criterion, a successful malicious unauthorised access, is enough on its own. An impact on data under point (a) counts as one of the other thresholds, so it needs a second threshold to make the incident major.

Step 1: Were critical services affected?

This is the gate. Under Article 6, the incident affects critical services if it:

• affects or has affected ICT services or network and information systems that support critical or important functions;
• affects or has affected financial services that require authorisation or registration, or that are supervised; or
• constitutes or has constituted a successful, malicious and unauthorised access to your network and information systems.

If none applies, the incident is not major, whatever its other effects. Record it anyway: DORA requires you to record all ICT-related incidents (Article 17(2)).

Step 2: Check the materiality thresholds

Where you cannot count exactly, the Delegated Regulation tells you to estimate, for example from comparable reference periods for clients and transactions (Article 9(1)). Duration runs from when the incident occurred until it is resolved; if you cannot tell when it occurred, from detection, or from the first trace in logs if you find it started earlier (Article 3(1)). Downtime runs from when the service becomes fully or partially unavailable until it is back to its previous level (Article 3(2)).

Recurring incidents

Incidents that are not major on their own count as one major incident when they occurred at least twice within 6 months, have the same apparent root cause, and together meet the major-incident test (Article 8(2)). You must check for recurring incidents monthly. This rule does not apply to microenterprises or to the entities listed in Article 16(1) of DORA.

Worked examples

These are illustrations of how the rule works. Your own classification depends on which functions you have identified as critical or important.

Once an incident is major

Report it to your competent authority under Article 19 of DORA. Delegated Regulation (EU) 2025/301 sets the deadlines:

• Initial notification: within 4 hours of classifying the incident as major, and no later than 24 hours after becoming aware of it. If you classify it as major only after those 24 hours, within 4 hours of the classification.
• Intermediate report: within 72 hours of the initial notification, with updates when regular activities are recovered.
• Final report: within one month of the latest intermediate report.

Where the incident affects clients' financial interests, you must also inform them without undue delay (Article 19(3) of DORA). See the full requirement list in our DORA compliance checklist.

Classify in minutes, not hours. The DORA Compliance Checklist pack includes an ICT incident classification matrix and notification timeline, plus a gap-assessment workbook, an ICT risk management framework template and a third-party provider register.

Sources

• Commission Delegated Regulation (EU) 2024/1772: classification of ICT-related incidents and materiality thresholds, EUR-Lex
• Commission Delegated Regulation (EU) 2025/301: content and time limits for major incident reports, EUR-Lex
• Regulation (EU) 2022/2554 (DORA), Articles 17 to 19, EUR-Lex

Related tools