The 24-hour clock starts earlier than you think

The deadline nobody disputes, and the one everybody does

Ask a room of security leads when the NIS2 24-hour deadline starts and you will get three answers: when the incident happened, when we understood it, and when management signed off. Only one of those is in the directive, and it is none of them.

Awareness. Not occurrence, not diagnosis, not approval. The clock starts when the entity becomes aware that it has a significant incident on its hands — which in practice means the moment a competent person could reasonably conclude that the significance test is met.

Why that wording is deliberate

Tying the deadline to diagnosis would make it self-defeating: the slower your investigation, the later your obligation. Tying it to occurrence would be impossible, because you often establish the start time weeks later, during forensics. Awareness is the only anchor that is both knowable at the time and resistant to gaming.

It also explains why the early warning itself is so light. It asks two things: whether the incident is suspected of being caused by unlawful or malicious acts, and whether it could have cross-border impact. That is not a report. It is a signal, designed to let the CSIRT offer help while helping is still possible.

Where the first day actually goes

In post-incident reviews, the lost time is almost never in detection or in drafting. It is in the gap between "this looks bad" and "we have agreed this is significant". That gap is filled with people trying to convene the right group of decision-makers, out of hours, to make a judgment nobody has been pre-authorised to make alone.

The significance test is not especially hard. It is article 23(3):

Note "is capable of causing". A contained incident that could have been severe still qualifies. This is where internal thresholds are most often set too high — teams calibrate on realised impact, and the directive calibrates on potential impact.

Write the rule before you need it

The fix is not a faster escalation tree. It is a written decision rule that an on-call engineer can apply at three in the morning without waking anybody. Something with the shape of: if any of these conditions holds, we file an early warning, and we do not wait for confirmation.

• Any confirmed unauthorised access to a system supporting an in-scope service
• Any encryption or destruction of data affecting service availability
• Any outage of an in-scope service beyond your defined threshold, from any cause not yet excluded as benign
• Any indication of data exfiltration affecting third parties
• Any incident where you cannot yet rule out severe disruption — the residual category that catches what the list misses

Filing early is cheap. Filing late is not.

There is a persistent worry that an early warning creates a permanent record of an incident that turns out to be nothing. That worry is misplaced. The chain is explicitly iterative: the 72-hour notification updates the early warning with a real assessment, and the final report at one month supersedes both. An early warning that resolves into "no significant impact" is a normal outcome, not an embarrassment.

The asymmetry is stark. An unnecessary early warning costs you a form and a conversation with your CSIRT — who, incidentally, may tell you something useful. A late one is a breach of article 23, in a regime where article 32 lets the authority order an audit at your expense and publish the fact of your non-compliance.

And it is not the only clock

A single incident routinely starts several. If personal data is affected, GDPR article 33 gives you 72 hours to the data protection authority — a different recipient, a different threshold, different content. Financial entities report under DORA instead of article 23. Some sectors carry national critical-infrastructure duties on top.

These run in parallel, not in sequence, and they do not share a form. Mapping them once, per legal entity, is an afternoon of work that pays for itself the first time you need it.