DORA Incident Classification: The 7 Criteria That Determine Whether an Incident Is 'Major'

The Digital Operational Resilience Act — DORA, Regulation (EU) 2022/2554 — has applied since 17 January 2025. One of the most operationally demanding requirements is the ICT-related incident reporting regime under Chapter III. Before any report goes to your National Competent Authority, you must first classify the incident correctly.

This guide explains the seven classification criteria from Article 18 of DORA and the joint RTS on incident classification, sets out the materiality thresholds that determine whether an incident is "major," and provides a decision framework that compliance and IT teams can use before the next incident occurs.

Why Classification Comes Before Reporting

DORA distinguishes between two categories of ICT-related incidents:

Category	Reporting Obligation	Timeline
Major ICT-related incident	Mandatory report to NCA (initial, intermediate, final)	4h / 72h / 1 month
Significant cyber threat	Voluntary notification to NCA; client notification if threat could affect them	Prompt
All other ICT-related incidents	Log internally; analyse as part of annual risk review	No external reporting

Misclassifying a major incident as non-major is a supervisory failure. Under-reporting has attracted enforcement attention from NCAs across the EU in analogous frameworks (NIS, PSD2, GDPR). Over-reporting (treating minor incidents as major) creates unnecessary regulatory burden and may trigger supervisory inquiries.

The classification decision must be made promptly — the initial notification must be submitted within 4 hours of an incident being classified as major (and no later than 24 hours after detection). There is no time for prolonged committee deliberation once classification is complete.

The 7 Classification Criteria Under Article 18

Article 18 of DORA requires financial entities to classify ICT-related incidents based on seven criteria. The Joint RTS on incident classification (developed jointly by EBA, ESMA, and EIOPA) specifies the quantitative and qualitative thresholds for each criterion.

An incident is major if it meets the materiality thresholds for 2 or more of the seven criteria.

Criterion 1: Clients and Financial Counterparties Affected

What it measures: The breadth of client impact — how many clients or financial counterparties are unable to access services or have their data affected.

Major threshold:

• More than 10% of all clients who use the disrupted service are affected; OR
• More than 500 clients in absolute numbers are affected

Practical notes:

• "Clients" includes both retail and professional clients. Count all clients who use the disrupted function, not all clients of the firm.
• If you provide a single service to 200 clients and all 200 are affected, the 500-client absolute threshold is not met — but check whether 200 represents ≥10% of your client base for that service.
• Counterparties in settlement or clearing chains count alongside end clients.

Examples:

• A NAV calculation system outage affecting 1,200 investors in a fund → Criterion 1 threshold met (>500 clients)
• An order management system failure affecting 45 of your 600 institutional clients → Criterion 1 threshold met (45/600 = 7.5%, below 10%; and below 500 absolute — threshold NOT met on this criterion)

---

Criterion 2: Geographic Spread

What it measures: Whether the incident affects operations or clients across multiple EU Member States or critical infrastructure.

Major threshold:

• The incident affects the financial entity's operations or clients in more than one EU Member State; OR
• The disruption affects critical financial infrastructure that spans Member States

Practical notes:

• This criterion is particularly relevant for cross-border firms — pan-European custodians, investment managers with multi-jurisdiction operations, or UCITS distribution platforms.
• A purely local incident (e.g., a data centre outage affecting only UK operations post-Brexit) may not trigger this criterion even if it is operationally significant.
• Geographic spread is assessed by where the affected clients and operations are located, not where the financial entity is headquartered.

Examples:

• A trading system outage affecting clients in Germany, France, and the Netherlands simultaneously → Criterion 2 threshold met
• A local office network failure in Amsterdam affecting only Dutch-based staff → Criterion 2 threshold NOT met

---

Criterion 3: Data Losses

What it measures: Whether the incident causes or risks causing a breach of confidentiality, integrity, authenticity, or availability of data.

Major threshold:

• Breach of confidentiality of personal or commercially sensitive data; OR
• Breach of integrity of data (corruption, unauthorized modification); OR
• Breach of authenticity of data (inability to verify data origin); OR
• Extended loss of availability of data necessary for critical functions

Practical notes:

