NIS2 gives in-scope organisations three reporting deadlines: 24 hours, 72 hours and one month. Most of what has been written about them is a summary of the directive, and your legal department can read the directive without help. The operationally interesting question is a different one: when does the clock actually start?
The deadlines run from the moment your organisation becomes aware of the incident, not from the moment the incident happens. That single detail moves NIS2 out of the legal department and into your logging and alerting stack.
Where the clock starts
The European Court of Auditors set the sequence out plainly in its Special Report 19/2026: an early warning within 24 hours, an incident notification within 72 hours, and a final report within one month. Awareness is the trigger (Figure 2).
Read as an engineer, that turns a legal obligation into a measurable property of your monitoring. If you detect a compromise in twenty minutes, you have twenty-three hours and forty minutes to produce an early warning. If you detect it on day three, you missed the first deadline two days before anyone in the organisation knew there was a deadline to miss.
This is not a grace period and it is not a defence. Late detection does not extend the clock, it consumes it. An organisation that cannot detect cannot report on time - not because it is unwilling, but because it does not yet know.
The scope changed more than the deadlines did
The old NIS directive covered around 15 500 entities across the EU. NIS2 covers more than 110 000 (para. 33). That is not a widening, it is a different population.
Two figures are worth putting next to each other. The transposition deadline for NIS2 was October 2024, and two member states met it (para. 33). The report does not name them, and we are not going to guess. Meanwhile public administration is the most frequently hit target in the EU, accounting for 38.2 % of 4 875 recorded incidents (ENISA threat landscape 2025, Annex I Figure 2) - and under the old NIS directive it had no reporting obligation at all.
The practical consequence for a newly in-scope organisation is uncomfortable. A large share of the entities now facing a 24-hour deadline have no reporting history, which means they have no detection practice built around one. Nobody has ever measured how long it takes them to notice.
Reporting is not detection
There is a second trap in the reporting chain, and it is easy to walk into while believing you are doing well.
Incident data reaching ENISA is quarterly, anonymised and aggregated. It serves statistics and trend analysis (para. 34). It is a good input for European situational awareness and the wrong input for defending your own network, because by the time it exists it is a quarter old and stripped of everything that would let you match it to your environment.
Reporting obligations and response capability are two different systems that happen to share a trigger. If you build only the first, you have a compliance pipeline that produces documents on a deadline. It will not tell you that something is wrong, and it will not help you when something is.
What has to be running before the incident
None of what follows is exotic. It is unglamorous plumbing, and its only remarkable property is that it has to exist before you need it, because none of it can be assembled inside a 24-hour window.
- Centralised logs with a defined retention period. Logs that live only on the host that produced them are gone exactly when the host is the problem. Retention has to be long enough to reconstruct a timeline that started before you noticed, which in practice means months, not days.
- Alerting with a named owner. Not a distribution list. A person, with a deputy, who is accountable for the alert being seen. An alert routed to a team mailbox is an alert routed to nobody.
- A contact chain that works outside office hours. Most incidents are discovered at an inconvenient time. The chain has to be tested - phone numbers go stale faster than infrastructure does.
- A severity matrix agreed in advance. Written down, with examples, before anyone is under pressure. What counts as significant is a judgement call, and a judgement call made at three in the morning without a rule is a coin toss.
- A named person who makes the classification call. Someone has to decide that this is the incident that starts the clock. If that authority is unassigned, the decision defaults to whoever is least willing to escalate.
- An audit trail of the decision itself. Not just what happened, but when you knew, who decided, and on what basis. The final report due in a month is a reconstruction, and reconstructions are only as good as the record.
The list is what an organisation under NIS2 should have in place. It is deliberately not a product description: none of it requires a particular vendor, and most of it is a matter of assigning responsibility rather than buying software.
Why detection is a compliance control
The usual framing puts detection in the security budget and compliance in the legal budget, and treats them as separate conversations with separate owners.
NIS2 does not respect that split. Because the clock starts at awareness, the quality of your detection is the variable that determines whether the deadline is physically achievable. An organisation with centralised logging, working alerts and a named decision-maker can comply. An organisation without them cannot, and no amount of policy documentation changes that. The deadline is not made easier by good intentions, a larger legal team or a well-written incident response policy that nobody has rehearsed.
That is the useful thing to take from the audit. The findings are about European institutions, but the mechanism is general: reporting obligations are downstream of detection, and a programme that gets the order backwards produces paperwork instead of security.
Source: European Court of Auditors, Special Report 19/2026, "Detecting and responding to cybersecurity incidents", adopted 16 June 2026. Available at eca.europa.eu under CC BY 4.0. Paragraph numbers in the text refer to the report so the findings can be checked.