DORA Major Incident Classification: The RTS 2024/1772 Gate, Six Thresholds, Recurring Incidents and the 2026 ESA Clarifications

An ICT-related incident is major under DORA when two things are true at once. It has affected critical services as set out in Article 6 of Commission Delegated Regulation (EU) 2024/1772, and it either meets the materiality threshold in Article 9(5)(b) (successful, malicious and unauthorised access that may result in data losses) or meets two or more of the other materiality thresholds in Article 9. That is the whole test in Article 8(1). The rest of the RTS is measurement: how to count clients, when the duration clock starts, which costs go into the 100 000 euro figure.

Lists of the criteria are easy to find. This guide works through the parts that decide real cases: how wide the critical-services gate is after two Joint ESAs answers, how the two routes count, the recurring-incident rule that turns several small incidents into one report, and the places where the text supports two readings. Legal quotations are taken from the EUR-Lex text, including a 2025 corrigendum to Delegated Regulation 2024/1774 that corrected its cross-reference to the recurring rule.

Who classifies under RTS 2024/1772, and what changes by entity type

In plain terms: every financial entity under DORA classifies its ICT-related incidents against the same criteria. Only the recurring-incident rule depends on the type of entity.

Entity	Single-incident test (Art. 8(1))	Recurring-incident test (Art. 8(2))
Financial entities under DORA’s full ICT risk framework	Yes	Yes, assessed monthly
Microenterprises: fewer than 10 persons and annual turnover and/or balance sheet total not above EUR 2 million; trading venues, central counterparties, trade repositories and central securities depositories can never be one (DORA Art. 3(60))	Yes	No
Article 16(1) entities, such as small and non-interconnected investment firms, exempted payment institutions, exempted electronic money institutions and small institutions for occupational retirement provision	Yes	No
Credit institutions, payment institutions, account information service providers and electronic money institutions	Yes; recital 1 notes that the harmonised reporting also covers their operational or security payment-related incidents	Yes, unless micro or Article 16(1)
Entities under NIS2 but not DORA	No: a different test applies, see our NIS2 incident classification guide	Not applicable

The duty to classify comes from DORA (Regulation (EU) 2022/2554) itself. Article 17(2) requires financial entities to “record all ICT-related incidents and significant cyber threats”, and Article 17(3)(b) requires procedures to “classify ICT-related incidents” according to the Article 18(1) criteria. Only major incidents are reported (Article 19(1)). A “not major” result is still an output of the process, and it matters later: the recurring-incident test can only run on records of incidents that were classified as not major.

Step 1: the critical-services gate is wider than its name

In plain terms: an incident passes the gate if it touches any one of three things, and the ESAs have read two of them broadly.

Article 6 asks whether the incident:

Limb	Text of Article 6	What usually trips it
(a)	“affects or has affected ICT services or network and information systems that support critical or important functions of the financial entity”	Any outage or degradation of a system on the entity’s list of systems supporting critical or important functions
(b)	“affects or has affected financial services provided by the financial entity that require authorisation, registration or that are supervised by competent authorities”	Any impact on a licensed client-facing service: payments, deposits, trading, insurance cover
(c)	“constitutes or has constituted a successful, malicious and unauthorised access to the network and information systems of the financial entity”	Any confirmed intrusion, on any system

Are the three limbs cumulative? The industry association AFME asked exactly that in 2024, warning that if any one limb sufficed, the second would make “almost every incident at a regulated entity” major. The Joint ESAs answer in Q&A 2024_7047 (final 11 December 2024) settled it: any one limb is enough. In its words, “an impact on any of the components listed in Article 6 of the Delegated Regulation should be considered as affecting critical services.”

Limb (c) was tested next. A competent authority asked whether it covers access to systems that support no critical or important function, pointing out that DORA’s own definition of a major ICT-related incident (Article 3(10)) refers to systems “that support critical or important functions”. In Q&A 2026_7779 (final 2 October 2026), the Joint ESAs answered that such access “must be assessed independently for the purpose of determining the criticality of the services affected”, “regardless of whether the compromised network and information systems support critical or important functions or whether the access to the financial entity’s network or systems was gained through the network and information systems of an ICT third-party service provider.”

