There is no single answer, because the clock is set by the regulation you are caught by, not by the incident. The shortest first deadline in the EU rulebook is 4 hours under DORA, and it starts when you classify an incident as major rather than when you notice it. NIS2 and the Cyber Resilience Act both want an early warning inside 24 hours. GDPR gives you 72 hours. The EU AI Act, counterintuitively, gives you between 2 and 15 days depending on what the incident did.
Most organisations are subject to more than one of these at once, and the clocks run in parallel from different starting points. A payment firm hit by a ransomware attack that also exposes customer records is on the DORA clock and the GDPR clock simultaneously, reporting to two different authorities in two different formats.
| Regulation | First deadline | Then | Final report |
|---|---|---|---|
| GDPR | 72 hours to the supervisory authority, from becoming aware | Information may be given in phases | No separate final report is prescribed |
| NIS2 | 24 hours, early warning, from becoming aware | 72 hours, incident notification | One month after the incident notification |
| DORA | 4 hours from classification as major, and no later than 24 hours from becoming aware | 72 hours, intermediate report | One month after the intermediate report |
| EU AI Act | 2, 10 or 15 days, depending on the incident | An incomplete initial report is permitted | A complete report follows the initial one |
| Cyber Resilience Act | 24 hours, early warning, from becoming aware | 72 hours, fuller notification | 14 days or one month, depending on the track |
How long do you have to report an incident?
Between 4 hours and 15 days, and the honest answer is that you have to know which regulation applies before the number means anything. Three things decide it.
The first is what happened. A personal data breach engages GDPR, an incident affecting a regulated service engages NIS2 or DORA, a malfunctioning high risk AI system engages the AI Act, and a vulnerability in a product you manufacture engages the CRA. One real world outage can be several of these at once.
The second is what starts the clock. Most regimes run from the moment you become aware; DORA runs from classification, with a backstop of 24 hours from awareness. The third is whether you owe a report or a warning: under NIS2 and the CRA the 24 hour deliverable is an early warning, short by design, and it does not require you to have finished investigating.
GDPR: what does the 72 hour clock actually cover?
Less than most summaries imply. Article 33(1) requires the controller to notify a personal data breach to the competent supervisory authority without undue delay and, where feasible, not later than 72 hours after having become aware of it. Three qualifications sit inside that sentence and all three matter.
It is conditional. The duty does not apply where the breach is unlikely to result in a risk to the rights and freedoms of natural persons. That assessment is yours to make and to document, not the authority's.
Missing it is not automatically a breach of the Article. Where notification is not made within 72 hours, Article 33(1) requires it to be accompanied by reasons for the delay. A late, explained notification is contemplated by the text.
The 72 hours binds the controller, not the processor. Article 33(2) requires the processor to notify the controller without undue delay after becoming aware, with no fixed period attached. Vendors who promise a 72 hour notification to their customers are promising something the Regulation does not ask of them, and controllers who rely on it have given away most of their own window.
Telling the individuals concerned is a separate duty under Article 34 with no 72 hour clock at all. It runs without undue delay, applies only where the breach is likely to result in a high risk to their rights and freedoms, and Article 34(3) exempts you where the data was rendered unintelligible by measures such as encryption, where later measures make the high risk unlikely, or where individual communication would take disproportionate effort and a public communication is made instead.
NIS2: what are the reporting stages?
Four, set out in Article 23(4), all measured from becoming aware of the significant incident.
An early warning without undue delay and in any event within 24 hours, indicating where applicable whether the incident is suspected of being caused by unlawful or malicious acts or could have a cross border impact. An incident notification within 72 hours, updating the early warning with an initial assessment including severity and impact and, where available, indicators of compromise. An intermediate report on status, but only upon the request of the CSIRT or competent authority. A final report not later than one month after the incident notification. Where the incident is still ongoing when the final report falls due, you file a progress report instead and the final report is due within one month of the handling being completed.
An incident is significant under Article 23(3) if it has caused or is capable of causing severe operational disruption of services or financial loss for you, or has affected or is capable of affecting others by causing considerable material or non-material damage. Note the phrase "is capable of causing": the test is not restricted to harm that actually materialised.
One derogation is widely missed. A trust service provider, for significant incidents affecting the provision of its trust services, owes the notification in point (b) within 24 hours rather than 72. If you operate under eIDAS as well as NIS2, your second deadline is the same as your first.
DORA: is it really 4 hours?
Yes, but not from the moment you think. The deadlines are not in DORA itself. Article 19(4) names the initial notification and the intermediate and final reports; the time limits are in Article 5 of Commission Delegated Regulation (EU) 2025/301.
The initial notification is due as early as possible, and in any case within 4 hours from the classification of the incident as a major ICT-related incident, and no later than 24 hours from the moment you became aware of it. That is one deadline with two triggers, and whichever falls first is the one you have to meet. If you have not classified an incident as major within 24 hours of becoming aware but classify it as major later, Article 5(2) gives you 4 hours from that classification.
The intermediate report is due at the latest within 72 hours from the submission of the initial notification, and it is due even where the status or handling of the incident has not changed. You then submit an updated intermediate report without undue delay, and in any case when regular activities have been recovered. The final report is due no later than one month after the intermediate report, or after the latest updated intermediate report where more than one was filed.
Two provisions are worth knowing before an incident rather than during one. Article 5(3) requires you to tell the competent authority before the deadline passes, with reasons, if you cannot meet it. Article 5(4) lets a deadline falling on a weekend or national bank holiday be met by noon the next working day, but Article 5(5) withdraws that relief for the initial notification and intermediate report of credit institutions, central counterparties, operators of trading venues, and entities identified as essential or important under Article 3 of NIS2. If you are a bank, the weekend does not help you. The classification test is in our guide to DORA major incident classification.
EU AI Act: when is a serious incident reportable?
Article 73 requires providers of high risk AI systems to report serious incidents to the market surveillance authorities of the Member State where the incident occurred. The report is due immediately after the provider establishes a causal link between the AI system and the incident, or the reasonable likelihood of one, and in any event within an outer limit that depends on the incident.
The default outer limit is 15 days from becoming aware. It drops to 2 days for a widespread infringement or for a serious and irreversible disruption of the management or operation of critical infrastructure. It is 10 days where a person has died, running from awareness, with the report due immediately once a causal relationship is established or even suspected.
The ordering looks wrong at first glance: death of a person carries a longer outer limit than critical infrastructure disruption. It is less strange once you read Article 73(4), which requires the report immediately upon suspicion rather than upon proof, so the 10 days is a backstop for establishing causation rather than a permitted delay.
Article 3(49) defines a serious incident as one leading, directly or indirectly, to death or serious harm to health, serious and irreversible disruption of critical infrastructure, infringement of Union law obligations protecting fundamental rights, or serious harm to property or the environment. Article 73(5) permits an incomplete initial report followed by a complete one, which is the practical route when the 2 day limit applies. Scope and dates are in our guide to EU AI Act scope and deadlines.
Cyber Resilience Act: why are there two final reports?
Because Article 14 runs two separate tracks, and manufacturers routinely plan for one and get caught by the other.
The first track is an actively exploited vulnerability in your product. Early warning within 24 hours of becoming aware, a vulnerability notification within 72 hours, and a final report no later than 14 days after a corrective or mitigating measure is available.
The second track is a severe incident affecting the security of the product. Early warning within 24 hours, an incident notification within 72 hours, and a final report within one month after that notification.
The two front ends are identical and the two back ends are not. The vulnerability final report is the only clock in any of these regimes that starts from the availability of a fix rather than from awareness or an earlier filing, so shipping the patch starts a new 14 day obligation rather than ending your duty. Both tracks report simultaneously to the CSIRT designated as coordinator and to ENISA through the single reporting platform in Article 16, and the coordinator may request an intermediate report under Article 14(6).
Article 71 brings Article 14 into application on 11 September 2026, more than a year before the rest of the Regulation applies on 11 December 2027. The full sequence is in our guide to the Cyber Resilience Act deadlines for 2026 and 2027.
Which clock applies when more than one regulation does?
All of them. There is no principle in any of these instruments that satisfying one discharges another, and they report to different bodies: supervisory authorities under GDPR, CSIRTs or competent authorities under NIS2, financial competent authorities under DORA, market surveillance authorities under the AI Act, and the CSIRT coordinator plus ENISA under the CRA.
Operationally, the shortest clock sets your process and the others inherit it. A bank subject to DORA and GDPR builds for 4 hours and the 72 hour GDPR notification is then comfortable. Designing to the longest applicable deadline is the mistake that turns a reportable incident into an enforcement matter; the exposure is set out for NIS2 and the Cyber Resilience Act separately. The one narrowing rule worth knowing is in the AI Act: under Article 73(9) providers of Annex III systems already subject to equivalent EU reporting obligations report only the fundamental rights category of serious incident, and Article 73(10) narrows it similarly for medical devices.
What the other results get wrong
Four errors recur across the published comparisons, and three of them are the kind that would cause a real filing to be late.
The first is presenting DORA as a flat "4 hour rule". It is 4 hours from classification with a 24 hour backstop from awareness, and an entity that reads it as 4 hours from awareness will over-report, while one that ignores the backstop will under-report. Several widely shared summaries also invent a "24 hour intermediate report" for DORA. There is no such stage: the intermediate report is at 72 hours.
The second is describing the EU AI Act as requiring "immediate" notification without a number. Article 73 sets outer limits of 2, 10 and 15 days, and a programme built on the word "immediately" has no deadline to test itself against. The third is treating the NIS2 24 hour item as a report: it is an early warning, and that distinction is what makes the deadline achievable.
The fourth is silence on the derogations. The trust service provider 24 hour rule, the DORA weekend provision and its carve out for banks and trading venues, and the CRA's 14 day fix-based clock are all in the primary texts and almost never in the summaries. Member States can also transpose NIS2 more strictly than the Directive's floor, so a national deadline may be shorter than the one quoted here.
Map your own clocks
Fill this in for your own organisation. A row you cannot answer is an incident you would report late.
| Question | Your answer | Why it matters |
|---|---|---|
| Which of the five regimes apply to you? | Most regulated organisations are caught by at least two, running in parallel to different authorities. | |
| What is your shortest first deadline? | That number, not the longest one, is what your process has to be built to meet. | |
| Who can classify an incident as major out of hours? | Under DORA the 4 hour clock starts at classification, so a delayed classification is not a defence. | |
| Can you file an early warning before you understand the incident? | NIS2 and the CRA expect exactly that at 24 hours. Waiting for the full picture is what makes filings late. | |
| Do your processor contracts set a notification period? | GDPR Article 33(2) gives processors no fixed clock, so your controller window is only as good as the contract. | |
| Is a weekend covered? | DORA Article 5(4) helps some entities and explicitly does not help banks, CCPs or trading venues. |
If most rows are blank, the gap is process rather than tooling, but the two are related: the clocks are short enough that assembling a filing by hand is where the time goes. Our incident management module holds the classification test and the filing templates against each of these deadlines, and a free compliance check will tell you which regimes you are actually in scope for before you design anything.
Frequently asked questions
What is the shortest incident reporting deadline in the EU?
4 hours, under DORA, measured from the classification of an ICT-related incident as major rather than from the moment you became aware of it, and capped at 24 hours from awareness. It is set by Article 5 of Commission Delegated Regulation (EU) 2025/301, not by DORA itself.
Does the GDPR 72 hour clock start when the incident happens?
No. It runs from when the controller becomes aware of the personal data breach, and falls away entirely where the breach is unlikely to result in a risk to the rights and freedoms of natural persons.
Does reporting under NIS2 satisfy GDPR?
No. They are separate duties owed to different authorities with different content and different tests. An incident can be significant under NIS2 without being a personal data breach, and the reverse is also true.
When do the Cyber Resilience Act reporting duties start?
11 September 2026. Article 71 applies the Regulation in full from 11 December 2027, but brings Article 14 forward to September 2026, and those duties attach to products already on the market.
What happens if we miss a deadline?
It varies. GDPR contemplates a late notification accompanied by reasons for the delay. DORA requires you to tell the competent authority before the deadline passes and explain why. NIS2 and the CRA treat the reporting duties as enforceable obligations in their own right, and under the CRA the Article 14 duties sit in the top penalty tier.
Primary sources
Deadlines are taken from the primary texts: Articles 33 and 34 of Regulation (EU) 2016/679 (GDPR); Article 23 of Directive (EU) 2022/2555 (NIS2); Article 19 of Regulation (EU) 2022/2554 (DORA) together with Article 5 of Commission Delegated Regulation (EU) 2025/301; Articles 3(49) and 73 of Regulation (EU) 2024/1689 (EU AI Act); and Articles 14 and 71 of Regulation (EU) 2024/2847 (Cyber Resilience Act). NIS2 is a Directive, so national transposition can set shorter or additional obligations. Confirm the current text and your national implementation before relying on a figure.





