DORA Incident Classification Criteria: RTS 2024/1772 Guide

Regulation Number: Commission Delegated Regulation (EU) 2024/1772

Adoption Date: March 13, 2024

Publication Date: June 25, 2024 (Official Journal)

Application Date: January 17, 2025

Official Source: EUR-Lex (eur-lex.europa.eu/eli/reg_del/2024/1772/oj/eng)

Executive Summary

Objective: This RTS establishes precise criteria for classifying ICT incidents as "major" and determines the materiality thresholds that trigger the obligation to report to competent authorities.

Critical Importance: Correct incident classification is essential as it determines:

The obligation to notify supervisors (within 4 hours for major incidents)
Potential penalties for non-reporting
The impact on reputation and customer confidence

The 6 Classification Criteria

An ICT incident is considered "major" if it meets ONE OR MORE of the following criteria:

1. Number of Clients Affected (Article 4)

Classification thresholds by entity type:

Financial Entity Type	Impact Threshold	Examples
Systemic banks (G-SIBs)	≥ 100,000 clients	BNP Paribas, Deutsche Bank, Santander
Other banks	≥ 50,000 clients	Regional banks, savings banks
Insurance companies (large)	≥ 100,000 policyholders	AXA, Allianz, Generali
Insurance companies (SMEs)	≥ 30,000 policyholders	Regional mutuals
Payment service providers	≥ 50,000 users	PayPal, Stripe, Revolut
Investment firms	≥ 20,000 clients	Brokers, asset managers
Crypto-asset providers	≥ 25,000 users	Exchanges, custodial wallets
Microenterprises	≥ 5,000 clients	Small fintechs, financial advisors

⚠ IMPORTANT - Calculating affected clients:

Count ALL impacted clients, even partially
Include both B2B AND B2C clients
For groups: count at consolidated level
Impacted = inability to access the critical service

2. ⏱ Duration of Service Interruption (Article 5)

Thresholds by function criticality:

Criticality Level	Minimum Duration	Service Examples
CRITICAL functions	≥ 2 hours cumulative over 24h	• SEPA/SWIFT payments • Real-time trading • Automated teller machines (ATM) • Client account access
IMPORTANT functions	≥ 4 hours cumulative over 24h	• Reporting services • Banking back-office • Claims management (insurance) • Account management portals
Other functions	≥ 24 hours continuous	• Marketing services • Newsletters • Non-essential administrative functions

Calculation method:

Cumulative: Add all interruptions over a rolling 24-hour period
Example: 3 outages of 45 minutes each = 2h15 cumulative → major incident for critical function
Partial degradation: A capacity reduction >50% counts as interruption

3. Geographic Extent (Article 3)

Classification by geographic scope:

Extent	Definition	Classification
Multi-Member States	Impact in ≥ 2 EU countries	MAJOR
Extensive national	Impact in ≥ 3 regions of a country OR ≥ 25% of national territory	MAJOR
Major metropolitan area	Capital or city > 1 million inhabitants completely impacted	POTENTIALLY MAJOR
Regional	Single administrative region	Minor (unless other criteria)

Special cases:

100% digital services: Geographic scope is determined by the location of affected clients
Physical branches: Count the number of closed sites versus total
Shared infrastructure: If the incident affects multiple institutions via a common third-party provider

4. Data Loss (Article 6)

Data loss classification criteria:

Loss Type	Major Threshold	Examples
Sensitive personal data	≥ 5,000 individuals	Bank card numbers, health data, biometric data
Non-sensitive personal data	≥ 50,000 individuals	Names, addresses, emails, phone numbers
Transactional data	≥ 10,000 transactions	Payment histories, stock orders, insurance policies
Critical financial data	Any irreversible loss	Account balances, trading positions, collateral
Data integrity	Corruption affecting >1% of critical records	Customer database, accounting records

⚠ ATTENTION - Types of losses:

Loss of confidentiality: Unauthorized access or data breach
Loss of availability: Data inaccessible > defined RPO
Loss of integrity: Data corrupted, modified or maliciously deleted
GDPR notification: If the DORA threshold is reached, GDPR notification also required!

5. Economic Impact (Article 7)

Financial thresholds by entity size:

Entity Category	Total Balance Sheet	Major Impact Threshold
Very large institutions	> €100 billion	≥ €10 million direct losses
Large institutions	€30-100 billion	≥ €5 million direct losses
Medium institutions	€5-30 billion	≥ €2 million direct losses
Small institutions	€1-5 billion	≥ €500,000 direct losses
Microenterprises	< €1 billion	≥ €100,000 direct losses

