DORA Major Incident Classification: Thresholds and Reporting Timelines Explained

DORA treats an ICT-related incident as major when it has hit critical services and either involves a successful, malicious and unauthorised access that may result in data losses, or crosses at least two other materiality thresholds, such as more than 10% of a service's clients affected, 2 hours of downtime on a service supporting a critical or important function, or EUR 100,000 of costs and losses. The initial notification is then due within 4 hours of that classification, and no later than 24 hours after the firm became aware of the incident. This guide sets out the test and the clock, with references to the EU texts.

A word on scope for UK readers

DORA, Regulation (EU) 2022/2554, is EU law. It has applied since 17 January 2025 to the financial entities listed in its Article 2(1): credit institutions, payment and e-money institutions, investment firms, insurers, fund managers, CSDs, CCPs, trading venues and others authorised in the EU. It is not part of UK law. For a UK-headquartered group, it bites on the group's EU-authorised entities, which must classify and report their own incidents to their EU competent authority. Any UK requirements on your UK-regulated activities sit outside the sources in the DORA knowledge base, which contains only EU texts and ESAs guidance, so this article says nothing about them.

UK technology firms supplying EU banks, insurers or investment firms are in a different position: they do not classify incidents for their clients, but their clients will need facts from them within hours. Under Article 19(5) of DORA, a financial entity may even outsource its reporting to a third-party service provider, though it remains fully responsible for compliance.

First question: is this an ICT-related incident?

DORA Article 3(8) defines an ICT-related incident as a single event or series of linked events, unplanned by the financial entity, which 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 entity's services.

Phishing aimed at customers is the classic borderline case. The joint ESAs answer to Q&A 2025_7613, published on 6 February 2026, says that where a phishing incident in the customer's private sphere does not affect services provided by the financial entity, directly or via its third-party providers, it does not qualify as an ICT-related incident, and so cannot trigger the major-incident thresholds. If the firm itself is successfully targeted, for instance through phishing emails to staff leading to an intrusion, or a large campaign ends up affecting its services, it can qualify.

The two-stage test in RTS 2024/1772

Commission Delegated Regulation (EU) 2024/1772 turns DORA's Article 18 criteria into a mechanical test. Article 8(1) requires, first, that the incident has affected critical services under Article 6, meaning it:

• affects ICT services or network and information systems supporting critical or important functions;
• affects financial services that require authorisation or registration or are supervised by competent authorities; or
• is a successful, malicious and unauthorised access to the firm's network and information systems.

Second, the incident must either meet the data-loss threshold in Article 9(5)(b) on its own, or meet two or more of the other thresholds in Article 9(1) to (6).

Measuring the inputs properly

Duration and downtime

Under Article 3 of the RTS, duration runs from occurrence to resolution. If occurrence cannot be pinned down, measure from detection; if logs show the incident began before detection, measure from the first log record. Downtime runs from when the service becomes fully or partially unavailable to when regular activities are restored to the pre-incident level. Estimates are expected where the end point is not yet known.

Costs and losses

Article 7 counts direct and indirect costs before any financial recoveries: stolen or expropriated funds, replacement of hardware and software, staff costs, contractual penalties, customer redress, forgone revenue, communications and advisory fees (legal, forensic, remediation). Routine maintenance, routine training, post-incident upgrades and insurance premiums are excluded. The ESAs confirmed in Q&A 2025_7439 that overtime repaid as time off in lieu, and working time clearly allocated to handling the incident, still count as staff costs.

Recurring incidents

Under Article 8(2), incidents that are not major individually are treated as one major incident if they occurred at least twice within 6 months, share the same apparent root cause and together meet the Article 8(1) criteria. The assessment must be run monthly. Microenterprises and firms under the Article 16(1) simplified framework are outside this rule.

The reporting timetable

Commission Delegated Regulation (EU) 2025/301, Article 5, fixes the deadlines for the three reports in DORA Article 19(4):

1. Initial notification: as early as possible; at the latest 4 hours after classification as major, and no later than 24 hours after becoming aware of the incident. Where classification only happens after 24 hours, the 4 hours run from classification.
2. Intermediate report: within 72 hours of the initial notification, even if nothing has changed; then an updated report without undue delay, and in any case once regular activities are recovered.
3. Final report: within one month of the intermediate report or, where applicable, the latest updated intermediate report.

Note for UK-based teams: the weekend relief in Article 5(4) refers to a weekend day or bank holiday in the Member State of the reporting financial entity, not to UK bank holidays. Where it applies, the report may go in by noon on the next working day. It never applies to initial or intermediate reports from credit institutions, CCPs, trading venue operators or NIS2 essential or important entities, and competent authorities may disapply it for other significant or systemic firms. A firm that cannot meet a deadline must say so, with reasons, before the deadline passes.

Checklist for the incident bridge

• Log detection time and best estimate of occurrence time.
• Confirm whether the affected service supports a critical or important function.
• Rule the data-loss threshold in or out early; it can make the incident major by itself.
• Count affected clients against the service's total, not the firm's total client base.
• Open a cost ledger immediately, including time off in lieu.
• Check the incident log for a same-root-cause event in the past 6 months.
• Identify which EU competent authority receives the report, and whose bank holidays apply.

If your team needs a quick, sourced answer during an incident, you can put the question straight to the DORA knowledge base, for instance: "If the same minor glitch keeps recurring but never individually crosses the major-incident threshold, can it still become reportable?"

This is an explanation of the rules, not legal advice. Check the official texts: RTS 2024/1772 on EUR-Lex and RTS 2025/301 on EUR-Lex.