---
title: "DORA major ICT incident thresholds: what triggers reporting?"
canonical_url: "https://www.sorena.io/artifacts/eu/digital-operational-resilience-act/faq/major-incident-thresholds"
source_url: "https://www.sorena.io/artifacts/eu/digital-operational-resilience-act/faq/major-incident-thresholds"
author: "Sorena AI"
description: "FAQ on DORA major ICT-related incident classification thresholds, recurring incidents, reporting triggers, and evidence inputs grounded in EU DORA RTS and ITS texts."
published_at: "2026-05-09"
updated_at: "2026-05-09"
keywords:
  - "DORA major ICT-related incident"
  - "DORA incident thresholds"
  - "EU DORA incident reporting"
  - "Delegated Regulation 2024/1772"
  - "Delegated Regulation 2025/301"
  - "EU DORA"
  - "major ICT-related incident"
  - "incident reporting"
  - "incident classification"
  - "financial services"
  - "cyber resilience"
---
**[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform

[Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io)

---

# DORA major ICT incident thresholds: what triggers reporting?

FAQ on DORA major ICT-related incident classification thresholds, recurring incidents, reporting triggers, and evidence inputs grounded in EU DORA RTS and ITS texts.

*FAQ* *EU DORA*

## DORA major ICT incident thresholds

A DORA incident is not reported as major just because it is disruptive; it must be classified against the EU criteria and materiality thresholds.

Use this FAQ to separate reportable major ICT-related incidents from ordinary incident handling, recurring non-major incidents, voluntary significant cyber-threat notifications, and evidence needed for the report file.

Under EU DORA, financial entities classify ICT-related incidents using the criteria in DORA Article 18 and the materiality thresholds in Delegated Regulation (EU) 2024/1772. A major classification triggers reporting to the relevant competent authority under DORA Article 19 and the later reporting time limits and templates. Timings in this page are source-linked; verify current legal source language before implementation decisions.

## What makes a DORA ICT-related incident major?

The first gate is critical-service impact. Delegated Regulation (EU) 2024/1772 treats an incident as major only where it affects critical services and either a successful malicious unauthorised access threshold linked to possible data loss is met, or at least two other materiality thresholds are met.

Critical-service impact is not limited to total outages. It includes ICT services or systems supporting critical or important functions, authorised or supervised financial services, and successful malicious unauthorised access to the financial entity's network and information systems.

- Start with the DORA Article 18 criteria: clients, financial counterparts and transactions; reputational impact; duration and downtime; geographical spread; data losses; criticality of services; and economic impact.
- Confirm whether the affected ICT service, system, or financial service supports a critical or important function before applying the major-incident gate.
- Do not invent lower internal numeric triggers and present them as DORA thresholds. Internal severity triggers can escalate review, but the DORA major classification should map back to the regulatory criteria.
- If actual client, counterparty, transaction, duration, downtime, or loss data is unavailable at classification time, use estimates based on available data and update the report when better figures are available.

Sources for this answer:

- [Regulation (EU) 2022/2554 (DORA)](https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX%3A32022R2554&ref=sorena.io) - Article 18 sets the incident classification criteria and Article 19 establishes reporting of major ICT-related incidents.
- [Delegated Regulation (EU) 2024/1772 on ICT incident classification](https://eur-lex.europa.eu/eli/reg_del/2024/1772/oj/eng?ref=sorena.io) - Specifies the major-incident classification rule, critical-service criterion, recurring incidents, and materiality thresholds.

## Which materiality thresholds should the incident team test?

Delegated Regulation (EU) 2024/1772 gives the main measurable thresholds. The incident team should record each criterion as met, not met, unknown, or estimated, and keep the data source for each answer.

Several criteria are not simple numeric tests. Reputational impact can be met through media coverage, repeated complaints, inability or likely inability to meet regulatory requirements, or likely material client or counterparty loss. Data-loss impact is assessed against availability, authenticity, integrity, and confidentiality.

- Clients: more than 10% of all clients using the affected service, or more than 100,000 affected clients, meets the client threshold.
- Financial counterparts: more than 30% of financial counterparts carrying out activities related to the affected service meets the threshold.
- Transactions: more than 10% of the daily average number of transactions or more than 10% of the daily average value of transactions related to the affected service meets the threshold.
- Duration and downtime: incident duration longer than 24 hours, or service downtime longer than 2 hours for ICT services supporting critical or important functions, meets the threshold.
- Geographical spread: impact in two or more Member States meets the threshold.
- Data losses: adverse impact on business objectives or regulatory compliance from availability, authenticity, integrity, or confidentiality loss meets the threshold; successful malicious unauthorised access that may result in data loss is separately material.
- Economic impact: direct and indirect costs and losses exceeding, or likely to exceed, EUR 100,000 meet the threshold.

Sources for this answer:

- [Delegated Regulation (EU) 2024/1772 on ICT incident classification](https://eur-lex.europa.eu/eli/reg_del/2024/1772/oj/eng?ref=sorena.io) - Articles 1 to 9 define how to measure client, transaction, reputation, duration, geographical, data-loss, critical-service, and economic impact thresholds.

## How do recurring incidents affect the threshold decision?

Recurring non-major incidents can become one major incident collectively. Delegated Regulation (EU) 2024/1772 applies this where the incidents occur at least twice within 6 months, have the same apparent root cause, and collectively satisfy the major-incident test.

Financial entities must assess recurring incidents monthly. The recurring-incident rule does not apply to microenterprises and to the financial entities listed in DORA Article 16(1), based on the RTS text.

- Track apparent root cause, affected service, classification criteria, timestamps, and recurrence count for incidents closed as non-major.
- Run a monthly recurrence review before treating repeated low-impact incidents as permanently non-reportable.
- If repeated incidents collectively meet the major-incident test, preserve the dates and times of occurrence because the final report template asks for recurring-incident information.

Sources for this answer:

- [Delegated Regulation (EU) 2024/1772 on ICT incident classification](https://eur-lex.europa.eu/eli/reg_del/2024/1772/oj/eng?ref=sorena.io) - Article 8 sets the recurring-incident conditions and monthly assessment requirement.
- [Implementing Regulation (EU) 2025/302 on incident report templates](https://eur-lex.europa.eu/eli/reg_impl/2025/302/oj/eng?ref=sorena.io) - The report template includes final-report fields for recurring non-major incidents and date/time of recurring incidents.

## What happens once the DORA major threshold is met?

Once the incident is classified as major, the reporting clock starts. Delegated Regulation (EU) 2025/301 requires the initial notification as early as possible, within 4 hours from major classification, and no later than 24 hours from awareness of the ICT-related incident. If classification as major happens later than 24 hours after awareness, the initial notification is due within 4 hours from that later classification.

The same RTS requires an intermediate report within 72 hours from the initial notification, updated intermediate reporting without undue delay when regular activities recover, and a final report no later than one month after the intermediate report or latest updated intermediate report. If a deadline cannot be met, the financial entity must inform the competent authority without undue delay and explain why before the relevant deadline.

- Initial notification evidence: incident reference code, detection date and time, classification date and time, incident description, classification criteria met, impacted Member States, discovery route, origin if available, business-continuity activation, and any reclassification.
- Intermediate report evidence: occurrence time, recovery time if applicable, how the classification criteria were fulfilled, incident type, threats and techniques, affected business processes and infrastructure, client financial-interest impact, other authority reporting, recovery actions, and indicators of compromise where applicable.
- Final report evidence: root cause, resolution summary, dates when the incident and root cause were resolved, direct and indirect costs and losses, recoveries, and recurring-incident information where applicable.
- Client communication is separate from competent-authority reporting: where a major ICT-related incident affects clients' financial interests, DORA requires informing affected clients without undue delay about the incident and mitigation measures.

Sources for this answer:

- [Regulation (EU) 2022/2554 (DORA)](https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX%3A32022R2554&ref=sorena.io) - Article 19 covers major ICT-related incident reporting, voluntary significant cyber-threat notification, and client information where financial interests are affected.
- [Delegated Regulation (EU) 2025/301 on incident reporting content and time limits](https://eur-lex.europa.eu/eli/reg_del/2025/301/oj/eng?ref=sorena.io) - Specifies the initial notification, intermediate report, final report contents, and reporting time limits.
- [Implementing Regulation (EU) 2025/302 on incident report templates](https://eur-lex.europa.eu/eli/reg_impl/2025/302/oj/eng?ref=sorena.io) - Provides the standard reporting fields and data glossary for major ICT-related incident reports.

## Primary sources

- [Regulation (EU) 2022/2554 (DORA)](https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX%3A32022R2554&ref=sorena.io) - Primary DORA text for incident classification criteria, competent-authority reporting, voluntary significant cyber-threat notification, and client communication.
  - Quote: "Classification of ICT-related incidents"
- [Delegated Regulation (EU) 2024/1772 on ICT incident classification](https://eur-lex.europa.eu/eli/reg_del/2024/1772/oj/eng?ref=sorena.io) - Grounds the major-incident test, recurring-incident rule, and materiality thresholds used on this page.
  - Quote: "Materiality thresholds for determining major incidents"
- [Delegated Regulation (EU) 2025/301 on incident reporting content and time limits](https://eur-lex.europa.eu/eli/reg_del/2025/301/oj/eng?ref=sorena.io) - Grounds the initial, intermediate, and final report contents and reporting time limits after major classification.
  - Quote: "initial notification, and for the intermediate and final reports"
- [Implementing Regulation (EU) 2025/302 on incident report templates](https://eur-lex.europa.eu/eli/reg_impl/2025/302/oj/eng?ref=sorena.io) - Grounds report-template evidence fields, including impact, root-cause, cost, recovery, indicators of compromise, and recurring-incident fields.
  - Quote: "DATA GLOSSARY AND INSTRUCTIONS"

## Topic Guides

- [DORA Critical or Important Functions: mapping ICT dependencies and evidence](/artifacts/eu/digital-operational-resilience-act/critical-and-important-functions.md): How DORA critical or important functions affect ICT service mapping, third-party contracts, register-of-information records, incidents, testing, and evidence.
- [DORA deadlines and compliance calendar for financial entities](/artifacts/eu/digital-operational-resilience-act/deadlines-and-compliance-calendar.md): Calendar the grounded DORA dates and recurring evidence: 17 January 2025 application, incident reporting clocks, register updates, annual reporting, TLPT cadence, and CTPP oversight milestones.
- [DORA ICT Third-Party Contract Remediation Workflow](/artifacts/eu/digital-operational-resilience-act/contract-remediation-workflow.md): A DORA workflow for remediating ICT third-party contracts covering critical or important functions, subcontracting, audit rights, exits, register updates, and evidence.
- [DORA ICT Third-Party Contracts FAQ](/artifacts/eu/digital-operational-resilience-act/faq/ict-third-party-contracts.md): What DORA requires in ICT third-party contracts, including critical or important functions, audit and access rights, termination, exit, subcontracting, register updates, and evidence.
- [DORA ICT third-party risk and contract clauses guide](/artifacts/eu/digital-operational-resilience-act/third-party-risk-and-contract-clauses.md): Source-grounded DORA guide for financial entities in scope, ICT third-party risk, contract clauses, subcontracting controls, register evidence, audit rights, exit planning, and oversight.
- [DORA incident classification forms: criteria, fields, and reporting clocks](/artifacts/eu/digital-operational-resilience-act/incident-classification-forms.md): Grounded guide to DORA ICT incident classification forms: major-incident criteria, significant cyber-threat notifications, report fields, time limits, evidence, and reclassification records.
- [DORA incident clock workflow: classification, reports, deadlines, and evidence](/artifacts/eu/digital-operational-resilience-act/incident-clock-workflow.md): Grounded DORA workflow for starting the major-incident reporting clock, classifying ICT incidents, submitting initial, intermediate, and final reports, and preserving authority evidence.
- [DORA major ICT incident reporting: classification, reports, and timing](/artifacts/eu/digital-operational-resilience-act/major-incident-reporting.md): Source-grounded DORA guide to major ICT-related incident classification, initial notifications, intermediate and final reports, competent authority routing, and significant cyber threat notifications.
- [DORA Register of Information FAQ: ICT Third-Party Arrangements](/artifacts/eu/digital-operational-resilience-act/faq/register-of-information.md): FAQ on the DORA register of information: who maintains it, which ICT third-party arrangements it covers, template fields, critical functions, reporting, data quality, and evidence.
- [DORA Register of Information Import and Build Workflow](/artifacts/eu/digital-operational-resilience-act/roi-import-and-build-workflow.md): Build a DORA register of information from procurement, vendor, contract, service, function, and subcontractor data using the official register templates and validation checks.
- [DORA Register of Information Template: ICT Provider Fields and Evidence](/artifacts/eu/digital-operational-resilience-act/dora-register-of-information-template.md): A grounded DORA register of information template for ICT third-party contracts, provider hierarchy, critical functions, dates, statuses, reporting, and evidence.
- [DORA TLPT selection: who can be required to test?](/artifacts/eu/digital-operational-resilience-act/faq/tlpt-selection.md): FAQ on DORA threat-led penetration testing selection: who identifies financial entities, what criteria are used, what the TLPT authority validates, and what evidence to keep.
- [DORA vs EBA outsourcing guidelines: ICT third-party risk comparison](/artifacts/eu/digital-operational-resilience-act/dora-vs-eba-outsourcing-guidelines.md): Compare binding DORA ICT third-party risk duties with the EBA/ESA outsourcing baseline for registers, critical functions, contracts, subcontracting, exit, incident reporting, and evidence.
- [DORA vs ISO 22301: ICT resilience and business continuity compared](/artifacts/eu/digital-operational-resilience-act/dora-vs-iso-22301.md): Compare DORA's binding ICT operational resilience duties for financial entities with ISO 22301's business continuity management system requirements.
- [DORA vs ISO/IEC 27001: legal ICT resilience obligations and ISMS controls](/artifacts/eu/digital-operational-resilience-act/dora-vs-iso-27001.md): Compare EU DORA and ISO/IEC 27001 across scope, governance, incident reporting, testing, ICT third-party risk, certification, evidence, overlap, and gaps.
- [DORA vs NIS2: financial-sector obligations, overlap, and evidence](/artifacts/eu/digital-operational-resilience-act/dora-vs-nis2.md): Compare DORA and NIS2 for financial entities, ICT providers, incident reporting, management accountability, third-party risk, supervisory routes, and reusable evidence.
- [DORA vs PSD2 incident reporting: major ICT and payment incidents](/artifacts/eu/digital-operational-resilience-act/dora-vs-psd2-incident-reporting.md): Compare DORA major ICT-related incident reporting with PSD2 major operational or security payment incident reporting, including scope, triggers, report stages, recipients, and evidence.
- [EU DORA Applicability Test for Financial Entities and ICT Providers](/artifacts/eu/digital-operational-resilience-act/applicability-test.md): A source-grounded DORA applicability test for financial-entity scope, ICT third-party services, critical or important functions, exclusions, proportionality, and evidence.
- [EU DORA Compliance Checklist for Financial Entities](/artifacts/eu/digital-operational-resilience-act/checklist.md): A source-grounded DORA checklist covering ICT risk governance, major incident reporting, resilience testing, TLPT, ICT third-party contracts, register-of-information records, and audit evidence.
- [EU DORA Compliance Obligations and Evidence Guide](/artifacts/eu/digital-operational-resilience-act/compliance.md): A source-grounded DORA compliance guide covering ICT risk management, incident reporting, resilience testing, TLPT, ICT third-party risk, registers, governance, oversight, and evidence.
- [EU DORA FAQ: scope, incidents, ICT contracts, testing, and evidence](/artifacts/eu/digital-operational-resilience-act/faq.md): Concise DORA FAQ covering who is in scope, proportionality, ICT third-party contracts, register-of-information records, major ICT incident thresholds and reporting, TLPT, testing, enforcement, and evidence.
- [EU DORA ICT risk management control baseline](/artifacts/eu/digital-operational-resilience-act/ict-risk-management-control-baseline.md): A source-grounded DORA control baseline for ICT risk governance, asset and dependency mapping, protection, detection, response, recovery, testing, third-party risk, and evidence.
- [EU DORA ICT subcontracting chain controls for critical functions](/artifacts/eu/digital-operational-resilience-act/subcontracting-chain-controls.md): DORA guide to ICT subcontracting chains for critical or important functions: prior assessment, contract conditions, register fields, monitoring, exit rights, and evidence.
- [EU DORA penalties and fines: enforcement powers and limits](/artifacts/eu/digital-operational-resilience-act/penalties-and-fines.md): Grounded guide to DORA enforcement: competent-authority powers, administrative penalties, remedial measures, publication rules, and Lead Overseer penalty payments for critical ICT third-party providers.
- [EU DORA Register of Information Data Model: templates, fields, and evidence](/artifacts/eu/digital-operational-resilience-act/register-of-information-data-model.md): Field-level guide to the EU DORA register of information data model: templates B_01 to B_07, provider identifiers, contract links, subcontracting chains, critical-function assessments, dates, and export evidence.
- [EU DORA Requirements Overview: ICT risk, incidents, testing, and third-party risk](/artifacts/eu/digital-operational-resilience-act/requirements.md): A grounded overview of the main EU DORA requirements for financial entities: governance, ICT risk management, incident reporting, resilience testing, TLPT, ICT third-party risk, register of information, oversight, proportionality, and evidence.
- [EU DORA Scope and Covered Entities: financial entities and ICT providers](/artifacts/eu/digital-operational-resilience-act/scope-and-covered-entities.md): Classify whether DORA applies to a financial entity, ICT third-party provider, group arrangement, branch, or critical ICT service dependency.
- [EU DORA Scope and Proportionality Workflow](/artifacts/eu/digital-operational-resilience-act/scope-and-proportionality-workflow.md): Classify DORA covered entities, simplified-framework status, critical or important functions, ICT dependencies, evidence records, and governance approvals.
- [EU DORA testing and TLPT readiness guide](/artifacts/eu/digital-operational-resilience-act/testing-and-tlpt-readiness.md): A grounded DORA guide for resilience testing, TLPT eligibility, authority interaction, test evidence, remediation plans, and avoiding unsupported testing cadence.
- [EU DORA TLPT eligibility workflow for financial entities](/artifacts/eu/digital-operational-resilience-act/tlpt-eligibility-workflow.md): Check how DORA TLPT authorities identify financial entities for threat-led penetration testing and what evidence supports scope, readiness, providers, and governance.
- [EU DORA TLPT Runbook: scope, providers, reports, and remediation](/artifacts/eu/digital-operational-resilience-act/tlpt-runbook.md): Build a DORA threat-led penetration testing runbook around authority coordination, scope validation, provider controls, active testing, closure reports, remediation, and attestation.
- [How does proportionality work under EU DORA?](/artifacts/eu/digital-operational-resilience-act/faq/proportionality.md): A grounded FAQ on DORA proportionality: what can be scaled, who may use the simplified ICT risk framework, what evidence supports the decision, and which duties cannot be waived.
- [How to build a DORA register of information](/artifacts/eu/digital-operational-resilience-act/register-of-information-how-to-build.md): Build a DORA register of information from contracts, ICT services, providers, functions, subcontractors, risk assessments, audit evidence, exit plans, and export checks.

*Recommended next step*

*Placement: before sources*

## Classify incidents against the DORA RTS before the reporting clock is missed

Use the cited sources listed here to verify obligations and the supporting evidence requirements.

- [Open Research Copilot for EU DORA](/solutions/research-copilot.md): Verify the following areas from the cited sources:  major ICT-related incident classification, reporting time limits, and evidence fields using the cited EU texts.
- [Review a DORA incident workflow](/contact.md): Map incident intake, classification, recurrence checks, competent-authority reporting, and client communication to the DORA RTS and ITS.


---

[Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us)

(c) 2026 Sorena AB (559573-7338). All rights reserved.

Source: https://www.sorena.io/artifacts/eu/digital-operational-resilience-act/faq/major-incident-thresholds