The practical effect: for most regulated entities, the gate filters out little. The incidents that fail it are internal ones that touch no system supporting a critical or important function, no authorised, registered or supervised service, and involve no successful malicious access, such as an accidental outage of an internal analytics tool. For everything else, the Article 9 thresholds do the real work. The ESAs’ staff instructions of September 2026 (discussed below) add that the critical-services criterion “must always be fulfilled” and that reports are expected to name “critical services affected” explicitly among the criteria in field 2.5 of the reporting template.

Step 2: the six materiality thresholds in Article 9

In plain terms: the RTS defines seven classification criteria in Articles 1 to 7, and six of them carry a materiality threshold in Article 9. Critical services has none, because it is the gate.

Criterion (measured under)	Threshold met where	Measurement detail that changes results
Clients, financial counterparts and transactions (Art. 1)	Any of: affected clients above 10% of all clients using the affected service, or above 100 000; affected counterparts above 30%; affected transactions above 10% of the daily average number or value for the service; clients or counterparts identified as relevant under Art. 1(3) affected (Art. 9(1))	Clients include third parties explicitly covered by the contract as beneficiaries of the service (Art. 1(1)). Where actual numbers cannot be determined, estimate from comparable reference periods (Art. 1(5))
Reputational impact (Art. 2)	Any of: reflected in the media; repetitive complaints from different clients or counterparts; unable, or likely unable, to meet regulatory requirements; will or is likely to lose clients or counterparts with a material impact on its business (Art. 9(2))	Art. 2(2) asks for the level of visibility the incident has gained “or is likely to gain”, so the assessment can change as coverage grows
Duration and service downtime (Art. 3)	Duration longer than 24 hours, or service downtime longer than 2 hours for ICT services that support critical or important functions (Art. 9(3))	Duration runs from occurrence to resolution. If the moment of occurrence is unknown, from detection; if the entity learns the incident began before detection, from the moment it is recorded in network or system logs or other data sources (Art. 3(1))
Geographical spread (Art. 4)	Impact in “two or more Member States in accordance with Article 4” (Art. 9(4))	Whether the home Member State counts is an open reading, see below
Data losses (Art. 5)	(a) an impact on availability, authenticity, integrity or confidentiality that harms business objectives or the ability to meet regulatory requirements; or (b) “any successful, malicious and unauthorised access not covered by point (a)” where it “may result in data losses” (Art. 9(5))	Point (b) needs no proof that data was taken, only that the access may result in data losses
Economic impact (Art. 7)	Costs and losses “have exceeded or are likely to exceed 100 000 euro” (Art. 9(6))	Counted “without accounting for financial recoveries”; excludes routine maintenance, post-incident upgrades and insurance premiums (Art. 7(1) and (2))

Two details are easy to miss. First, the 2-hour downtime limb applies only to ICT services that support critical or important functions, while the 24-hour duration limb applies to any incident. Second, the economic figure is counted before recoveries: money recovered after the incident is not deducted from the 100 000 euro test.

Two routes to “major”: how Article 8(1) counts

In plain terms: with the gate passed, one threshold is enough if it is the access threshold; otherwise two are needed.

Article 8(1) gives two conditions after the gate: “(a) the materiality threshold referred to in Article 9(5), point (b), is met; (b) two or more of the other materiality thresholds referred to in Articles 9(1) to (6) are met.” Point 9(5)(a), the data-impact limb, sits inside Article 9(5), so on the text it counts as one of the “other” thresholds for route (b).

What is the counting unit? Each paragraph of Article 9 defines “the materiality threshold for the criterion”, and paragraphs 9(1), 9(3) and 9(5) say it “is met where any of the following conditions are fulfilled”. On that wording, 12% of clients affected and 15% of transaction value affected are one threshold, not two, because both sit in Article 9(1). The opposing reading leans on Article 8(1)(a), which calls a single lettered point, 9(5)(b), “the materiality threshold”. In our reading the per-criterion count has the stronger textual support, but document whichever count you apply.