Calculation of direct losses:

✓ Include: Remediation costs, emergency IT expenses, external consultants, regulatory fines, customer compensation
✓ Include: Revenue lost during interruption (transaction fees not collected, interest not generated)
✓ Include: Financial fraud directly related to the incident
✗ Exclude: Reputation costs, stock market value loss, future customer attrition

⏰ Initial vs. final calculation:

Initial notification (4h): Use a preliminary estimate based on observed impact
Interim report (72h): Refine the estimate with partial data
Final report (1 month): Definitive figures with supporting documents

6. Criticality of Affected Services (Article 8)

Criticality matrix:

Criticality Level	Criteria	Service Examples	Major Threshold
CRITICAL (Tier 1)	• Direct customer service • Regulated/mandatory • Revenue >20% of turnover	• Payments • Trading • Core Banking • Claims processing	Any interruption ≥ 2h
IMPORTANT (Tier 2)	• Support for critical functions • Compliance • Revenue 5-20% of turnover	• Regulatory reporting • Risk management • Customer onboarding	Interruption ≥ 4h
STANDARD (Tier 3)	• Support functions • No direct client impact • Revenue <5% of turnover	• HR systems • Marketing • Intranet	Interruption ≥ 24h

Determining criticality:

Base on the Business Impact Analysis (BIA) performed under the RTS Risk Management
Document the classification in the critical functions register
Review the classification at least annually
When in doubt, classify at the higher level (precautionary principle)

Classification Logic: Decision Tree

4-Step Process

STEP 1 - Detection (T+0)

ICT incident detected (outage, cyberattack, data corruption, etc.)
Activation of incident management team
Start of reporting timer

STEP 2 - Rapid Assessment (T+0 to T+2h)

Identify affected systems/services
Estimate number of impacted clients
Assess geographic extent
Check if data is compromised

STEP 3 - Preliminary Classification (T+2h to T+4h)

Apply EACH classification criterion
If A SINGLE criterion reaches the threshold → MAJOR INCIDENT
Prepare initial notification
Alert the management body

STEP 4 - Notification (Before T+4h)

Submit initial report via supervisor's portal
Include all information available at this stage
Specify if the classification is preliminary

Practical Classification Examples

✓ Example 1: Ransomware Cyberattack - MAJOR

Scenario: A regional bank suffers a ransomware attack that encrypts its production servers.

Observed impacts:

Online banking unavailable: 75,000 clients cannot access their accounts
Duration: 6 hours before partial restoration
Geography: Entire Île-de-France region
Losses: €250,000 (emergency response + forensic consultant)

Classification:

✓ Criterion 1 (Clients): 75,000 > 50,000 → MAJOR
✓ Criterion 2 (Duration): 6h > 2h for critical function → MAJOR
✗ Criterion 3 (Geography): Only 1 region → Not major
✗ Criterion 5 (Economic): €250k < threshold → Not major

✓ Verdict: MAJOR INCIDENT (notification within 4h mandatory)

⚠ Example 2: Limited Data Breach - NOT MAJOR

Scenario: An insurance company discovers a data leak via a poorly secured API.

Observed impacts:

Exposed data: Names + emails of 3,200 policyholders
No sensitive data (no card numbers, no medical data)
No service interruption
Detection and correction within 2 hours

Classification:

✗ Criterion 1 (Clients): Service not interrupted
✗ Criterion 4 (Data): 3,200 < 50,000 for non-sensitive data

✓ Verdict: MINOR INCIDENT (no DORA notification, but GDPR notification required)

✓ Example 3: Cloud Infrastructure Outage - MAJOR

Scenario: A cloud provider suffers a major power failure in its primary datacenter.

Observed impacts:

15 financial institutions simultaneously affected
Geography: France, Belgium, Luxembourg
Duration: 3 hours complete interruption
Affected services: Core banking, trading platforms, payment processing

Classification:

✓ Criterion 3 (Geography): 3 Member States → MAJOR
✓ Criterion 2 (Duration): 3h > 2h for critical functions → MAJOR
✓ Criterion 6 (Criticality): Critical services affected → MAJOR

✓ Verdict: MAJOR INCIDENT

⚠ Particularity: EACH client institution must notify individually (15 separate notifications)

✓ Classification Checklist

