Learn
DORA’s incident reporting regime is, by design, the most time-pressured obligation in the entire regulation. Article 19 requires financial entities to submit an initial notification to their national competent authority (NCA) within 4 hours of classifying an ICT-related incident as “major” - and no later than 24 hours after the incident is first detected.
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 EBA’s Regulatory Technical Standards (RTS) on incident classification criteria (Commission Delegated Regulation (EU) 2024/1772), establishes a multi-criteria threshold test. The classification is not subjective - it is a structured assessment against seven quantitative and qualitative criteria, each with defined thresholds that determine whether an incident crosses the “major” line.
Getting this wrong has consequences in both directions. Under-report, and you face supervisory penalties, remediation orders, and reputational damage. Over-report, and you drown your NCA in noise, erode your credibility, and waste critical resources during an active incident. This guide gives you the exact criteria, thresholds, timelines, and decision logic you need to get classification right every time.
📈
Article 18 & RTS Criteria
The 7 Classification Criteria for Major Incidents
Under Article 18(1) of DORA, financial entities must classify ICT-related incidents based on seven criteria. The EBA RTS further specifies the quantitative thresholds and materiality conditions for each. An incident is classified as “major” if it meets the primary criterion (criticality of services affected) plus at least one additional criterion at or above the defined threshold.
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 of clients, financial counterparties and transactions affected; (b) the duration of the ICT-related incident; (c) the geographical spread; (d) the data losses that the 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; (g) the level of the institution’s internal escalation.”
The RTS refines criterion (g) from the regulation text, replacing “internal escalation” with “transaction value affected” as a more objective measure. Below is the definitive breakdown of each criterion with its major-incident threshold:
| # | Criterion | Major Incident Threshold | What to Measure |
|---|---|---|---|
| 1 | Clients / Counterparties Affected | > 10% of total clients using the affected service, OR > 100,000 clients in absolute terms | Count unique clients/counterparties unable to access or use the affected service. Include downstream impact through third-party channels (e.g., payment scheme participants). |
| 2 | Duration of Incident | > 2 hours for critical/important functions; > 24 hours for other services | Measured from detection (or when the entity should have detected it) to full service restoration. Includes degraded performance, not just total outage. |
| 3 | Geographical Spread | ≥ 2 EU Member States affected, OR impact on critical infrastructure in other jurisdictions | Assess whether clients/operations in multiple countries are impacted. Cross-border payment systems, clearing operations, and correspondent banking relationships amplify this criterion. |
| 4 | Data Losses | Any breach of confidentiality or integrity of data related to critical/important functions; OR availability loss already captured under duration | Consider all four data dimensions: availability, authenticity, integrity, and confidentiality. Data exfiltration, corruption, or unauthorised access automatically elevate severity. Cross-reference with GDPR personal data breach thresholds. |
| 5 | Criticality of Services Affected | Incident affects services supporting critical or important functions (as identified under Art. 3(22) of DORA) | This is the primary gateway criterion. You must first determine whether the affected service supports a critical/important function. If not, the incident cannot be classified as major regardless of other thresholds. |
| 6 | Economic Impact | Direct + indirect costs exceed whichever is lower: €100,000 or 0.1% of the entity’s annual net revenue | Direct costs: remediation, recovery, forensics, penalties. Indirect costs: lost revenue, client compensation, reputational damage, opportunity cost. Estimate early; refine in subsequent reports. |
| 7 | Transaction Value Affected | Transactions affected represent > 10% of average daily transaction value, OR the absolute value exceeds entity-specific materiality thresholds | Calculate the total value of transactions that failed, were delayed, or were processed incorrectly. Include pending settlement obligations. This criterion is especially relevant for payment institutions, CCPs, and CSDs. |
Critical Classification Logic
An incident is major when Criterion 5 (criticality of services) is met AND at least one of the other six criteria breaches its threshold. This is a conjunctive-then-disjunctive test: the gateway must be passed, then any single additional criterion triggers the classification. There is no weighting or scoring - one breach above threshold is sufficient.
⏰
Article 19 Obligations
The Three-Stage Reporting Timeline
Article 19 of DORA establishes a three-phase reporting obligation for major ICT-related incidents. Each phase has a strict deadline, mandatory content requirements, and must be submitted to the relevant NCA using the prescribed format. Understanding what “the clock” means at each stage is essential.
DORA Article 19(4)
“Financial entities shall submit to the competent authority: (a) an initial notification, without delay, but no later than 4 hours after the classification of the incident as major [...] and in any case no later than 24 hours from the moment the financial entity has detected the incident; (b) an intermediate report, no later than 72 hours after the initial notification [...]; (c) a final report, no later than one month after the intermediate report.”
| Report | Deadline | Required Content |
|---|---|---|
| Initial Notification | 4 hours after classification (max 24h after detection) | Entity identification (LEI, name, NCA reference); date/time of detection and classification; nature and type of incident; initial assessment of affected services, clients, and counterparties; whether the incident is recurring; preliminary impact assessment; any immediate actions taken; contact person details. |
| Intermediate Report | 72 hours after initial notification | Updated classification against all 7 criteria with quantified thresholds; status of containment and recovery activities; root cause analysis (preliminary, if not yet confirmed); updated client/counterparty impact numbers; geographical spread assessment; estimated economic impact; transactions affected (volume and value); any regulatory or contractual notification obligations triggered; updated remediation timeline. |
| Final Report | 1 month after intermediate report | Confirmed root cause analysis; full quantified impact assessment across all 7 criteria; total economic cost (direct + indirect); lessons learned and corrective actions; changes to ICT risk management framework; whether the incident revealed third-party provider failings; confirmation of client communications; audit trail of all actions taken during the incident lifecycle. |
The “Double Clock” Problem
Article 19(4)(a) creates two overlapping deadlines: 4 hours from classification and 24 hours from detection. This means you have a maximum of 20 hours to classify the incident before the absolute backstop kicks in. In practice, NCAs expect classification within 2-4 hours of detection for obvious major incidents.
Voluntary Notifications
Article 19(2) explicitly permits financial entities to voluntarily notify their NCA of “significant cyber threats” that did not result in a major incident. While optional, NCAs view voluntary reporting favourably and it demonstrates mature risk management. Some entities use this for near-misses.
What Happens When You Miss the Deadline
NCAs have the power to require remediation plans, impose administrative penalties, and - in serious cases - publicly disclose the failure. Under Article 50, competent authorities may impose penalties proportionate to the severity, duration, and impact of the non-compliance. For significant financial entities, a missed 4-hour window can trigger an on-site inspection. The reputational cost of being named as a late reporter often exceeds the administrative 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 gateway criterion must be assessed first, and the remaining criteria should be evaluated in parallel to minimise classification time.
Step 1 - Gateway: Criticality of Services (Criterion 5)
Does the incident affect an ICT service that supports a critical or important function as defined in your business impact analysis (BIA) and your register of information? If NO → the incident is not major under DORA. Log it, manage it, but no NCA reporting obligation. If YES → proceed to Step 2.
Step 2 - Assess All Remaining Criteria in Parallel
For each of the six remaining criteria, determine whether the threshold is met:
Clients affected: >10% or >100k?
Duration: >2h (critical) or >24h (other)?
Geography: ≥2 Member States?
Data losses: Confidentiality/integrity breach?
Economic impact: >€100k or >0.1% revenue?
Transaction value: >10% daily volume?
Step 3 - Classification Decision
If any one of the six criteria in Step 2 breaches its threshold → classify as MAJOR. The 4-hour NCA reporting clock starts now. If none of the six criteria breach → classify as not major. However, continue monitoring - incidents can escalate, and reclassification may be required.
Step 4 - Ongoing Reassessment
Incidents evolve. A minor incident at hour 1 may become major at hour 3 as impact propagates. Article 18(2) requires financial entities to continuously reassess the classification throughout the incident lifecycle. If an incident is reclassified from non-major to major, the 4-hour clock restarts from the moment of reclassification - but the 24-hour absolute backstop is measured from original detection.
📑
Incident Taxonomy
Major vs. Significant vs. Minor Incidents
DORA creates a clear hierarchy of ICT-related incidents. Only “major” incidents trigger the mandatory NCA reporting obligation, but all incidents must be logged, managed, and available for supervisory review. Understanding the boundaries between categories prevents both over-reporting and dangerous under-classification.
| Dimension | Major Incident | Significant Incident | Minor Incident |
|---|---|---|---|
| Classification trigger | Criterion 5 + ≥1 other threshold breached | Critical service affected but no secondary threshold breached | No critical service affected, or impact below all thresholds |
| NCA reporting required? | Yes - mandatory | No (but recommended to document for supervisory review) | No |
| Reporting timeline | 4h / 72h / 1 month | Internal SLA only | Internal SLA only |
| Management body involvement | Mandatory notification to board (Art. 17(3)) | Recommended escalation to CISO/CRO | Operational team handles |
| Client notification | Required if incident impacts client interests (Art. 19(3)) | Case-by-case basis | Generally not required |
| Root cause analysis | Mandatory, included in final report | Expected under Art. 17 process | Best practice, not mandated |
| Documentation retention | Full audit trail, 5+ years | Internal records, supervisory access | Internal records |
Why “Significant” Still Matters
Even though significant incidents don’t trigger NCA reporting, they must be captured in your ICT-related incident management process under Article 17. Supervisory authorities review your full incident register during examinations, and a pattern of misclassified “significant” incidents that should have been “major” will raise immediate red flags. Build a defensible classification audit trail for every incident, regardless of severity.
🏛️
Regulatory Mechanics
NCA Reporting: Who, Where, and How
The reporting destination is your home NCA - the competent authority that has granted or registered the financial entity’s authorisation. For banks, this is typically the national banking supervisor (e.g., BaFin in Germany, AMF/ACPR in France, DNB in the Netherlands, CBI in Ireland). For payment institutions, it’s the relevant payment services supervisor. For cross-border groups, the home NCA of the parent entity coordinates with host supervisors.
Reporting Format
The EBA ITS (Implementing Technical Standards) on incident reporting prescribe a standardised template. Each phase (initial, intermediate, final) uses a structured form with designated fields. Free-text narratives supplement the structured data. Submission via the NCA’s designated reporting portal or secure channel.
Single Point of Contact
Article 19(5) requires financial entities to designate a single member of senior management responsible for incident notifications. This person must be empowered to escalate, classify, and submit reports without waiting for committee approvals. Pre-designate deputies for 24/7 coverage.
Cross-Border Coordination
For incidents affecting multiple Member States, the home NCA will share notifications with relevant host NCAs and ESAs (EBA, EIOPA, ESMA). You report to one NCA; they coordinate the rest. However, you must flag the cross-border dimension in your report.
Parallel Notification Obligations
A major ICT incident may also trigger obligations under other regimes: GDPR (Article 33, 72-hour breach notification), NIS2 (if the entity is an essential/important entity), PSD2 (for payment service providers). Each framework has its own timeline and NCA. Ensure your incident response process maps all parallel obligations.
Practical Tip: Pre-Stage Your Reports
Pre-populate the initial notification template with static entity data (LEI, NCA reference, authorisation details, key contact names, standard service descriptions) so that during a live incident, your team only needs to fill in incident-specific fields. This alone can save 30-45 minutes of the 4-hour window - time that should be spent on containment and assessment, not form-filling.
⚠️
Pitfalls to Avoid
6 Common Classification Mistakes
After reviewing incident management practices across dozens of EU financial institutions, these are the classification errors we see most frequently - and the consequences of each.
Mistake 1: Waiting for Full Impact Data Before Classifying
Teams delay classification until they have definitive client counts, economic impact figures, or confirmed root causes. But DORA does not require certainty - it requires a reasonable assessment. The initial notification explicitly allows preliminary data. Waiting for perfection burns through your 4-hour window and risks breaching the 24-hour absolute backstop. Classify on best-available information, then refine in subsequent reports.
Mistake 2: Confusing “ICT Incident” with “Cybersecurity Incident”
DORA’s scope is broader than cybersecurity. Article 3(8) defines “ICT-related incident” as any unplanned event or series of events that compromises the security of network and information systems and has an adverse impact on their availability, authenticity, integrity, or confidentiality. This includes hardware failures, software bugs, configuration errors, cloud provider outages, and capacity exhaustion - not just ransomware and data breaches. Many entities fail to flag infrastructure incidents to their classification process.
Mistake 3: Missing the Gateway Criterion
Criterion 5 (criticality of services) is the mandatory gateway, but many entities have not completed the prerequisite: mapping their ICT services to their critical and important functions. Without this mapping, classification becomes guesswork. Before DORA’s application date, every financial entity should have a definitive register linking each ICT service to its business function criticality assessment. This mapping comes directly from the business impact analysis required under Article 11.
Mistake 4: Treating Third-Party Outages as “Not Our Incident”
When a cloud provider, payment processor, or SaaS vendor suffers an outage that impacts your services, it is your ICT-related incident for classification purposes. DORA is clear: the classification criteria assess impact on your clients, your services, and your transactions. The root cause being external does not exempt you from reporting. In fact, Article 28 and the third-party risk management framework 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 degradation at 09:00 might affect only internal systems; by 11:00, customer-facing APIs may be timing out across three countries. Teams that classify once and don’t reassess miss the reclassification obligation and blow through their reporting window. Build reassessment checkpoints into your incident management playbook - at minimum, every 30 minutes for the first 4 hours of any incident affecting ICT infrastructure.
Mistake 6: Failing to Coordinate DORA + GDPR + NIS2 Notifications
A single incident can trigger reporting obligations under DORA (4h to NCA), GDPR (72h to DPA), and NIS2 (24h to CSIRT). Each has different thresholds, different NCAs, and different content requirements. Entities that manage these in separate silos inevitably send inconsistent information to different regulators - a red flag that invites scrutiny. Integrate all regulatory notification obligations into a single incident response workflow with a unified classification engine.
🔍
Applied Classification
Real-World Scenarios: Major or Not?
Theory is clean. Reality is messy. Here are four scenarios that test the classification criteria in practice. Each walks through the gateway test and secondary criteria assessment.
| Scenario | Key Facts | Criteria Analysis | Classification |
|---|---|---|---|
| Cloud provider outage hits online banking | AWS region outage, 3.5 hours, 45,000 retail customers unable to access mobile/web banking, single country | Gateway: Online banking = critical function. Duration: 3.5h > 2h threshold. Clients: 45k (may be <10% for large bank but exceeds duration threshold alone) | MAJOR |
| Internal HR system ransomware | Ransomware encrypts HR/payroll system, employee data potentially exfiltrated, 48h to restore, no customer-facing impact | Gateway: HR system likely not mapped as critical/important function for DORA purposes. Classification depends entirely on your BIA. If not critical → not major under DORA (but still a GDPR breach). | LIKELY NOT MAJOR |
| Payment processing degradation | Card payment processing at 60% capacity for 90 minutes, €2.3M in transactions delayed, clients in DE and NL affected | Gateway: Payment processing = critical. Duration: 90 min < 2h, borderline. Geography: 2 Member States. Transactions: Assess against daily volume. Gateway + geography likely triggers classification. | MAJOR |
| DDoS attack on website | DDoS takes corporate website offline for 4 hours, no impact on trading/banking/payment systems, marketing site only | Gateway: Corporate marketing website is not a critical or important function. No customer service disruption. No data loss. No transaction impact. Gateway not met. | NOT MAJOR |
The Grey Zone
Most classification disputes live in the grey zone: incidents that clearly affect critical services but where the secondary criteria are borderline. The EBA RTS guidance on this is explicit - when in doubt, classify as major and refine later. An over-report that gets downgraded in the intermediate report is far less damaging than an under-report discovered by the NCA after the fact. Document your classification rationale regardless of the outcome.
⚡
Platform Capability
How Venvera Automates Incident Classification
When 240 minutes is all you have, you cannot afford to spend 120 of them figuring out whether you need to report. Venvera’s DORA incident management module is purpose-built for this exact challenge. It encodes the full Article 18 classification criteria, the RTS thresholds, and the three-phase reporting timeline into an automated workflow that reduces classification time from hours to minutes.
Auto-Classification Engine
Input incident parameters (affected services, duration estimate, client count, geographic reach) and the engine evaluates all 7 criteria against the RTS thresholds in real time. Classification recommendation with confidence level and regulatory justification generated instantly.
Critical Function Mapping
Pre-configured mapping between your ICT services, business functions, and criticality assessments from your Register of Information. The gateway criterion (Criterion 5) is evaluated automatically based on which service is affected.
Deadline Countdown & Alerts
From the moment an incident is logged, visual countdown timers track the 4-hour initial notification window, 72-hour intermediate report deadline, and 1-month final report due date. Automated escalation alerts at 50%, 75%, and 90% of each deadline.
NCA Report Generation
Pre-populated report templates in the EBA ITS format. Entity identification, static data, and service mappings are filled automatically. Incident-specific fields are structured for rapid completion. Export-ready for NCA submission portals.
Reclassification Monitoring
As you update incident parameters during an active event, the classification engine continuously re-evaluates. If a non-major incident crosses a threshold, immediate alerts and automatic reclassification ensure you never miss the reporting window.
Multi-Framework Coordination
A single incident triggers parallel assessment under DORA, GDPR, and NIS2 simultaneously. The platform maps each framework’s threshold, identifies all required notifications, and tracks each deadline independently - all from one incident record.
Classification Audit Trail
Every classification decision, every parameter change, every reassessment is logged with timestamps and user attribution. When the NCA asks “why did you classify this incident as non-major?”, you have a defensible, time-stamped record of your reasoning.
Root Cause Taxonomy
Structured root cause analysis aligned with the EBA taxonomy for ICT-related incidents. Ensures your final report uses the correct categorisation expected by supervisors, and feeds into your risk assessment process for ICT risk management under Article 6.
From Detection to Classification in Under 15 Minutes
Financial entities using Venvera’s incident module have reduced their average classification time from 2-3 hours (manual spreadsheet-based assessment) to under 15 minutes. That reclaims over 80% of the 4-hour window for what actually matters: containing the incident and minimising client impact, rather than filling out forms and debating thresholds in conference calls.
Key Takeaways
- 7 criteria, 1 gateway: Criterion 5 (criticality of services) must be met before any other threshold triggers “major” classification.
- 4-hour initial notification: Clock starts at classification, but the 24-hour absolute backstop runs from detection. You have maximum 20 hours to classify.
- Three-phase reporting: Initial (4h), Intermediate (72h), Final (1 month). Each has mandatory content requirements defined in the EBA ITS.
- Third-party outages count: If your provider goes down and your clients are affected, it is your incident to classify and report.
- When in doubt, report: Over-reporting is recoverable. Under-reporting triggers supervisory scrutiny.
- Pre-populate templates: Static entity data should be ready before an incident occurs. Do not waste crisis time on form-filling.
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 obligations. Published March 2026. References: Regulation (EU) 2022/2554 (DORA), Commission Delegated Regulation (EU) 2024/1772 (RTS on incident classification), EBA/ITS on incident reporting templates.