The scenarios below are illustrations we built to apply the text, not cases from any authority.

Scenario	Gate (Art. 6)	Thresholds met	Result
A. An attacker logs into a back-office HR server with stolen credentials. The server supports no critical or important function; investigators cannot rule out data access	Limb (c), per Q&A 2026_7779	9(5)(b): the access may result in data losses	Major through route (a)
B. Mobile banking is down for 3 hours; 12% of app users cannot log in; no media coverage. The entity lists mobile banking as supporting a critical function	Limbs (a) and (b)	9(1) (12% of clients) and 9(3) (downtime over 2 hours)	Major through route (b)
C. The same outage lasts 90 minutes, but a national news site reports it	Limbs (a) and (b)	9(1) and 9(2) (media)	Major through route (b): the news story supplies the second threshold
D. An internal analytics platform is down for 30 hours after a failed patch; it supports no critical function or licensed service, and no one broke in	Not met	9(3) (duration over 24 hours)	Not major: fails the gate. Record it for the monthly recurring check
E. Card authorisations fail for 70 minutes for 4% of clients (under 100 000), in the home Member State and one other; a trade publication covers it	Limb (b)	9(2) (media); 9(4) depends on the reading	Major or not major, depending on whether the home Member State counts

Scenario C shows why reputational impact matters. Media coverage has no reach qualifier in Article 2(1)(a), so a short outage that reaches the news can pass route (b) with a client count that would not matter on its own.

Recurring incidents: when small incidents add up to one major report

In plain terms: two or more non-major incidents with the same specific cause, within six months, are tested together, and if together they pass Article 8(1) they are reported as one major incident.

Article 8(2) sets three conditions, all of which must be met: the incidents “have occurred at least twice within 6 months”; they “have the same apparent root cause as referred to in Article 20, first subparagraph, point (b)” of DORA; and they “collectively fulfil the criteria for being considered a major incident set out in paragraph 1.” The second subparagraph adds: “Financial entities shall assess the existence of recurring incidents on a monthly basis.” The rule “does not apply to microenterprises and to financial entities listed in Article 16(1)”.

The ESAs’ final report on the draft RTS (JC 2023 83) explains the design. Consultation responses proposed look-back periods “from 3 to 12 months”; the ESAs moved from a rolling assessment to a monthly one, concluded that “monthly assessment for the previous 6 months should be adequate to capture recurrence”, and dropped the earlier references to “similar nature and impact”, keeping the root cause only. They tied the root cause to the taxonomy in the reporting standards, which is why Article 8(2)(b) points to DORA Article 20 rather than defining root causes itself.

That taxonomy is in the reporting forms of Implementing Regulation (EU) 2025/302. Field 4.1 has five high-level categories: malicious actions, process failure, system failure/malfunction, human error and external event. Field 4.2 breaks them down further; “third-party failures”, for example, is a detailed category under external event. A shared category is not enough. The instructions for field 4.2 state that “for recurring major ICT-related incidents, the specific apparent root cause of the incident is taken into account and not the broad categories included in this field.” Two outages caused by two different suppliers both fall under “third-party failures” but do not share an apparent root cause; two outages caused by the same certificate-renewal step being skipped do.

Three further points shape the monthly procedure:

• Reporting format. Article 3 of the ITS requires recurring incidents that together meet Article 8(2) to be reported “in an aggregated form”. For field 2.2, the detection time is “the date and the time at which the last ICT-related incident was detected.”
• Evidence retention. Article 22(d) of RTS 2024/1774 requires the ICT-related incident policy to provide for retaining all evidence relating to ICT-related incidents, and the EN corrigendum of 15 May 2025 corrected its cross-reference to read “in accordance with Article 8(2) of Commission Delegated Regulation (EU) 2024/1772” (the published text had said “Article 15”, an article 2024/1772 does not have). In practice, records of non-major incidents need their root cause and impact figures kept long enough for a six-month look-back, or condition (c) cannot be tested.
• Aggregation method. The RTS does not say how “collectively” combines figures: whether client counts are added across occurrences (counting a client hit twice twice), whether durations are summed, whether costs are summed. Summing costs fits Article 7(4), which already adds up the cost types within one incident; for clients and duration, decide a method, write it down and apply it every month.

