How to Classify a Major ICT-Related Incident Under DORA: Thresholds and Timelines

Under DORA, an ICT-related incident is major when it has affected critical services and either meets the data-loss threshold for a successful, malicious and unauthorized access, or meets two or more of the other materiality thresholds, such as costs and losses above EUR 100,000 or downtime above 2 hours for ICT services supporting critical or important functions. Once you classify it as major, the initial notification is due within 4 hours of classification and no later than 24 hours after you became aware of the incident. Here is how the test works, step by step, with the exact references from Commission Delegated Regulation (EU) 2024/1772 and (EU) 2025/301.

Who this applies to, and why US groups should care

DORA, Regulation (EU) 2022/2554, has applied since 17 January 2025. Its incident rules bind "financial entities" listed in Article 2(1), points (a) to (t): credit institutions, payment and e-money institutions, investment firms, crypto-asset service providers, CSDs, CCPs, trading venues, fund managers, insurers, IORPs, crowdfunding platforms and others. If your US-headquartered group owns an EU-authorized bank, broker-dealer subsidiary, payment institution or insurer, that EU entity is the one that classifies and reports. The parent's own US obligations are a separate matter that the sources indexed in the DORA knowledge base do not cover.

If you are a US cloud, SaaS or managed-services company serving EU financial clients, the classification duty is theirs, not yours. But you will be asked for facts fast: start time, affected services, number of affected users, data impact. DORA Article 19(5) also lets a financial entity outsource the reporting itself to a third-party service provider, while it "remains fully responsible" for meeting the requirements.

Step 1: Is it an ICT-related incident at all?

Article 3(8) of DORA defines an ICT-related incident as a single event or a series of linked events, unplanned by the financial 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 the financial entity provides. A major ICT-related incident (Article 3(10)) is one with a high adverse impact on the systems that support critical or important functions.

A frequent gray area is customer phishing. In Q&A 2025_7613 (final answer published on 6 February 2026), the ESAs said a phishing incident in the customer's private sphere that does not affect the services the financial entity provides, directly or through its third-party providers, is not an ICT-related incident under DORA, so it cannot trigger the major-incident thresholds. By contrast, if the financial entity itself is successfully targeted (for example, phishing emails sent to employees lead to an intrusion) or a wide phishing campaign ends up affecting its services, the incident can qualify and may become major if it reaches the thresholds.

Step 2: The critical-services gate

Article 8(1) of RTS 2024/1772 makes one criterion mandatory: the incident must have affected critical services as defined in Article 6. That is the case where the incident:

• affects or has affected ICT services or network and information systems that support critical or important functions of the financial entity;
• affects or has affected financial services that require authorization or registration, or that are supervised by competent authorities; or
• constitutes or has constituted a successful, malicious and unauthorized access to the entity's network and information systems.

If none of the three applies, the incident is not major, whatever its other effects. If one applies, move on to the materiality thresholds in Article 9.

Step 3: The six materiality thresholds

An incident that passes the gate is major where either the data-loss threshold in Article 9(5)(b) is met (a successful, malicious and unauthorized access that may result in data losses), or at least two of the other thresholds in Article 9(1) to (6) are met.

How to measure duration and downtime

Article 3 of the RTS is precise. Duration runs from the moment the incident occurs until it is resolved; if you cannot tell when it occurred, from detection; and if you learn it started before detection, from the moment it shows up in logs or other data sources. Service downtime runs from the moment the service is fully or partially unavailable to clients, counterparts or internal or external users, until regular activities are restored to the pre-incident service level. Where you do not yet know when the incident will be resolved, you estimate.

How to count the EUR 100,000

Article 7 lists what goes into the economic impact, without accounting for financial recoveries: expropriated funds, replacement or relocation of hardware and software, staff costs (including overtime), contractual non-compliance fees, customer redress, forgone revenues, communication costs, and advisory costs such as legal, forensic and remediation services. It excludes day-to-day costs: general maintenance, keeping staff skills up to date, post-incident upgrades and insurance premiums. Q&A 2025_7439 adds that overtime compensated with time off instead of pay still counts as a staff cost if it can clearly be attributed to the incident.

Recurring incidents: when small glitches add up

Article 8(2) catches the slow-burn problem. Incidents that are individually not major are treated as one major incident where they meet all three conditions: they occurred at least twice within 6 months, they have the same apparent root cause, and they collectively meet the major-incident criteria. You must assess recurring incidents monthly. This paragraph does not apply to microenterprises or to entities under the Article 16(1) simplified framework.

The reporting clock: 4 hours, 24 hours, 72 hours, one month

Article 5 of RTS 2025/301 sets the time limits for the three reports required by DORA Article 19(4):

1. Initial notification: as early as possible, and in any case within 4 hours from classifying the incident as major, and no later than 24 hours from the moment you became aware of it. If you only classify it as major after those 24 hours, you have 4 hours from that classification.
2. Intermediate report: at the latest within 72 hours from submitting the initial notification, even if nothing has changed, plus an updated intermediate report without undue delay and in any case once regular activities have been recovered.
3. Final report: no later than one month after the intermediate report or, where applicable, the latest updated intermediate report.

If a deadline falls on a weekend or a bank holiday in the entity's Member State, the report may be filed by noon of the next working day. That relief does not cover initial notifications or intermediate reports from credit institutions, central counterparties, trading venue operators and entities identified as essential or important under NIS2, and a competent authority may withdraw it for other significant or systemic entities. If you cannot meet a deadline, you must tell the authority, with reasons, before the deadline expires.

A first-hours checklist and common mistakes

• Record detection time and, if known, occurrence time; you will need both (RTS 2025/301, Articles 2 and 3).
• Map the affected service to your list of critical or important functions before anything else.
• Check the data-loss threshold early: a confirmed malicious unauthorized access that may result in data losses can make the incident major on its own.
• Start a cost log on day one, including unpaid overtime, and do not net off insurance recoveries.
• Check your recurring-incident log: is this the second event with the same root cause in 6 months?
• Do not wait for root-cause analysis to file the initial notification; the final report is where root causes go.

The most common mistake is to treat "major" as a judgment call. It is a rules-based test, and the sources leave little room once the facts are known. The second is to underestimate economic impact by counting only invoices. Teams that need to check a specific threshold quickly can query the DORA base directly, for example: "Once we classify an incident as major, how much time do we have to send the initial notification, and what about the intermediate and final reports?"

This article explains the rules and is not legal advice. For decisions, rely on the official texts on EUR-Lex: RTS 2024/1772 and EUR-Lex: RTS 2025/301.