When is an incident major under DORA? Criteria, thresholds and five worked cases

The short answer: under DORA, an ICT-related incident is major when it affects critical services of the financial entity and one of two further conditions is met: there was successful malicious unauthorised access that may lead to data losses, or two or more of the materiality thresholds in Article 9 of Delegated Regulation (EU) 2024/1772 are met. If it is major, the initial notification goes to your supervisor within 4 hours of classifying it as major, and no later than 24 hours after you became aware of it.

The rest of this article is the detail you need to apply that sentence at three in the morning: what counts as a critical service, the exact thresholds, how they are measured and five cases classified step by step.

The rule in two steps

Classification is not a points score. It is a gate, then a count.

Step 1: the gate. If the incident does not affect critical services, it is not major, however many clients it touches. Article 6 of Delegated Regulation 2024/1772 says an incident affects critical services when any of these applies:

1. It affects ICT services or network and information systems that support critical or important functions of the entity.
2. It affects financial services that require authorisation or registration, or that are supervised.
3. It is successful, malicious and unauthorised access to the entity's network and information systems.

Step 2: the count. Once through the gate, the incident is major (Article 8(1)) when:

• (a) there was malicious unauthorised access to network and information systems that may lead to data losses (the threshold in Article 9(5)(b)). That alone is enough; or
• (b) two or more of the other Article 9 thresholds are met.

The six criteria and their thresholds

These are the Article 9 thresholds. Each row is one criterion: meeting two conditions in the same row counts once, not twice.

DORA's seventh criterion, the criticality of the services affected, is not in the table because it is not counted: it is the gate in step 1.

How each one is measured

The thresholds are clear. What changes the outcome is how you measure. Articles 1 to 7 of the Delegated Regulation spell it out:

• Incident duration: from when the incident occurs until it is resolved. If you don't know when it started, from detection; but if logs show it started earlier, from what the logs say.
• Service downtime: from when the service becomes fully or partially unavailable until it is back at its pre-incident level. If delayed operations remain afterwards, downtime lasts until they are completed.
• Clients affected: those who cannot use the service and also those adversely affected by it. Third parties covered by the contract as beneficiaries of the service count too.
• Transactions: all those involving a monetary amount with at least one part carried out in the Union: payments, securities, crypto-assets, commodities, collateral.
• Costs and losses: expropriated funds, replacing or relocating software, hardware or infrastructure, extra staff and overtime, contractual breaches, client redress, forgone revenue, communication and advisers (legal, forensics) all count. Day-to-day maintenance, post-incident improvements and insurance premiums do not. And recoveries, such as insurance payouts, are not deducted.
• If you don't have the figure: estimate it from comparable reference periods. The rule allows it explicitly; you do not have to wait for the exact number.

Five cases classified step by step

All five cases are about ACME, a bank.

Case 1. ACME's app, down for three hours

ACME has 400,000 clients on its app. On a Tuesday at 10:00 its authentication service fails and 150,000 clients cannot log in for 3 hours.

• Gate: the app supports a critical function. Through.
• Clients: 150,000 exceeds 100,000 and also 10 %. That is one criterion met, even though two conditions apply.
• Downtime: 3 hours, more than 2 for a service supporting a critical function. Second criterion.
• Result: major. Two criteria. The initial notification is due 4 hours after classification, and at the latest 24 hours after becoming aware.

Case 2. Ransomware contained in 40 minutes

An attacker encrypts one of ACME's HR file servers. The team isolates it in 40 minutes. No client notices anything.

• Gate: this is successful, malicious, unauthorised access to the entity's systems (Article 6(c)). Through, even though no critical function is touched.
• Article 8(1)(a) shortcut: that access may lead to data losses. That is enough.
• Result: major, even though it lasted 40 minutes and affected no clients. And if personal data was involved, GDPR notification to the data protection authority within 72 hours has to be assessed separately.

This is the case most often misclassified: anyone who only looks at clients, duration and money files it as minor.

Case 3. ACME's portal down because of its cloud provider

ACME's cloud provider has an outage. The client portal, which supports a critical function, is down for 90 minutes. 8 % of portal clients are affected and a regional newspaper runs the story.

• Gate: through.
• Downtime: 90 minutes, under 2 hours. Not met.
• Clients: 8 %, under 10 %, and fewer than 100,000. Not met.
• Reputation: media coverage. One criterion.
• Result: not major. Only one criterion. But it must be recorded with its cause, because it may count as a recurring incident.

The fact that the failure was the provider's changes nothing: the entity classifies the impact on its own services.

Case 4. The same failure, seven weeks later

Seven weeks later, the same fault at the same provider takes the portal down again: 70 minutes and 6 % of clients.

Separately, neither is major. But Article 8(2) says recurring incidents are major when all three conditions are met:

• they occurred at least twice within six months: yes;

• they share the same apparent root cause: yes;

• together they meet the major-incident criteria: affected clients add up to 14 %, above 10 %, and reputation was already met by the first one. Two criteria.

• Result: major, as a recurring incident.

The recurring-incident check is monthly, and it does not apply to microenterprises or to the entities in Article 16(1) of DORA.

