Classifying a major ICT incident under DORA: the operational decision tree

Classifying a major ICT incident under DORA is a two-step decision: determine whether a critical service is affected, then test the regulatory severity thresholds. The crisis cell must record its answers, unknowns and assumptions from detection onwards, and reassess the qualification at every material change. The tree below accelerates that decision without replacing case-by-case regulatory analysis.

Facts to establish before qualifying the incident

Do not wait for the root-cause analysis. As soon as the incident is detected, the incident owner opens a single, timestamped qualification sheet, separate from the general crisis log.

Step 1 — Assign an owner to each data point

The sheet must at least cover:

• detection time, estimated start and the method used to estimate it;
• components, financial services and business functions affected;
• whether the supported functions are critical or important;
• the number of clients affected and the total number of clients using the service;
• the number of financial counterparties affected and the corresponding denominator;
• the number and value of transactions affected, compared with relevant daily averages;
• the Member States concerned;
• the duration of the incident and of any service unavailability;
• breaches of availability, authenticity, integrity or confidentiality of data;
• any successful malicious and unauthorised access, and its potential for data loss;
• indicators of reputational impact;
• direct or indirect costs and losses already observed or foreseeable;
• incidents over the previous six months with a similar apparent cause.

Each field gets an owner: Operations for clients and transactions, the business for service impact, CISO or CIO for technical data, Finance for costs, Compliance or Risk for interpreting the criteria.

Step 2 — Link the component to the affected service

An unavailable server or a compromised account is not enough to qualify the incident. Document the chain:

ICT component → ICT service → financial service → business function → clients or obligations affected.

The expected evidence is the services-to-functions map, completed if needed by the business owner. This step notably determines whether the service supports a critical or important function.

Step 3 — Snapshot the impacts

For each measure, record the value, the denominator, the measurement time and the source: incident ticket, technical logs, monitoring tool, client extract, transaction file, complaints or financial estimate. A value without a denominator cannot be tested against a percentage threshold.

Exit criterion: every data point needed by the tree has a value, “unknown” or “not applicable”. No cell is left blank.

The decision tree for testing severity criteria

Commission Delegated Regulation (EU) 2024/1772 sets the applicable criteria and thresholds. Counting must be done by regulatory family: crossing two client-related sub-thresholds does not, on its own, mean two distinct criteria have been met.

Step 1 — Is a critical service affected?

Answer yes if at least one of the situations in Article 6 is established:

1. the service supports a critical or important function;
2. the affected financial service is subject to authorisation, registration or supervision by a competent authority;
3. malicious and unauthorised access to network and information systems has succeeded.

If the answer is no, the incident is not major under this tree. Keep the justification anyway and reassess if the scope changes.

Step 2 — Is the data-specific branch met?

Ask: has malicious and unauthorised access succeeded, with access that may lead to data loss?

• Yes: if the critical-service gate is also met, classify the incident as major.
• No: move on to the accumulation of other criteria.
• Unknown or plausible: assign the status “provisional qualification under escalation”.

Do not confuse this branch with any availability or integrity breach. It targets the specific threshold in Article 5(1)(b) of the delegated regulation.

Step 3 — Have at least two other criteria been crossed?

Test each family with a yes/no question:

• Clients or counterparties: are more than 10% of clients using the service, more than 100,000 clients, or more than 30% of relevant financial counterparties affected?
• Transactions: are more than 10% of the average daily number or average daily value of transactions related to the service affected?
• Reputation: has the incident led to media coverage, repeated complaints from different clients or counterparties, a likely inability to meet regulatory requirements, or a risk of client loss with a significant impact on the business?
• Duration or unavailability: has the incident lasted more than 24 hours, or has unavailability of a service supporting a critical or important function exceeded two hours?
• Geographic reach: does the incident produce an impact in at least two Member States?
• Data: has the breach of availability, authenticity, integrity or confidentiality had, or will it have, a negative effect on operational objectives or compliance with regulatory requirements?
• Economic impact: do costs and losses exceed, or are they expected to exceed, EUR 100,000?