• This criterion does not have a purely quantitative threshold — it is qualitative. Any confirmed breach of data confidentiality (even affecting a single client's data) will meet the threshold.
• Availability loss is assessed in combination with Criterion 4 (duration) and Criterion 5 (criticality of services).
• Under GDPR, a personal data breach may trigger separate notification obligations to data protection authorities (DPAs) within 72 hours — DORA's incident reporting to NCAs runs in parallel, not as a substitute.

Examples:

• Unauthorized access to client portfolio data extracted by a threat actor → Criterion 3 threshold met (confidentiality breach)
• A ransomware attack that encrypts trade records and prevents access for 3 hours → Criterion 3 potentially met (availability loss + potential integrity concern)
• A brief network connectivity outage with no data access or exfiltration → Criterion 3 threshold NOT met

---

Criterion 4: Criticality of Services Affected

What it measures: Whether the disrupted services are "critical or important" functions of the financial entity.

Major threshold:

• The incident disrupts a function designated as critical or important under the financial entity's ICT risk management framework (Article 6 of DORA); AND
• The disruption affects the financial entity's ability to provide those functions

Practical notes:

• Each financial entity must have identified its critical and important functions as part of its ICT risk management framework. If this mapping has not been completed, Criterion 4 cannot be properly applied.
• Critical functions for fund managers typically include: NAV calculation, order processing, portfolio management systems, investor reporting, regulatory reporting, fund accounting, and transfer agency.
• A disruption to a non-critical function (e.g., an internal HR system) does not meet this criterion even if operationally disruptive.

Examples:

• A fund accounting platform outage that prevents NAV publication → Criterion 4 threshold met (NAV calculation is a critical function)
• A disruption to the internal ticketing system used by IT support → Criterion 4 threshold NOT met (not a critical or important financial function)

---

Criterion 5: Duration

What it measures: How long the incident lasts.

Major threshold:

• The incident lasts more than 24 hours for services other than payment services; OR
• The incident lasts more than 2 hours for payment services or settlement services

Practical notes:

• Duration is measured from the start of the disruption (when the service first became unavailable or impaired) to full restoration.
• A recurring incident — where a system is disrupted, partially restored, and disrupted again — counts as a single incident if the underlying cause is the same.
• Partial service restoration (e.g., the system is up but processing at reduced capacity or with data quality concerns) does not stop the duration clock.

Examples:

• A core banking system outage from 09:00 to 13:30 (4.5 hours) affecting retail payment processing → Criterion 5 threshold met (>2 hours for payment services)
• A fund transfer system disruption from Monday afternoon to Wednesday morning (>24 hours) → Criterion 5 threshold met
• A 45-minute data feed interruption that is fully resolved with no data loss → Criterion 5 threshold NOT met

---

Criterion 6: Economic Impact

What it measures: The direct and indirect financial losses attributable to the incident.

Major threshold:

• Direct costs attributable to the incident exceed EUR 100,000; OR
• Total costs (including opportunity costs and reputational damage estimates) exceed EUR 500,000

Practical notes:

• Direct costs include: recovery expenses (external IT support, forensics, legal), regulatory fines, contractual penalties, and compensation paid to affected clients.
• Opportunity costs may include: revenue foregone due to inability to execute trades, penalties for missed settlement, increased borrowing costs.
• At the time of classification, the full economic impact may be unknown — use a reasonable estimate based on available information. You can revise the assessment in the intermediate and final reports.
• For small financial entities, these thresholds may be proportionate to annual revenue. The proportionality principle in Article 4 of DORA does not eliminate the reporting obligation, but may affect how NCAs assess the materiality of borderline cases.

Examples:

• A cyberattack requiring EUR 150,000 in forensic recovery costs → Criterion 6 threshold met (direct costs >EUR 100,000)
• A brief outage causing EUR 20,000 in client compensation → Criterion 6 threshold NOT met on direct cost basis; check indirect costs

Note on third-party-driven incidents: Where the disruption originates at an ICT third-party provider, the entries in your DORA register of information (specifically RT.04 contractual data and RT.02 function mapping) are the fastest way to scope economic impact across affected functions.

---

Criterion 7: Reputational Impact

What it measures: Whether the incident has or is likely to have a material reputational impact on the financial entity.

Major threshold:

• The incident has led to or is likely to lead to significant media coverage; OR
• The incident has led to or is likely to lead to regulatory scrutiny or supervisory inquiries outside the incident reporting itself; OR
• The incident has materially damaged the financial entity's reputation with clients or counterparties

Practical notes:

• This is the most subjective of the seven criteria. It requires judgment at the time of classification about likely reputational consequences.
• "Significant media coverage" means coverage in national or trade press that identifies the financial entity by name and links it to an ICT failure — not general industry commentary.
• Supervisory inquiries specifically triggered by the incident (from the NCA, EBA, ESMA, or EIOPA) count; routine supervisory contact does not.

Examples:

• A major custody bank's core system outage reported in the Financial Times → Criterion 7 threshold met
• An incident at a small AIFM known to a narrow audience with no press coverage expected → Criterion 7 threshold NOT met unless clients or counterparties escalate

---

The Classification Decision Framework

Apply the seven criteria in sequence as soon as you detect an ICT-related incident. An incident is major if 2 or more criteria are met at their defined thresholds.

ICT-related incident detected
         │
         ▼
Does the incident affect a critical or important function? (Criterion 4)
  If NO → lower likelihood of major; continue assessment
  If YES → one criterion met; continue checking for a second
         │
         ▼
Assess the remaining 6 criteria:
  1. Clients affected: >10% or >500 absolute?
  2. Geographic spread: >1 EU Member State?
  3. Data losses: confidentiality/integrity/authenticity breach?
  5. Duration: >24h (or >2h for payments)?
  6. Economic impact: direct >EUR 100k or total >EUR 500k?
  7. Reputational impact: significant media/regulatory attention?
         │
         ▼
≥ 2 criteria met?
  YES → Classify as MAJOR ICT-related incident → Initiate reporting procedure
   NO → Log as non-major incident; monitor for escalation

The "Significant Cyber Threat" — A Separate Category

Article 19 of DORA introduces a separate concept: the significant cyber threat. This is not an incident that has materialised, but a threat with the potential to become one.

Financial entities that detect a significant cyber threat must:

1. Notify their competent authority promptly (no fixed timeline, but "without undue delay")
2. Notify affected clients if the threat could affect their financial interests

What constitutes a "significant" threat is not defined with the same precision as the incident criteria, but the RTS provides guidance: a threat is significant if it has the technical characteristics to cause material disruption to critical functions or data loss, even if not yet exploited.

Practical implication: A credible, targeted phishing campaign against your key operational staff, or evidence of active reconnaissance against your trading infrastructure, may require NCA notification even before any disruption occurs. Do not treat threat intelligence as purely an internal IT matter.

Preparing for Classification Before the Next Incident

The classification decision under Article 18 must be made under time pressure. Compliance and operational resilience teams should prepare the following before any incident occurs:

1. Map Critical and Important Functions

Criterion 4 requires you to have identified your critical and important functions in advance. This mapping must be documented in your ICT risk management framework (Article 6). Without it, you cannot apply Criterion 4 correctly. The same critical/important function (CIF) flag drives the ICT third-party register guide's RT.02 template — keep both artefacts in sync.

2. Establish Client Population Baselines

To apply Criterion 1, you need to know your client population for each critical service. Prepare a table showing: service name, number of clients using the service, and the 10% threshold (i.e., 10% of the client population for that service).

3. Pre-Define Classification Thresholds in Your Incident Response Procedure

Incorporate the seven criteria and their thresholds directly into your incident response procedure or runbook. When an incident is detected, the on-call team should be able to run through the criteria checklist without referring to the RTS text.

4. Identify the Reporting Contact for Each NCA

Reporting goes to your home NCA: AFM (Netherlands), BaFin (Germany), CSSF (Luxembourg), CBI (Ireland), AMF (France), etc. Identify the reporting portal or contact in advance. NCA portals are published on their websites; do not discover this for the first time at 2am when you have 4 hours to submit an initial notification.

5. Pre-Draft Your Initial Notification Template

The initial notification under Article 19 must include: the nature of the incident, the time it was detected and when it started, the classification criteria met, the functions and services affected, and the immediate containment measures taken. Pre-drafting a template and populating the static fields in advance will save critical time.

---

Need to analyse the DORA incident classification RTS and incident response requirements? financialregulations.eu provides AI-powered answers grounded in the full DORA text and all published RTS and ITS — including the joint RTS on incident classification.

Analyse DORA Requirements — Free →