DORA incident classification in plain terms
The Digital Operational Resilience Act — Regulation (EU) 2022/2554 — has applied to EU financial entities since 17 January 2025. One of its most operationally critical obligations is the major ICT-related incident reporting framework: when your systems go wrong, you may have as little as 24 hours to notify your competent authority.
The classification decision — whether an incident is "major" — is not a judgment call. It's a structured legal test based on six criteria defined in Art. 19 DORA and further quantified in Commission Delegated Regulation (EU) 2024/1772 (the RTS on major incident classification criteria). Get the classification wrong — either over-reporting or under-reporting — and you're exposed to regulatory criticism. Get it right and you have a documented, defensible basis for your response.
This guide covers: who DORA applies to, the six Art. 19 criteria with their RTS thresholds, the reporting timeline, parallel notification obligations, and what to do in the first 72 hours.
Who DORA applies to
DORA Art. 2 defines the in-scope entities. The list is broad and covers almost every category of EU-regulated financial institution:
- Credit institutions (banks, including those supervised by the ECB under the SSM)
- Payment institutions and electronic money institutions (EMIs)
- Investment firms (MiFID II Article 4)
- Crypto-asset service providers (CASPs) under MiCA
- Insurance and reinsurance undertakings (Solvency II)
- Central counterparties (CCPs) and central securities depositories (CSDs)
- Trading venues (regulated markets, MTFs, OTFs)
- Trade repositories and data reporting service providers (DRSPs)
- UCITS management companies and alternative investment fund managers (AIFMs)
- Account information service providers (AISPs) and payment initiation service providers (PISPs)
- Critical ICT third-party providers (CTTPs) — designated by the ESAs
Micro-enterprises (fewer than 10 employees, turnover/balance sheet ≤€2M) are exempt from some obligations but not from incident reporting if a major incident occurs.
The six Art. 19 major incident criteria
An ICT-related incident is "major" under DORA if it meets one or more of the following criteria. One is sufficient — you don't need to meet multiple thresholds.
Art. 19(1)(a) — Client and transaction thresholds
The incident affects:
- More than 10% of clients or more than 50,000 clients (whichever is lower), measured against active clients in the preceding 12 months, or
- More than 10% of daily average transactions or transactions exceeding €5 million in value, measured against the 90-day rolling average
RTS reference (Art. 5, Delegated Reg. 2024/1772): Client count is measured against all active retail clients in the preceding 12 months. "Active" is defined per entity type — for a bank, this typically means clients with at least one transaction in the period. For payment institutions, it covers all users who initiated or received a payment.
Practical challenge: at the time of classifying an incident (potentially within hours), you may not yet know how many clients were affected. The RTS recognises this — you should use the best available estimate and update in your intermediate report. When uncertain, classify as major.
Art. 19(1)(b) — Reputational impact
The incident has or is likely to have a reputational impact on the financial entity.
RTS reference (Art. 6, Delegated Reg. 2024/1772): Reputational impact is assessed on: national or international media coverage, regulatory or parliamentary attention, significant volume of client complaints, or awareness among peer financial institutions or market counterparties. A media inquiry alone may be sufficient to trigger this criterion.
This is the most subjective criterion and the one most likely to be under-applied. When in doubt, treat media contact or significant complaint volume as triggering reputational impact.
Art. 19(1)(c) — Duration
The incident results in a service outage of at least 4 hours for a critical or important function.
RTS reference (Art. 7, Delegated Reg. 2024/1772): Duration is measured from first service degradation (not from when the incident was detected) to full service restoration. Critical and important functions are those the entity has designated under its ICT risk management framework (Art. 4 DORA). For most financial entities, these include: payment processing, core banking, trading execution, settlement, clearing, AML/fraud screening, and regulatory reporting.
Practical note: a 3.5-hour outage that's resolved before the 4-hour threshold is not major under this criterion alone. But if it also exceeded the client threshold, it is still major. Track duration from first customer-visible impact, not from incident detection.
Art. 19(1)(d) — Geographic spread
The incident affects ICT services in more than one EU Member State or causes cross-border impact on financial stability, other financial infrastructure, or other financial entities.
RTS reference (Art. 8, Delegated Reg. 2024/1772): Particularly relevant for groups operating across jurisdictions and for incidents affecting shared ICT infrastructure (multi-region cloud outages, pan-European payment network failures). A single-country incident at a purely domestic institution typically won't meet this criterion.
Art. 19(1)(e) — Data loss, integrity, or confidentiality
The incident causes a loss, leakage, or corruption of data — an integrity or confidentiality breach affecting financial transaction data, client records, or regulatory reporting data.
RTS reference (Art. 9, Delegated Reg. 2024/1772): Assessment is based on: sensitivity of the data (financial transaction data, personal data, market-sensitive data), volume affected, and whether the loss impacts the entity's ability to meet regulatory reporting obligations. Note: a data breach that also involves personal data may simultaneously trigger GDPR Art. 33 notification (72h to supervisory authority) — these are parallel obligations.
Art. 19(1)(f) — Critical or important function impact
The incident significantly impacts the availability, authenticity, integrity, or confidentiality of data or services related to a critical or important function — even if the absolute volume of clients or transactions affected doesn't meet the thresholds in criterion (a).
RTS reference (Art. 10, Delegated Reg. 2024/1772): This criterion acts as a catch-all for incidents that are operationally severe even if relatively contained. For example: a 2-hour outage affecting only your proprietary trading desk may not meet the client threshold, but if proprietary trading is a critical function, criterion (f) may still be triggered.
The three-report structure: 24h / 72h / 1 month
Once you classify an incident as major, the DORA reporting clock starts. The ITS on incident reporting templates — Commission Implementing Regulation (EU) 2024/2518 — defines the exact content requirements for each report:
Early warning (within 24 hours of becoming aware)
Content: incident reference, date/time of detection and occurrence, initial classification as major/non-major (provisional), brief description of the incident, immediate actions taken, preliminary assessment of impact. This is a notification, not a full report — precision is less important than timeliness. If you become aware of the incident on Friday at 3pm, your early warning is due by Saturday at 3pm.
Intermediate report (within 72 hours of becoming aware)
Content: updated classification, revised impact assessment (clients affected, transaction impact, financial losses if quantifiable), extent of geographic spread, client notification status, ongoing containment and mitigation measures, root cause hypothesis if available, third-party involvement if applicable. The intermediate report is where your investigators have had time to assess the full scope.
Final report (within 1 month of resolution)
Content: confirmed root cause analysis, total impact assessment, all remediation actions taken, permanent fixes implemented, lessons learned, preventive measures, whether ICT testing revealed or was triggered by the incident. The final report should be a complete post-incident review document that would satisfy a regulatory inspection.
Which competent authority do you notify?
DORA notifications go to your lead competent authority:
- Significant institutions (directly supervised by ECB): Joint Supervisory Team (JST) / ECB, with copies to the national NCA
- Less significant institutions (nationally supervised): National NCA (e.g., BaFin Germany, ACPR France, DNB Netherlands, FI Sweden, CSSF Luxembourg)
- Investment firms: National NCA under MiFID II (e.g., BaFin, AMF, FCA for EEA-equivalence entities)
- CCPs/CSDs: ESMA oversight (via national NCA)
- Insurers/reinsurers: National NCA under Solvency II (EIOPA oversight for systemic firms)
- Payment institutions/EMIs: National NCA under PSD2/PSD3 (EBA oversight for cross-border firms)
For cyber incidents, you may also notify: your national CSIRT/CERT (ENISA coordinates at EU level), and potentially law enforcement if the incident involves criminal activity.
Parallel notification obligations
A DORA major incident doesn't eliminate other notification obligations — it runs in parallel:
GDPR personal data breach (Art. 33-34)
If the incident involves a personal data breach, you must notify your lead supervisory authority (GDPR DPA) within 72 hours of becoming aware. If the breach poses high risk to individuals, you must also notify affected data subjects (Art. 34). DORA notification and GDPR notification are to different authorities and have different content requirements — they are complementary, not substitutes for each other.
NIS2 incident notification (Art. 23)
If your entity is also designated as an essential or important entity under NIS2 (Directive (EU) 2022/2555), you have a parallel 24h early warning obligation to your NIS2 competent authority. Financial entities may have concurrent DORA and NIS2 obligations for the same incident — check your national transposition law.
PSD2/PSD3 operational incident reporting
Payment service providers have additional EBA Guidelines obligations on operational incident reporting. The DORA reporting regime is intended to supersede the PSD2 regime for DORA-in-scope entities from January 2025, but verify with your national NCA whether parallel filings are still expected during the transition.
RTO/RPO under DORA Art. 12
DORA Art. 12 requires financial entities to establish, implement, and test ICT business continuity policies including defined RTOs (Recovery Time Objectives) and RPOs (Recovery Point Objectives) for critical functions. The major incident framework interacts with your RTO/RPO in two ways:
- An incident that breaches your defined RTO is strong evidence that the function was critically impacted, supporting a major classification under criterion (c) or (f)
- The final report must assess whether your RTO/RPO was met and, if not, what remediation is planned
Benchmark RTOs per EBA Guidelines on ICT risk management: 2-4 hours for critical payment functions, 24 hours for less critical functions. If you haven't defined RTOs, doing so is both an Art. 12 obligation and practically necessary for incident classification.
Third-party ICT provider involvement
If the incident originated with or was exacerbated by a third-party ICT provider (cloud provider, payment processor, core banking software vendor), DORA Art. 28-29 contractual requirements become relevant:
- Your contract should include incident notification SLAs — typically 24-48 hours for major incidents
- The provider should be obligated to provide root cause information for your final report
- For Critical Third-Party Providers (CTTPs) designated by the ESAs, additional oversight applies
Your final report must reference third-party involvement and describe what contractual remedies you have exercised or plan to exercise.
Classify your incident now
ComplyKit's free DORA Major ICT Incident Classification Matrix walks you through all six Art. 19 criteria with their RTS thresholds. Input your entity details and incident information, answer each criterion, and the tool:
- Provides a real-time classification decision (Major / Non-major) as you assess each criterion
- Generates a formal classification report with Art. 19 and RTS article citations
- Produces the 24h/72h/1-month reporting timeline with content requirements
- Assesses parallel GDPR/NIS2/PSD2 notification obligations
- Analyses RTO/RPO breach implications
- Lists entity-specific competent authority contacts
- Provides a first-72-hours action checklist
→ Use the DORA Incident Classification Matrix free
Also useful: DORA Technical Standards Checklist for the full DORA ICT framework, or NIS2 Compliance Checklist for parallel NIS2 obligations.