If at least two of these families reach their threshold and a critical service is affected, classify the incident as major.

Step 4 — Should recurring incidents be aggregated?

At least once a month, look for individually non-major incidents that:

• occurred at least twice over a six-month period;
• share the same apparent cause;
• collectively meet the conditions for classifying a major incident.

The “apparent cause” is the one available at the time of assessment; it does not require waiting for a definitively proven root cause.

Tree output: retain a single status — “major”, “not major at this stage” or “provisional qualification under escalation”. Classification as major then feeds into the process covered in the DORA ICT incident management cheat sheet, without repeating notification sequences here.

What to do when impacts or thresholds remain uncertain

An unknown data point is never a negative answer. It must become a measurable hypothesis, with an owner and a deadline.

Step 1 — Frame each unknown

Keep a table including:

Unknown data point	Low–high range	Source or method	Owner	Next update	Possible effect
Clients affected	8,000–14,000	Errored sessions	Operations	14:30	10% threshold possible
Foreseeable costs	EUR 60–120k	Finance estimate	Finance	16:00	Economic threshold possible

The range must rest on an identifiable method. A purely speculative upper bound justifies investigation, not a regulatory conclusion.

Step 2 — Test the low and high scenarios

Run the tree with the low hypothesis, then with the high one. If the two scenarios lead to different statuses, keep a provisional qualification and trigger an immediate review involving the incident owner, CISO and Compliance or Risk.

Also escalate when:

• two criteria are close to their threshold;
• several impacts accumulate without an isolated threshold yet being demonstrated;
• successful malicious access or data loss remains plausible;
• service criticality is undecided;
• denominator quality does not allow a reliable calculation.

Step 3 — Define the next reassessment trigger

Do not merely schedule a review “later”. Retain the first expected event: a new extract, a possible duration overrun, extension to another service or Member State, discovery of exfiltration, a rise in affected clients or transactions, a revised cost estimate, or a link to a recurring incident.

Exit criterion: no “not major at this stage” status is maintained when a decisive unknown still has no owner, estimation method or deadline.

How to trace and validate the classification decision

The audit trail must allow an internal third party to reconstruct the decision without interviewing crisis participants.

Step 1 — Build a versioned dossier

Keep:

• the incident identifier, scope and chronology;
• the version of the tree and regulatory reference used;
• the financial service and function affected;
• for each criterion: threshold, value, denominator, source, measurement time and answer;
• logs, extracts or non-modifiable references for evidence;
• unknowns, ranges, assumptions and confidence levels;
• analysis of recurring incidents and their apparent cause;
• the rationale for classification or non-classification;
• dissenting views, reservations and arbitrations;
• reassessment dates and the change history.

Step 2 — Organise validation

The incident owner validates the facts, the CISO or ICT lead the technical impact, the business the effect on the service, and Compliance or Risk the reading of the criteria. The conclusion rests with the decision-maker designated by the entity’s internal procedure; their identity, decision time and any reservations are recorded.

Any requalification produces a new version without overwriting the previous one. It must cite the new triggering fact: duration threshold crossed, scope extended, data loss confirmed or economic estimate revised.

Exit criterion: every positive, negative or unknown answer can be linked to timestamped evidence, an explicit hypothesis and a named validator.

Regulatory sources: Regulation (EU) 2022/2554 — DORA, Delegated Regulation (EU) 2024/1772 on classification criteria and the ESMA DORA page.

Frequently asked questions

Who qualifies the incident when it originates from an ICT third-party service provider?

The financial entity remains responsible for classification with regard to its services, functions, clients and obligations. The provider supplies the necessary technical elements — chronology, scope, availability, access and affected data — but its own qualification does not replace that of the asset manager or payment institution.