Learn
DORA’s incident reporting regime is, by design, the most time-pressured obligation in the entire regulation. For a major ICT-related incident, a financial entity must submit an initial notification to its national competent authority (NCA) as early as possible, and in any case within 4 hours of classifying the incident as major - and no later than 24 hours from the moment it becomes aware of the incident. Those time limits are set out in Commission Delegated Regulation (EU) 2025/301, which supplements Article 19(4) of DORA.
That creates a brutally small window. But before the clock even starts, you face a harder question: is this incident “major” in the first place?
Article 18 of DORA, supplemented by the joint ESAs’ Regulatory Technical Standards on the classification of ICT-related incidents (Commission Delegated Regulation (EU) 2024/1772), establishes a structured, multi-criteria threshold test. Classification is not a matter of gut feel - it is a defined assessment against seven criteria, each with materiality thresholds that decide whether an incident crosses the “major” line, and a precise combination rule that ties them together.
Getting this wrong has consequences in both directions. Under-report, and you face supervisory scrutiny, remediation orders, and reputational damage. Over-report, and you drown your NCA in noise and burn scarce resources during a live incident. This guide gives you the exact criteria, thresholds, timelines, and decision logic - straight from the regulation - to get classification right every time.
📈
RTS 2024/1772, Articles 1 to 7
The 7 Classification Criteria for Major Incidents
Article 18(1) of DORA sets out the criteria financial entities use to classify ICT-related incidents, and Articles 1 to 7 of the RTS (Delegated Regulation (EU) 2024/1772) turn them into seven named criteria, with Article 9 fixing the materiality thresholds for each. Read the criteria first, then the combination rule that decides “major”.
DORA Article 18(1)
“Financial entities shall classify ICT-related incidents and shall determine their impact on the basis of the following criteria: (a) the number and/or relevance of clients or financial counterparts affected and, where applicable, the amount or number of transactions affected [...] and whether the ICT-related incident has caused reputational impact; (b) the duration of the ICT-related incident, including the service downtime; (c) the geographical spread [...]; (d) the data losses that the ICT-related incident entails, in relation to availability, authenticity, integrity or confidentiality of data; (e) the criticality of the services affected [...]; (f) the economic impact, in particular direct and indirect costs and losses [...].”
The RTS splits those into seven criteria - it separates reputational impact into a criterion of its own and treats the criticality of services as the gateway. Below is the definitive breakdown of each criterion with its materiality threshold from Article 9 of the RTS:
| # | Criterion | Materiality Threshold (RTS Art. 9) | What to Measure |
|---|---|---|---|
| 1 | Clients, Financial Counterparts & Transactions Affected | > 10% of clients using the affected service, OR > 100,000 clients; OR > 30% of financial counterparts; OR affected transactions > 10% of the daily average number or value (Art. 9(1)) | Count unique clients or counterparts unable to access or use the affected service, and value the transactions that failed, were delayed, or were processed incorrectly. Transactions are part of this criterion - not a separate one. |
| 2 | Reputational Impact | Met where the incident has been reflected in the media, caused repetitive client or counterpart complaints, threatens the entity’s ability to meet regulatory requirements, or is likely to cost it clients or counterparts with a material business impact (Art. 2, Art. 9(2)) | A qualitative criterion. Assess visibility and client-facing fallout, not just internal disruption. Media coverage or a wave of complaints on client-facing services is the clearest signal. |
| 3 | Duration & Service Downtime | Incident duration > 24 hours, OR service downtime > 2 hours for ICT services that support critical or important functions (Art. 9(3)) | Two distinct clocks: overall incident duration (24-hour threshold) and downtime of services supporting critical or important functions (2-hour threshold). Include degraded performance, not just total outage. |
| 4 | Geographical Spread | The incident has an impact in two or more Member States (Art. 9(4)) | Assess whether clients or operations in more than one Member State are affected. Cross-border payment systems, clearing operations, and correspondent banking relationships amplify this criterion. |
| 5 | Data Losses | Any loss affecting availability, authenticity, integrity or confidentiality of data that adversely affects business objectives or regulatory compliance; OR a successful malicious unauthorised access to systems that may result in data losses (Art. 9(5)(a) and (b)) | Consider all four data dimensions. Note the second limb - a successful malicious unauthorised access - is the RTS’s single strongest trigger (see the combination rule below). Cross-reference with GDPR personal data breach thresholds. |
| 6 | Criticality of Services Affected (GATEWAY) | Met where the incident affects ICT services or systems supporting critical or important functions; OR affects authorised, registered or supervised financial services; OR constitutes a successful, malicious and unauthorised access to network and information systems (Art. 6) | This is the primary gateway. If none of its three limbs is met, the incident cannot be major, regardless of the other thresholds. Note the third limb: a successful malicious intrusion opens the gateway even for a non-critical system. |
| 7 | Economic Impact | Direct and indirect costs and losses have exceeded, or are likely to exceed, EUR 100,000 (Art. 9(6)) | Sum direct costs (remediation, recovery, forensics, penalties) and indirect costs (lost revenue, client compensation, opportunity cost). The threshold is a flat EUR 100,000 - there is no revenue-percentage alternative. Estimate early, refine later. |
The Combination Rule (RTS Article 8)
An incident is major where it has affected critical services (the criticality gateway, Article 6) AND either: (i) the Article 9(5)(b) threshold is met - a successful, malicious and unauthorised access to network and information systems that may result in data losses; OR (ii) two or more of the six materiality thresholds in Article 9(1) to (6) are met. In other words, one ordinary threshold on its own is not enough - you need a qualifying malicious intrusion, or at least two thresholds. Economic impact is one of those six thresholds; it carries no special standalone power. Article 8 also adds an aggregation rule: recurring incidents that are individually non-major count as one major incident where they occur at least twice within 6 months, share the same apparent root cause, and collectively meet the test. Entities assess this monthly, and it does not apply to microenterprises.
⏰
Article 19 & RTS 2025/301
The Three-Stage Reporting Timeline
Article 19 of DORA requires an initial notification and two follow-up reports for every major ICT-related incident, submitted to the relevant NCA. The exact deadlines are laid down in Commission Delegated Regulation (EU) 2025/301, Article 5. Each phase has a strict clock and defined content.
Commission Delegated Regulation (EU) 2025/301, Article 5
Initial notification: as early as possible, and in any case within 4 hours from the classification of the incident as major, and no later than 24 hours from the moment the financial entity has become aware of the incident. Intermediate report: at the latest within 72 hours from the submission of the initial notification. Final report: no later than one month after the submission of the intermediate report (or the latest updated intermediate report).
| Report | Deadline | Required Content |
|---|---|---|
| Initial Notification | 4 hours after classification (max 24h after becoming aware) | Entity identification; date and time of detection and classification; nature and type of incident; initial assessment of affected services, clients, and counterparts; whether the incident is recurring; preliminary impact assessment; immediate actions taken; contact details. |
| Intermediate Report | 72 hours after initial notification | Updated assessment against the criteria and thresholds; status of containment and recovery; preliminary root cause; updated client and counterpart impact; geographical spread; estimated economic impact; transactions affected (volume and value); other notification obligations triggered; updated remediation timeline. An updated intermediate report is due once regular activities have been recovered. |
| Final Report | 1 month after the intermediate report | Confirmed root cause analysis; full quantified impact assessment; total economic cost (direct and indirect); lessons learned and corrective actions; changes to the ICT risk management framework; whether the incident revealed third-party provider failings; confirmation of client communications; audit trail of actions taken. |
The “Double Clock” Problem
The initial notification carries two overlapping deadlines: 4 hours from classification and 24 hours from becoming aware of the incident. That gives you a hard ceiling of roughly 20 hours to reach a classification decision before the absolute backstop takes over. Treat classification as its own time-boxed task, not an afterthought once containment is done.
Voluntary Notifications
Article 19(2) lets financial entities voluntarily notify their NCA of significant cyber threats that have not resulted in a major incident. It is optional, but it demonstrates mature risk management and can be useful for near-misses that meet the significant-threat test (see the FAQ below).
What Happens When You Miss the Deadline
Under Article 50 of DORA, competent authorities may impose administrative penalties and remedial measures for breaches, proportionate to the severity and impact of the non-compliance, and may in serious cases publicly disclose the failure. Beyond the sanction itself, being flagged as a late or non-reporter invites closer supervisory attention - a cost that often outweighs the fine.
🌳
Decision Framework
Classification Decision Tree
When an ICT-related incident occurs, use this structured walkthrough to reach a classification decision. The order matters: the criticality gateway is assessed first, then the materiality thresholds are evaluated in parallel to minimise classification time.
Step 1 - Gateway: Criticality of Services (Article 6)
Is any one of the three gateway limbs met? (a) the incident affects ICT services or systems supporting a critical or important function in your business impact analysis and register of information; (b) it affects financial services that require authorisation, registration or supervision; (c) it constitutes a successful malicious unauthorised access to your systems. If NO to all three → the incident is not major. Log it and manage it, but there is no NCA reporting obligation. If YES to any → proceed to Step 2.
Step 2 - Assess the Six Materiality Thresholds in Parallel
For each of the six thresholds in Article 9(1) to (6), determine whether it is met:
Clients / transactions: >10% or >100k clients, >30% counterparts, or >10% of daily transactions?
Reputational: media coverage, repetitive complaints, or client loss?
Duration: >24h duration, or >2h downtime for critical/important functions?
Geography: two or more Member States?
Data losses: adverse data impact, or malicious access that may cause data loss (9(5)(b))?
Economic: costs and losses > EUR 100,000?
Step 3 - Apply the Combination Rule (Article 8)
With the gateway met, classify as MAJOR if either: the Article 9(5)(b) threshold is met (a successful malicious unauthorised access that may result in data losses), OR two or more of the six thresholds in Step 2 are met. If only one ordinary threshold is met and there is no qualifying malicious access → not major (but keep monitoring). When you classify as major, the 4-hour NCA reporting clock starts now.
Step 4 - Ongoing Reassessment
Incidents evolve. A minor incident at hour 1 may cross a second threshold at hour 3 as impact propagates. Reassess the classification throughout the incident lifecycle. If an incident is reclassified from non-major to major, the 4-hour clock runs from the moment of reclassification - but the 24-hour absolute backstop is still measured from when you first became aware of the incident.
📑
Incident Taxonomy
Major vs. Non-Major Incidents vs. Cyber Threats
DORA distinguishes major ICT-related incidents (mandatory NCA reporting) from other, non-major incidents (log and manage internally), and separately allows voluntary notification of significant cyber threats. Understanding the boundaries prevents both over-reporting and dangerous under-classification.
| Dimension | Major Incident | Non-Major Incident | Significant Cyber Threat |
|---|---|---|---|
| Trigger | Gateway met + [9(5)(b) OR two or more thresholds] | Gateway not met, or the combination rule not satisfied | A threat that could materialise into a major incident (Art. 10) - no incident has occurred |
| NCA reporting | Yes - mandatory | No (log under Art. 17) | Voluntary (Art. 19(2)) |
| Reporting timeline | 4h / 72h / 1 month | Internal SLA only | No fixed regulatory clock |
| Management body | Escalate per ICT incident process (Art. 17) | Operational or risk team | Risk management escalation |
| Client notification | Required where it impacts clients’ financial interests (Art. 19(3)) | Generally not required | Not applicable |
| Root cause analysis | Mandatory, in the final report | Expected under Art. 17 process | Threat analysis |
| Documentation | Full audit trail for supervisory review | Internal records, supervisory access | Internal records |
Why Non-Major Incidents Still Matter
Even though non-major incidents do not trigger NCA reporting, they must be recorded and managed under your ICT-related incident management process (Article 17). Supervisors review your full incident register during examinations, and a pattern of incidents recorded as non-major that should have been classified as major will raise immediate red flags. Build a defensible, time-stamped classification rationale for every incident, regardless of outcome.
🏛️
Regulatory Mechanics
NCA Reporting: Who, Where, and How
The reporting destination is your home NCA - the competent authority that authorised or registered the financial entity. For banks, that is typically the national banking supervisor (for example BaFin in Germany, the ACPR in France, DNB in the Netherlands, the Central Bank of Ireland). For payment institutions, it is the relevant payment services supervisor. For cross-border groups, the home NCA of the parent entity coordinates with host supervisors.
Reporting Format
The reporting templates are prescribed by the implementing technical standards (Commission Implementing Regulation (EU) 2025/302). Each phase - initial, intermediate, final - uses a standardised, structured form, with free-text narrative to supplement the structured data. Submission is via the NCA’s designated reporting channel.
Clear Ownership
Designate a person empowered to escalate, classify, and submit reports without waiting for committee approvals, and pre-appoint deputies for 24/7 coverage. Under a 4-hour clock, an unclear owner is the single most common cause of a missed deadline.
Cross-Border Coordination
For incidents relevant to other Member States, the home NCA shares the notification with the relevant host NCAs and the ESAs (EBA, EIOPA, ESMA), as set out in Articles 11 and 12 of the RTS. You report to one NCA; they coordinate the rest. Flag the cross-border dimension in your report.
Parallel Notification Obligations
A major ICT incident may also trigger other regimes: GDPR (Article 33, 72-hour breach notification), NIS2 (if the entity is an essential or important entity), and PSD2 (for payment service providers). Each has its own timeline and authority. Map all parallel obligations into your incident response process.
Practical Tip: Pre-Stage Your Reports
Pre-populate the initial notification template with static entity data (identifiers, NCA reference, authorisation details, key contact names, standard service descriptions) so that during a live incident your team only fills in incident-specific fields. That keeps the tight window focused on containment and assessment, not form-filling.
⚠️
Pitfalls to Avoid
6 Common Classification Mistakes
These are the classification errors most likely to trip up an incident team under time pressure - and why each one matters.
Mistake 1: Waiting for Full Impact Data Before Classifying
Teams delay classification until they have definitive client counts, economic figures, or a confirmed root cause. But the initial notification explicitly allows preliminary data - it calls for a reasonable assessment, not certainty. Waiting for perfect numbers burns your 4-hour window and risks breaching the 24-hour absolute backstop. Classify on the best available information, then refine in the intermediate and final reports.
Mistake 2: Confusing “ICT Incident” with “Cybersecurity Incident”
DORA’s scope is broader than cyber. Article 3(8) defines an “ICT-related incident” as a single event or series of linked events unplanned by the entity that compromises the security of network and information systems and has an adverse impact on the availability, authenticity, integrity, or confidentiality of data or on the services provided. That includes hardware failures, software bugs, configuration errors, cloud provider outages, and capacity exhaustion - not just ransomware and data breaches. Many entities never route infrastructure incidents through the classification process at all.
Mistake 3: Not Mapping Services to Critical or Important Functions
The criticality gateway (Article 6) turns on whether the affected service supports a critical or important function - defined in Article 3(22) as one whose disruption would materially impair the entity’s financial performance, or the soundness or continuity of its services, or its compliance with the conditions of its authorisation. Without a definitive mapping of ICT services to functions, drawn from your business impact analysis and register of information, the gateway assessment becomes guesswork.
Mistake 4: Treating Third-Party Outages as “Not Our Incident”
When a cloud provider, payment processor, or SaaS vendor suffers an outage that hits your services, it is your ICT-related incident to classify. The criteria assess impact on your clients, your services, and your transactions. An external root cause does not exempt you from reporting - the third-party risk management obligations in DORA specifically contemplate this scenario.
Mistake 5: Not Reclassifying as Incidents Evolve
An incident that starts minor can become major as cascading failures propagate. A database performance issue at 09:00 might touch only internal systems; by 11:00, customer-facing APIs may be timing out across three countries and pushing a second threshold over the line. Teams that classify once and never reassess miss the reclassification and blow through the reporting window. Build reassessment checkpoints into your playbook for any incident affecting ICT infrastructure.
Mistake 6: Failing to Coordinate DORA, GDPR and NIS2 Notifications
A single incident can trigger reporting under DORA (4h to the NCA), GDPR (72h to the DPA), and NIS2 (24h early warning to the CSIRT). Each has different thresholds, authorities, and content. Entities that run these in separate silos inevitably send inconsistent information to different regulators - a red flag that invites scrutiny. Drive all notification obligations from one incident record and one classification assessment.
🔍
Applied Classification
Worked Scenarios: Major or Not?
Theory is clean; reality is messy. These four illustrative scenarios apply the gateway and the combination rule. Each walks through the gateway test and the threshold count.
| Scenario | Key Facts | Criteria Analysis | Classification |
|---|---|---|---|
| Cloud provider outage hits online banking | Cloud region outage, 3.5 hours of downtime on mobile and web banking, ~45,000 retail customers affected, single country, recovery and remediation costs estimated above EUR 100,000 | Gateway: online banking supports a critical function. Threshold 1: downtime 3.5h > 2h. Threshold 2: economic impact > EUR 100,000. Two thresholds met. | MAJOR |
| Internal HR system ransomware | Ransomware encrypts the HR and payroll system, employee data likely exfiltrated, 48 hours to restore, no customer-facing impact | Gateway: a successful malicious unauthorised access opens the gateway via Article 6(c), even though HR is not a critical function. Single trigger: the same access satisfies Article 9(5)(b). Gateway + 9(5)(b) is sufficient on its own. | MAJOR |
| Payment processing degradation | Card payment processing at 60% capacity for 90 minutes, EUR 2.3M in card transactions delayed - more than 10% of the processor’s average daily transaction value - clients in DE and NL affected | Gateway: payment processing is critical. Duration: 90 min < 2h, not met. Threshold 1: geography, 2 Member States (Art. 9(4)). Threshold 2: transactions affected exceed 10% of the daily average transaction value (Art. 9(1)). Two thresholds met. | MAJOR |
| DDoS attack on marketing website | A DDoS takes the corporate marketing website offline for 4 hours; no impact on trading, banking or payment systems; no unauthorised access; marketing site only | Gateway: the marketing site is not a critical or important function, no financial service is affected, and a DDoS is a disruption rather than a successful unauthorised access. None of the three gateway limbs is met. | NOT MAJOR |
The Grey Zone
Most disputes live where the gateway is clearly met but the second threshold is borderline. There is no regulatory instruction to “report when in doubt”, but supervisors expect a documented, defensible rationale for every call. Where the two-threshold test is genuinely marginal, many entities err toward reporting and downgrade in the intermediate report - an over-report that gets corrected is far less damaging than an under-report the NCA finds after the fact. Whatever you decide, record why.
⚡
Platform Capability
How Venvera Supports Incident Classification
When 240 minutes is all you have, you cannot spend half of it working out whether you need to report. Venvera’s incident module - one part of a broader multi-framework compliance platform - encodes the Article 6 gateway, the Article 9 materiality thresholds, the Article 8 combination rule, and the three-phase reporting timeline into a structured workflow, so classification is a guided assessment rather than a spreadsheet debate.
Guided Classification
Enter the incident parameters (affected services, duration, client count, geographic reach) and the module evaluates the gateway and the six thresholds against the RTS combination rule, returning a classification recommendation with the regulatory justification behind it.
Critical Function Mapping
A pre-configured mapping between your ICT services, business functions, and criticality assessments from your register of information means the Article 6 gateway is evaluated automatically based on which service is affected.
Deadline Countdown & Alerts
From the moment an incident is logged, countdown timers track the 4-hour initial notification window, the 72-hour intermediate deadline, and the 1-month final report due date, with escalation alerts as each deadline approaches.
NCA Report Drafting
Report templates aligned to the implementing technical standards (Regulation (EU) 2025/302). Entity identification, static data, and service mappings are pre-filled; incident-specific fields are structured for rapid completion and export.
Reclassification Monitoring
As you update incident parameters during a live event, the module re-evaluates the combination rule. If a non-major incident crosses a second threshold, it flags the change so you do not miss the reporting window.
Multi-Framework Coordination
A single incident record can drive parallel assessment under DORA, GDPR, and NIS2, mapping each regime’s threshold and tracking each deadline independently, so consistent information reaches every regulator.
Classification Audit Trail
Every classification decision, parameter change, and reassessment is logged with timestamps and user attribution, so when a supervisor asks why an incident was classified as non-major, you have a defensible record of the reasoning.
Structured Root Cause
Root cause capture aligned with the incident taxonomy expected by supervisors, feeding your final report and your wider ICT risk management framework (Article 6 of DORA).
Spend the Window on Containment, Not Forms
The point of encoding the rule is simple: turn classification into a guided, minutes-long assessment with a defensible audit trail, so your team spends the 4-hour window on containing the incident and protecting clients rather than debating thresholds on a conference call.
Key Takeaways
- The gateway plus the combination rule: an incident is major only where it affects critical services (Article 6) AND either a successful malicious unauthorised access (Article 9(5)(b)) or two or more of the six thresholds is met.
- One threshold is not enough: economic impact over EUR 100,000, on its own, does not make an incident major - it is one of six thresholds, and you need two (or a qualifying malicious intrusion).
- 4-hour initial notification: the clock starts at classification, with a 24-hour absolute backstop from when you became aware, so you have at most about 20 hours to classify.
- Three-phase reporting: initial (4h), intermediate (72h), final (1 month), with deadlines set by Delegated Regulation (EU) 2025/301.
- Third-party outages count: if your provider goes down and your clients are affected, it is your incident to classify and report.
- Document every call: record the classification rationale for every incident, major or not - your incident register is examined by supervisors.
Frequently Asked Questions
What makes an ICT-related incident “major” under DORA?
Under Article 8 of the classification RTS (Delegated Regulation (EU) 2024/1772), an incident is major where it has affected critical services (the criticality gateway in Article 6) and either the Article 9(5)(b) threshold is met - a successful, malicious and unauthorised access to network and information systems that may result in data losses - or two or more of the six materiality thresholds in Article 9(1) to (6) are met. The gateway alone is not enough, and no single ordinary threshold is enough on its own.
What is the DORA incident reporting timeline?
Three phases, with deadlines set by Delegated Regulation (EU) 2025/301, Article 5. The initial notification is due as early as possible and within 4 hours of classifying the incident as major, and no later than 24 hours from becoming aware of it. The intermediate report is due within 72 hours of the initial notification. The final report is due no later than one month after the intermediate report.
Is the EUR 100,000 economic-impact figure a standalone trigger?
No. The economic-impact threshold in Article 9(6) is met where direct and indirect costs and losses exceed, or are likely to exceed, EUR 100,000 - but it is only one of six materiality thresholds. On its own, with the gateway met, it produces a single threshold, which is not sufficient. You need a second threshold, or a qualifying malicious unauthorised access under Article 9(5)(b). There is no revenue-percentage alternative to the EUR 100,000 figure.
Do third-party provider outages count as our incident?
Yes. If a cloud provider, payment processor, or other ICT third party suffers an outage that affects your services, clients, or transactions, it is your ICT-related incident to classify and, if it meets the test, to report. The classification criteria measure impact on your operations; an external root cause does not remove the obligation.
What is a “significant cyber threat” and must it be reported?
Under Article 10 of the RTS, a cyber threat is significant where, taken together: it could, if it materialised, affect critical or important functions of the entity (or other entities, providers, clients or counterparts); it has a high probability of materialising, judged on vulnerabilities, threat-actor capabilities and intent, and persistence; and, if it materialised, it could meet the criticality and materiality thresholds for a major incident. Reporting a significant cyber threat is voluntary under Article 19(2) of DORA, not mandatory.
Primary sources
This guide is drawn from the regulation and its technical standards: Regulation (EU) 2022/2554 (DORA, including Articles 18, 19 and 50); Commission Delegated Regulation (EU) 2024/1772 (RTS on the classification of major ICT-related incidents and significant cyber threats, including Articles 1 to 10); Commission Delegated Regulation (EU) 2025/301 (RTS on the content and time limits of incident reports, Article 5); and the European Banking Authority DORA pages for the ESAs’ incident-reporting standards. Always confirm the current text before relying on a specific figure or deadline.
This article is for informational purposes only and does not constitute legal or regulatory advice. Financial entities should consult their legal counsel and competent authorities for entity-specific guidance on DORA incident classification and reporting. Last reviewed: July 2026.
