When an incident report deadline is running: what to do first
Confirm the moment your organisation first became aware of the incident, and write that moment down. The deadline runs from awareness, not from the point where the incident is fully understood. Route the file immediately to whoever inside the organisation is authorised to sign a notification. More than one regime can apply to the same incident, each with its own clock and its own decision-maker, so do not wait for one team to finish before another starts.
Which clock is running
Three separate regimes can require a report inside a fixed period, and none of them share a deadline, a form, or a recipient.
| Trigger | Regime | Who decides first |
|---|---|---|
| Breach involving personal data | Applicable data protection framework | The organisation's own controller function, then the competent supervisory authority |
| Incident affecting the network or information systems of an essential or important entity | Directive (EU) 2022/2555 (NIS2) | The organisation's incident response function, then the national competent authority |
| Serious incident involving a high-risk AI system | Regulation (EU) 2024/1689 (AI Act) | The provider or deployer, then the market surveillance authority |
The applicable data protection framework does not put a specific number of hours on this page, because that number sits in the regulation and in guidance from the competent supervisory authority, and it is the authority's own text that governs, not a summary of it. Directive (EU) 2022/2555 (NIS2) sets a short sequence of steps for essential and important entities: an early signal, a fuller notification, and a final report, each with its own timing fixed by the directive itself. Regulation (EU) 2024/1689 (AI Act) places a comparable duty on providers and deployers once a serious incident involves a high-risk system, with obligations phasing in as the act enters into force from 2 August 2026, a position confirmed as of the review date noted below.
What changes once the clock is running
Before a deadline starts, an incident is mainly a technical and operational problem. Once a deadline is running, it becomes a documentation problem as well. The authority that eventually reviews the file will ask what was known, when, and who decided what to do about it. A late report is judged against the moment of awareness your organisation can prove, not the moment your organisation would prefer to claim. Missing internal timestamps, informal chat threads instead of a written log, and unclear ownership of the decision are the three most common reasons a report is treated as late.
What to do first
- Freeze the timeline. The person who first learned of the incident writes down the date, time, and source of that knowledge, before memory of it softens.
- Name one decision-maker. A single named person, not a committee, takes responsibility for the notification and its timing.
- Separate the regimes. Data protection, NIS2, and AI-related duties are assessed as three questions, not one, even where the same incident triggers all three.
- Draft before you have full certainty. An initial notification can be provisional; regulators generally expect an early signal followed by detail, not silence followed by a complete file.
- Preserve the evidence trail. Logs, tickets, and internal messages about the incident are kept intact and are not edited after the fact.
- Get legal sign-off on the wording before the notification leaves the organisation, because the wording itself becomes part of the evidence later.
Who decides, and where
The first decision is internal: who signs, and on what basis. The second decision belongs to the competent authority for the regime in question, which reviews the notification, may request further information, and decides whether the timing and content were adequate. For data protection matters, that is the competent supervisory authority. For NIS2 matters, that is the national authority designated under Directive (EU) 2022/2555 (NIS2). For AI-related serious incidents, that is the relevant market surveillance authority under Regulation (EU) 2024/1689 (AI Act). None of these bodies coordinate the deadline for you; your organisation is expected to track all applicable clocks in parallel.
If your situation differs
If the incident began with software received under a licence, and the licence itself later turns out to be the weaker point, that is a second problem running on its own timeline. It is covered in When source code escrow is demanded explained.
If the compromised system was built on rights your organisation received from someone else, the ownership question does not pause while the incident report is prepared. See When the deal transfers rights that were never owned.
If the incident traces back to a supplier's product, and a third party separately claims that product infringes its own rights, keep the two files apart. See When a supplier is accused of infringing a third party's rights, and assign different people to each.
If the affected system involves an AI feature and the incident changed how data moves through it, the report and the underlying data flow are two separate questions. See When an AI feature changes the data flow in your architecture, once the immediate deadline is under control.
If the incident exposed customer-facing material and a regulator or counterparty later argues that material was itself a binding offer, that is a distinct commercial question. See When marketing is treated as an offer step by step comparison with an incident notification.
What this page does not solve
This page does not fix a missed deadline, and it does not tell you the exact number of hours or days that applies to your specific incident; that figure sits in the text of the applicable regulation and in guidance from the competent authority, and it changes by regime and by entity type. This page also does not replace a forensic assessment of what happened, and it does not decide whether your organisation counts as an essential or important entity, or whether an AI system involved qualifies as high-risk. Those are separate, fact-specific determinations.
Verified
Checked: 14 January 2025. Primary sources named on this page: Directive (EU) 2022/2555 (NIS2); Regulation (EU) 2024/1689 (AI Act). The AI Act's phased entry into force from 2 August 2026 should be rechecked against the current text before it is relied on for a specific timeline.
Related publications
A closely related question sits one step earlier in the same file: When an AI feature changes the data flow in the same system that triggered the incident.
Frequently asked questions
What is the first step when an incident report deadline is running?
Fix the moment of awareness in writing and name a single decision-maker for the notification. Everything else follows from those two facts.
Which deadline is already running?
It depends on the regime engaged by the incident. A personal data breach, an incident under Directive (EU) 2022/2555 (NIS2), and a serious incident under Regulation (EU) 2024/1689 (AI Act) each start their own clock, and an incident can trigger more than one at once.
Who decides, and on what evidence?
The competent authority for each regime decides, based on the timeline your organisation can document: when awareness occurred, what was reported, and how quickly. Undocumented awareness is treated as unfavourable to the organisation.
Next step
If a deadline is already running, the practical work is triage: which regime applies, who signs, and what the first notification says. That is a same-day conversation, not a project. Contact our team and describe the incident in outline; we will confirm within minutes, in working hours, which clock applies and who inside your organisation should own it.