NIS2 incident notification: building a process that holds up under pressure

NIS2’s deadlines are well known: an early warning within 24 hours of becoming aware of an incident, a fuller notification within 72 hours, a final report within a month. The practical problem is not the deadline itself, but that most companies discover they lack a process capable of meeting it at exactly the worst moment to improvise one.

The first obstacle is classification, not drafting

Before anyone writes the notification, someone has to decide whether the event is "significant" under the directive’s criteria — severe operational disruption, material financial loss, or impact on other entities. Without classification criteria decided in advance, that call gets made under pressure, often downward, to avoid the notification duty — a mistake that exposes the company far more than the notification itself would.

A process that holds up defines in advance who has the authority to declare an incident "significant", against what objective thresholds, and who must be told immediately, because the 24-hour clock starts from becoming aware of the incident, not from its full technical confirmation.

Rehearsing the process before it matters

A notification plan that has never been exercised is a hypothesis, not a capability. A tabletop exercise — a simulated incident, a real stopwatch, and the roles actually involved — almost always shows where the process breaks down: who has to approve the notification’s wording, how to reach the regulator outside office hours, who talks to customers if the news leaks before the official notification does. These look like operational details until they are missing at the wrong moment.

The takeaway

Meeting NIS2’s deadlines is not a drafting-speed problem. It is a problem of decisions made in advance — who classifies, who approves, who communicates — so the 24 hours are counted from a process that already exists, not one invented while the incident is still open.