My rule for adding up recurring incidents

The regulation says recurring incidents are major if they "collectively" meet the criteria, but it does not say how to add them up. Each entity has to decide, and this is the rule I apply:

• What you count, you add up: clients, counterparts, transactions and costs across all incidents in the series. A client who appears in two incidents counts once.
• For yes-or-no criteria, once is enough: if any incident in the series made the news or reached another Member State, the series meets that criterion.
• Duration is not added up. Two 70-minute outages are not one of 140: each incident is looked at on its own. Adding them up would turn any intermittent fault into a major incident, and I don't think that is what the regulation intends.
• When in doubt, notify. Over-reporting costs a report. Failing to report something the supervisor considered major costs a much longer explanation.

Whatever your rule is, write it down before you need it and apply it the same way every time. What a supervisor will not accept is a rule that changes to suit the moment.

Case 5. A night batch that duplicates charges

An error in ACME's direct-debit batch duplicates 2,000 charges. The batch ran at 01:00; the error is detected at 09:00 and fixed at 07:00 the next day, 30 hours after it occurred. Many clients call to complain. Refunds and compensation cost EUR 40,000.

• Gate: it affects a financial service that requires authorisation. Through.
• Clients and transactions: 2,000 charges against a daily average of 60,000 is 3.3 %; by value, also below 10 %. Not met.
• Duration: 30 hours, counted from when it occurred (01:00), not from detection. More than 24 hours. One criterion.
• Reputation: repeated complaints from different clients. Second criterion.
• Economic: EUR 40,000, below 100,000. Not met.
• Result: major.

Had duration been counted from detection, it would be 22 hours and the result would change. That is why measuring from the first log entry matters.

If it is major: reporting deadlines

They are set by Delegated Regulation (EU) 2025/301, Article 5:

• Weekends and public holidays: if a deadline falls on one, you may submit by noon on the next working day. This does not apply to the initial notification or intermediate report of credit institutions, central counterparties, trading venue operators and entities that are essential or important under NIS2. The supervisor can also withdraw it from other significant entities.
• If you can't make it: tell the supervisor before the deadline and explain why.
• Who to: your competent authority. In Spain, depending on the type of entity, the Banco de España, the CNMV or the Directorate-General for Insurance and Pension Funds.

The most common mistakes

1. Counting the same criterion twice. Exceeding both 10 % and 100,000 clients is one criterion, not two.
2. Forgetting the malicious-access shortcut. Unauthorised access that may lead to data losses is major on its own, even with no clients affected.
3. Measuring duration from detection. It is measured from when the incident occurred, if the logs show it. Note: the 24-hour reporting deadline does run from when you become aware.
4. Not recording minor incidents. Without a log of each one and its cause, the monthly recurring-incident check is impossible.
5. Getting the cost wrong. Including insurance premiums or the follow-up improvement project, or deducting what the insurer pays.
6. Waiting for certainty. The rules allow estimates and later reclassification. The initial notification even has a field to report reclassification from major to non-major.

How to have it sorted before it happens

Classification is decided in the first hour, and in the first hour nobody has time to look for data. What works is having it ready:

• The map of critical services: which services support critical or important functions, on which systems and with which providers.
• Baselines for each service: clients using it, counterparts, and the daily average number and value of transactions. Without them you cannot work out 10 % in the middle of the night.
• A classification sheet with the six criteria and the time of each decision, so you can justify later why it was classified that way and when.
• A log of every incident with its cause, for the monthly recurring-incident check.

In Almenara, the Incidents module matches the incident against your inventory and impact analysis, proposes the classification using these criteria and tracks the deadlines for you. To see how a case like this plays out, the “Your cloud provider goes down” demo walks through it end to end. And the DORA guide covers the rest of the obligations.

Frequently asked questions

Can an incident that affects no clients be major?

Yes. Malicious unauthorised access to the entity's systems that may lead to data losses is major on its own, even with no clients affected and no service downtime (case 2).

How many criteria make an incident major under DORA?

Two or more of the Article 9 thresholds of Delegated Regulation 2024/1772, provided the incident affects critical services. The exception is malicious access with possible data losses, which is enough on its own.

When does the 24-hour reporting clock start?

When the entity becomes aware of the incident. Within that window, the initial notification must be sent at most 4 hours after classifying it as major.

If the failure is my ICT provider's, do I still have to report it?

Yes, if it meets the criteria. The financial entity classifies the impact on its own services, whatever the origin of the failure (case 3).

What if I classify it as major and it turns out it wasn't?

You can reclassify it. The initial notification and the reports record reclassification from major to non-major. It is better to report with estimates than to wait for all the data and miss the deadline.

What is a recurring incident under DORA?

Two or more incidents within six months, with the same apparent root cause, that are not major individually but meet the criteria together. They are checked monthly. The rule does not apply to microenterprises.

Do cyber threats have to be reported too?

Only voluntarily. Article 10 of Delegated Regulation 2024/1772 defines when a cyber threat is significant, and Delegated Regulation 2025/301 sets out what that voluntary notification must contain.