A workable monthly cycle, based on how we built the procedure into our DORA pack, looks like this:

1. Pull every incident classified as not major in the past six months (incident manager; effort Low if the log has a root-cause field, High if it does not).
2. Group them by specific apparent root cause, not by field 4.1 category (incident manager with the system owner; Medium).
3. For each group of two or more, compute collective values and run the gate and both routes of Article 8(1) (compliance; Low with a tool).
4. Where a group qualifies, report it as one major incident in aggregated form and start the reporting clock (compliance; High).
5. Record the outcome for every group, including “not major”, with the date of the review (compliance; Low). This record is the evidence that the monthly assessment happened.

The open readings, and what the ESAs have said about them

In plain terms: in a few places the text supports two answers. The defensible approach is to choose a reading, record why, and apply it consistently, rather than decide case by case.

The home Member State question is the one with the most material behind it, and it points both ways. DORA Article 18(1)(c) refers to the geographical spread “particularly if it affects more than two Member States”. The RTS threshold in Article 9(4) is lower and differently worded: an impact “in two or more Member States in accordance with Article 4”, while Article 4 directs the entity to assess “whether the incident has or had an impact in other Member States”.

In that final report, the ESAs wrote that “the impact of the incident should be assessed against all Member States and, if there is any impact in at least two Member States, FEs to consider the criterion being met”, which supports counting the home Member State. On 16 September 2026, ESAs staff published DORA Incident Reporting – Operational Instructions, which say of field 2.6 that geographical spread “refers to the assessment of the major incident’s impact across other Member States. Accordingly, it is expected that the country of the affected financial entity is not included in this field.” The same document says it does “not represent any legal interpretation, nor … official stance of the ESAs”. One reading treats that line as a rule for filling in field 2.6 only; the other treats it as a signal that only other Member States count towards the threshold. Neither document settles the threshold itself.

Question	Reading 1	Reading 2	ESA material found
Does the home Member State count towards “two or more Member States” (Art. 9(4))?	Yes: count every Member State with impact	No: count only Member States other than the home one	JC 2023 83 supports reading 1; the September 2026 staff instructions exclude the home country from field 2.6
Can an access that already meets 9(5)(a) still use route (a) through 9(5)(b), given the words “not covered by point (a)”?	Yes (inclusive)	No: route (b) and a second threshold are needed (literal)	Q&A 2026_7779 says route (a) applies to 9(5)(b) “(where any successful, malicious and unauthorised access are considered as well)”, which leans inclusive; recital 10 (not binding) says such access to systems supporting critical or important functions “should always be considered as major incidents which are to be reported”
Is the count in route (b) per criterion or per lettered point?	Per criterion	Per point	None found
Where several services are affected, is Art. 9(1) tested per service or on aggregated figures?	Per service (“the affected service”)	Aggregated	ITS field 3.5: “In case of more than one service affected, the services shall be provided in an aggregated manner”, a reporting rule

One more trap sits in the reporting forms. Field 2.6 refers to “Articles 4 and 12” of Delegated Regulation 2024/1772 and field 4.12 to “Articles 7 and 14”. The adopted regulation ends at Article 13, and its Article 12 concerns details shared between authorities. Both numbers match the draft annexed to JC 2023 83, where Article 12 held the geographical-spread threshold and Article 14 the economic-impact threshold. Read them as Articles 9(4) and 9(6).

After the classification: the clock, clients and the board

In plain terms: classification as major starts a four-hour clock, and duties to clients and the management body follow.

Under Article 5(1)(a) of Delegated Regulation (EU) 2025/301, the initial notification is due “within four hours from the classification of the ICT-related incident as a major ICT-related incident and no later than 24 hours from the moment the financial entity has become aware of the ICT-related incident”. Where classification as major comes after 24 hours, the four hours run from that classification (Article 5(2)). Classification is therefore part of the reporting timeline, not a step before it. For how this compares with the NIS2 early warning, see DORA vs NIS2 reporting deadlines.

