How fast do you have to report a major ICT incident under DORA
Once you classify an ICT-related incident as "major," you have to send the initial notification to your competent authority within 4 hours of that classification decision, and in any case no later than 24 hours after you first became aware of the incident. From there, an intermediate report is due within 72 hours of the initial notification, and the final report follows within one month of the intermediate report (or the latest updated intermediate report, if the incident drags on).
Where these numbers actually come from
I say this a lot to clients because people keep quoting half-remembered timelines from blog posts: the obligation itself sits in Articles 17 to 23 of Regulation (EU) 2022/2554 (DORA), but the exact clocks and content requirements are not in the regulation's text. They were finalized by the European Supervisory Authorities (EBA, ESMA, EIOPA) through two technical standards that the European Commission adopted as Commission Delegated Regulation (EU) 2025/301 (the RTS on content and timelines) and Commission Implementing Regulation (EU) 2025/302 (the ITS on standard forms and templates). Classification criteria, separately, come from Commission Delegated Regulation (EU) 2024/1772. If you're building a compliance program, read those three alongside the Level 1 text, not instead of it.
What makes an incident "major" in the first place
Article 18 of DORA sets the criteria; the RTS 2024/1772 turns them into thresholds with a combination rule. The logic works in two steps.
First, a gateway test: does the incident affect ICT systems supporting a critical or important function, does it affect authorised or supervised financial services, or does it involve a successful, malicious, unauthorised access to your systems. If none of these apply, you're not looking at a major incident, full stop, regardless of how bad it feels operationally.
Second, if the gateway is open, you check the materiality criteria:
- Clients, counterparts and transactions affected, including number or percentage of clients, financial counterparts, and transaction volume or value
- Reputational impact, assessed through media coverage, repeated client complaints, or risk to meeting regulatory requirements
- Duration of the incident and downtime of the affected service
- Geographical spread across Member States
- Data losses affecting availability, authenticity, integrity or confidentiality
- Criticality of the services affected
- Economic impact, meaning direct and indirect costs and losses
An incident becomes major when the gateway is met and either there's a qualifying malicious intrusion that may cause data loss, or at least two of the materiality thresholds are triggered together. One bad number on its own, even a large economic loss, generally isn't enough by itself. This is a frequent misreading I see in incident runbooks: teams treat each criterion as independently decisive instead of applying the combination logic the RTS actually sets out. There's also an aggregation rule worth knowing: incidents with the same apparent root cause, recurring at least twice within six months, get assessed together and can collectively cross the major threshold even if each one looked fine in isolation.
What this actually requires operationally for a small EMI or PI
Most small electronic money institutions and payment institutions I work with don't have a problem understanding the rule. They have a problem executing it inside a 4-hour window with a five or ten person operations team.
A few things that genuinely move the needle:
- Pre-calculate your thresholds now, not during an incident. Know what 10% of your client base is in absolute numbers, know your daily average transaction volume and value, so nobody is doing that arithmetic while a system is down.
- Build a one-page classification checklist mapped directly to the gateway plus the materiality criteria, and make sure whoever is on call at 2am can apply it without waiting for a compliance officer to wake up.
- Decide in advance who has authority to classify an incident as major. If that decision sits with one person who might be unreachable, the 4-hour clock will beat you before anyone notices.
- Draft your initial notification template against the ITS 2025/302 fields in advance, with your entity details, competent authority contact, and service inventory already filled in. The initial report doesn't need root cause, so don't let your team stall trying to find one.
- Track obligations on a calendar that counts from classification, not from detection, and separately from submission of each report, since the intermediate and final deadlines chain off the prior filing, not off the original incident time.
This is exactly the operational gap Novafin's DORA incident-reporting automation work is built to close: pre-built classification logic, templated notifications, and deadline tracking that doesn't depend on one person remembering the rules under pressure. If you're also working through your third-party risk obligations, our piece on DORA Article 28 vendor registers for EMIs covers the register side of the same framework.
If you want a second pair of eyes on your incident classification and reporting setup before a real incident forces the test, reach out at team@novafin.co or through the DORA compliance page.