Criterion	Question to Ask	Data Source
1. Clients	☐ How many clients can no longer access the service?	Access logs, CRM system, application monitoring
2. Duration	☐ How long has the service been interrupted? ☐ What is the criticality of the affected service?	Monitoring system, ticketing, log timestamps
3. Geography	☐ How many regions/countries are impacted? ☐ Which offices/datacenters are affected?	Infrastructure mapping, service geolocation
4. Data	☐ Has there been unauthorized access to data? ☐ Is data lost or corrupted? ☐ What type of data? How many people?	SIEM logs, DLP alerts, database audit trails
5. Impact €	☐ Estimate of incident response costs? ☐ Lost transactional revenue? ☐ Fraud or direct financial losses?	Invoices, budget tracking, accounting data
6. Criticality	☐ Is the affected service critical or important? ☐ What is its classification in the BIA?	Critical functions register, BIA documentation

⚠ Common Errors to Avoid

✗ Error #1: Waiting for complete resolution before classifying

Correct: Classify as soon as sufficient information is available (within 4h), even if the incident is not yet resolved.

✗ Error #2: Only counting clients who complain

Correct: Count ALL clients who cannot access the service, whether they attempted to connect or not during the incident.

✗ Error #3: Considering theoretical rather than actual interruption duration

Correct: The duration starts as soon as the service is unavailable, not from detection or start of remediation.

✗ Error #4: Classifying differently an incident caused by a third party

Correct: The cause of the incident (internal/external/third-party) does NOT affect classification. Only impact matters.

✗ Error #5: Not reclassifying if the situation evolves

Correct: If an initially minor incident exceeds a threshold in subsequent hours/days, it must be reclassified as major and notified.

What to Do After Classification?

If the incident is classified MAJOR:

T+4h max: Submit initial report (see RTS 2025/301 Incident Reporting)
T+72h max: Submit interim report with detailed analysis
T+1 month max: Submit final report with root cause and corrective measures
In parallel: Inform the management body, activate crisis communication plan

If the incident is classified MINOR:

No notification to supervisors required
Document in internal incidents register
Include in annual ICT resilience report
Analyze during quarterly incident review with management body

Additional Resources

RTS 2025/301: Incident Reporting (timelines and templates)
ITS 2024/2956: Standardized notification templates
EBA Guidelines: Classification examples by sector
DORA Article 19: Legal basis for incident reporting

Need Help Implementing These Requirements?

Our experts can guide your institution through DORA compliance, from gap analysis to full implementation.

Free Gap Analysis Consulting Services Download All Guides

Practitioner tools for DORA compliance teams

Workbooks, playbooks and certifications built for EU financial entities. Add several to your cart: volume discounts apply automatically.

academy-bundle

DORA Certifications Bundle

399 € excl. VAT

academy

DORA for IT & Security Teams

199 € excl. VAT

academy

DORA for ICT Providers & Vendors

199 € excl. VAT

Browse the full library · Excel toolkits · Certifications

How Compliant Is Your Institution?

Take our free 5-minute assessment and get an instant DORA compliance score with personalised recommendations.

Get Your Free DORA Score Join the Webinar Waiting List

RTS on ICT Incident Classification

Executive Summary

The 6 Classification Criteria

1. Number of Clients Affected (Article 4)

2. ⏱ Duration of Service Interruption (Article 5)

3. Geographic Extent (Article 3)

4. Data Loss (Article 6)

5. Economic Impact (Article 7)

6. Criticality of Affected Services (Article 8)

Classification Logic: Decision Tree

4-Step Process

Practical Classification Examples

✓ Example 1: Ransomware Cyberattack - MAJOR

⚠ Example 2: Limited Data Breach - NOT MAJOR

✓ Example 3: Cloud Infrastructure Outage - MAJOR

✓ Classification Checklist

⚠ Common Errors to Avoid

✗ Error #1: Waiting for complete resolution before classifying

✗ Error #2: Only counting clients who complain

✗ Error #3: Considering theoretical rather than actual interruption duration

✗ Error #4: Classifying differently an incident caused by a third party

✗ Error #5: Not reclassifying if the situation evolves

What to Do After Classification?

If the incident is classified MAJOR:

If the incident is classified MINOR:

Additional Resources

Need Help Implementing These Requirements?

Practitioner tools for DORA compliance teams

DORA Certifications Bundle

DORA for IT & Security Teams

DORA for ICT Providers & Vendors

How Compliant Is Your Institution?