Everyone knows the DORA reporting deadlines by now. Four hours after classification, 24 hours after detection, and the rest of the reporting timeline. But the deadlines only start running once you have answered a harder question: is this incident major at all?
That question is governed by Commission Delegated Regulation (EU) 2024/1772, the RTS on incident classification. Get it wrong in one direction and you flood the authority with reports. Get it wrong in the other direction and you have an unreported major incident, which is a much worse conversation to have.
The two-step logic
The RTS boils down to a two-step test.
Step 1: Does the incident affect critical services? That means ICT services or network and information systems supporting critical or important functions, or ICT services provided by third parties that support them. If no critical service is touched, the incident is not major. This is why your mapping of critical and important functions is the foundation of incident classification, not just of the register. Step 2: If yes, is one of these true?- The incident involves successful, malicious and unauthorised access to your network and information systems. That alone makes it major.
- Or the incident meets the threshold on at least two of the other classification criteria.
Simple in structure. The work sits in the criteria and their thresholds.
The criteria and their thresholds
- Clients and counterparts. More than 10 percent of the clients using the affected service, or more than 100,000 clients. For financial counterparts, more than 30 percent. For transactions, more than 10 percent of the daily average number or value of transactions for that service. Estimates are allowed when exact numbers are not available.
- Reputational impact. Met when the incident draws media coverage, triggers repeated complaints, causes loss of clients with material effect, or leaves you unable to meet regulatory requirements.
- Duration and downtime. Incident duration longer than 24 hours, or service downtime longer than 2 hours for an ICT service supporting a critical or important function.
- Geographical spread. Impact in two or more Member States.
- Data losses. Any impact on the availability, authenticity, integrity or confidentiality of data that has an adverse effect on your business objectives or your ability to meet regulatory requirements.
- Economic impact. Costs and losses above 100,000 euro, gross, before any recoveries.
Note how low some of these sit in practice. Two hours of downtime on a critical service plus a data integrity issue is already two criteria. Many firms that read the thresholds for the first time realise that incidents they handled quietly last year would be major today.
The rule everyone forgets: recurring incidents
Incidents that are not major on their own can become major together. If incidents with the same apparent root cause occur at least twice within six months and cumulatively meet the criteria, they are classified as one major incident. The RTS expects you to assess this monthly. If your incident process has no recurrence check, this obligation is currently being met by nobody.
💡 Prepare your denominators before you need them. Every percentage threshold has a denominator: clients per service, daily average transactions, counterparts. You cannot compute "more than 10 percent of clients using the affected service" at 02:30 during an outage if nobody knows the baseline. Maintain the baselines per critical service, review them quarterly, and classification becomes arithmetic instead of debate.
Two habits that keep you out of trouble
Classify fast, and log when you did it. The 4-hour clock starts at classification, and supervisors know that. A pattern of long gaps between detection and classification reads as deadline management, not diligence. A documented classification step with a timestamp protects you. Document the non-major decisions too. When an incident touches a critical service but you conclude it is not major, write down which criteria you assessed and why the thresholds were not met. The ESAs' first incident report showed thousands of reports flowing in across the EU, and the follow-up question to a quiet firm is always the same: show us what you did not report, and why.How DORA GRC helps
The incident module in DORA GRC has the classification logic built in. Register the incident, answer the criteria questions, and the module computes the classification against the RTS thresholds, timestamps the decision, and starts the right reporting deadlines. Recurring incidents are flagged automatically by root cause across the six-month window, and non-major assessments are stored with the same evidence trail as the reported ones.
Sources: Commission Delegated Regulation (EU) 2024/1772 on the classification of ICT-related incidents. Regulation (EU) 2022/2554 (DORA), Articles 17 to 19. ESAs joint report on major ICT-related incidents, 2026.