Role	Owns	Evidence to keep
CISO or incident manager	Gate assessment, Article 9 measurements, estimates where actual figures are missing	Classification record with time stamps and the data behind each threshold
Compliance officer	Chosen readings on the open points, monthly recurring review, reports to the competent authority	Written readings with dates; monthly review log
Management body	Receives information on “at least major ICT-related incidents”, with impact, response and additional controls (DORA Art. 17(3)(e))	Minutes or briefing notes
Client communications	Informing clients “without undue delay” where a major incident affects their financial interests (DORA Art. 19(3))	Copies of client notices

Two DORA provisions often surprise teams. Reporting can be outsourced to a third-party service provider, but the entity “remains fully responsible” (Article 19(5)). And Member States may require reports to go also to the NIS2 competent authorities or CSIRTs (Article 19(1), last subparagraph), so check national rules before assuming one recipient.

Frequently asked questions

Is every cyber attack a major incident under DORA?

No. Limb (c) of Article 6 and threshold 9(5)(b) both require a “successful, malicious and unauthorised access”. Where that happened and the access may result in data losses, Q&A 2026_7779 states that the incident is major through route (a), whichever system was entered. A blocked attempt is not covered by those words; it may instead be a significant cyber threat under Article 10, which a financial entity may notify voluntarily (DORA Article 19(2)).

Does the 100 000 euro threshold allow for insurance recoveries?

No. Article 7(1) counts costs and losses “without accounting for financial recoveries”, and Article 7(2) excludes insurance premiums from the costs. The threshold is also met where costs are “likely to exceed” the amount, so an estimate can trigger it before invoices arrive.

Do microenterprises run the monthly recurring-incident check?

No. Article 8(2) “does not apply to microenterprises and to financial entities listed in Article 16(1)”. They still classify each incident under Article 8(1).

This article provides general information only and does not constitute legal or regulatory advice. Requirements may vary by jurisdiction and organisation type. Consult a qualified legal professional or compliance specialist for advice specific to your situation.

The next step is to turn this test into a written classification procedure before the next incident: fix the readings on the open points, decide the aggregation method for recurring incidents, and make sure non-major incidents are logged with a specific root cause. Our DORA Compliance Pack includes the D22 classification tool that computes each reading side by side. For the rest of the regulation, from ICT risk management to the register of information, return to the DORA compliance guide.

Sources

1. Commission Delegated Regulation (EU) 2024/1772 of 13 March 2024 on the criteria for the classification of ICT-related incidents and cyber threats, materiality thresholds and details of reports of major incidents. Official Journal of the European Union, L series, 25.6.2024. EUR-Lex
2. Regulation (EU) 2022/2554 on digital operational resilience for the financial sector (DORA). OJ L 333, 27.12.2022. EUR-Lex
3. Commission Delegated Regulation (EU) 2025/301 on the content and time limits of the initial notification and of intermediate and final reports on major ICT-related incidents. EUR-Lex
4. Commission Implementing Regulation (EU) 2025/302 on the standard forms, templates and procedures for reporting major ICT-related incidents and notifying significant cyber threats, Annexes I and II. EUR-Lex
5. Corrigendum to Commission Delegated Regulation (EU) 2024/1774, OJ L 2025/90420, 15.5.2025 (Article 22, first subparagraph, point (d)). EUR-Lex
6. Joint ESAs, Q&A 2024_7047, “Critical Services Affected”, final answer 11 December 2024. EBA Single Rulebook Q&A
7. Joint ESAs, Q&A 2026_7779, “Scope of Article 6 lit. c RTS”, final answer 2 October 2026. EBA Single Rulebook Q&A
8. ESAs staff, DORA Incident Reporting – Operational Instructions, 16 September 2026. European Securities and Markets Authority
9. Joint Committee of the European Supervisory Authorities, JC 2023 83, Final Report on draft RTS specifying the criteria for the classification of ICT-related incidents, materiality thresholds for major incidents and significant cyber threats under DORA. European Banking Authority