NEWVenvera speaks your language: the full platform, in English, German, Spanish, Bulgarian and Arabic.See what’s new
Incident Reporting Deadlines by Regulation
Learn

Incident Reporting Deadlines by Regulation

·Alexander Sverdlov

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.

RegulationFirst deadlineThenFinal report
GDPR72 hours to the supervisory authority, from becoming awareInformation may be given in phasesNo separate final report is prescribed
NIS224 hours, early warning, from becoming aware72 hours, incident notificationOne month after the incident notification
DORA4 hours from classification as major, and no later than 24 hours from becoming aware72 hours, intermediate reportOne month after the intermediate report
EU AI Act2, 10 or 15 days, depending on the incidentAn incomplete initial report is permittedA complete report follows the initial one
Cyber Resilience Act24 hours, early warning, from becoming aware72 hours, fuller notification14 days or one month, depending on the track
The first reporting deadline in five EU regimes: 4 hours under DORA, 24 hours under NIS2, 72 hours under GDPR and 15 days under the EU AI Act

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.

The NIS2 Article 23(4) reporting stages: 24 hour early warning, 72 hour notification, intermediate report on request, final report at one month, and a progress report if the incident is ongoing

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.

The DORA reporting sequence showing one clock with two triggers: 4 hours from classification as major, capped at 24 hours from becoming aware, then 72 hours and one month

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.

EU AI Act Article 73 reporting clocks: 2 days for critical infrastructure or widespread infringement, 10 days for the death of a person, 15 days for every other serious incident

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.

Cyber Resilience Act Article 14 runs two tracks that share a 24 hour early warning and 72 hour notification but end in different final reports at 14 days and one month

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.

QuestionYour answerWhy 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.

The bottom line on incident reporting deadlines: the shortest clock you are subject to is the only one worth planning against

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.

Alexander Sverdlov

Alexander Sverdlov

CEO & Founder

Alexander is the founder of Venvera and a 20+ year veteran of European cybersecurity and compliance. He has led security and risk programmes for regulated financial institutions, fintechs and SaaS companies operating under DORA, NIS2, GDPR, ISO 27001 and the EU AI Act. Before Venvera, he founded Atlant Security, an offensive security consultancy that ran penetration tests, red-team exercises and ISO 27001 readiness programmes for clients across the EU and the Middle East. He writes on the cross-framework realities of running modern compliance: how to map one control to many obligations, where the spreadsheets fall apart, and what regulators are actually asking for once the auditor sits down.

More articles by Alexander

CONTINUE READING