19 August 2026

A NIS2 incident: you have 24 hours. What exactly has to happen

The Polish KSC Act gives essential and important entities 24 hours for an early warning of a significant incident, 72 hours for a notification and generally one month from the notification for a final report. The periods run from obtaining information about an event that meets the incident criteria, not automatically from the first raw alert.

That clock starts whether you are ready or not. Which is why the whole game is played before the incident, not during it. I will lay out what has to happen in the first day and what has to exist beforehand for that day to be survivable. A caveat: I am not a lawyer, this is not legal advice, and you should confirm the significance thresholds and procedural details with counsel and your competent CSIRT.

The clock runs from obtaining information about the incident

A monitoring alert does not necessarily start the period on its own. The key moment is when the organisation obtains information allowing the event to be classified as an incident. Organisations must not artificially delay alert analysis, however, because a lack of timely assessment capability does not suspend statutory duties.

The consequence is practical: you must be able to recognise and escalate at any hour, and be clear on who decides significance. Without that, 24 hours can vanish before anyone realises they were running.

The first day, hour by hour

I will show it as a sample, well-run sequence. The hours are notional, the point is the order.

Hour zero, detection. Monitoring or a human notices something worrying. The event lands somewhere it will not be lost, with the exact time of detection, because everything downstream is counted from that time.

The first hours, significance assessment. A designated person judges whether this is an incident under the law and whether it is significant. This decision must have an owner in advance, because in the middle of an event there is no time to work out who decides. If significant, you trigger the reporting path.

The first several hours, gathering facts. What happened, when it was detected, which systems and services are affected, the preliminary impact on the services you provide. For an early warning you do not need a full analysis, you need an honest picture of what is already known, marking what is still uncertain.

Before 24 hours elapse, the early warning. You send an early warning to the competent CSIRT. It is a short message: that an incident occurred, an initial assessment, whether you suspect malicious action or cross-border effects. It is not a full report, just a signal that "something is happening and we are working on it".

Then, by 72 hours, the notification proper with an updated assessment and impact, and generally within one month of that notification the final report describing the cause, the course of events and the actions taken.

One important exception: a public entity classified as important may use the simplified route. It then submits the 72-hour notification without the 24-hour early warning or final report. The entity's status and reporting route should be confirmed before an incident occurs.

What has to exist before the incident happens

That first day is survivable only if you prepared five things beforehand.

A definition of an incident. What counts as an incident for you and what makes it significant. Without it, every event triggers a debate instead of a procedure.

Designated people. Who assesses significance, who writes the notification, who approves it, who has access to the CSIRT reporting system. Roles filled by name, with deputies, because incidents do not schedule themselves around the responsible person's working hours.

Rehearsed access. An account in the reporting system, credentials somewhere you can reach under pressure. Your first login to the CSIRT system cannot happen in the thirteenth hour of the counted day.

An incident register. A place where you record events, including those that ultimately were not significant. The auditor asks about the process, not just the notifications sent, and the register shows you assess events systematically.

A rehearsed path. At least one dry run, to reveal where the process jams, before it jams on a real incident.

An important boundary: preparation, not automation

Here I must say plainly what my tool does not do, because it is a matter of trust. The incident register in the tool is for preparing the notification: it gathers facts, tracks deadlines, holds the wording and the history. It does not send anything to a CSIRT automatically. The decision to report and the sending itself are done by a human, consciously. Reporting to an authority is an act for which a person is responsible, not a script, and it should stay that way. The tool exists so that when the human makes that decision, everything is ready to hand, not so that it makes the decision for them.

The honest part: most events are not significant

Not every alert is an incident and not every incident is significant under the law. The vast majority of events end at the assessment "this does not qualify for reporting", and that is normal. Keeping a register for them too is not bureaucracy, it is evidence that you have a working process that consciously separates the serious from the noise. To an auditor, such a register says more than a single notification sent.

In practice

If you want to see what an incident register with 24h, 72h and one-month deadline counters looks like, run as preparation for a notification rather than its automation, enter the demo.

24 hours sounds alarming until you are prepared, and stops being so once you are. The whole difference is whether the five things on this list exist before the incident, or whether you are trying to build them during it, watching the clock tick.

Sources

One email a week with newly published vulnerabilities worth knowing about. No account needed.

This digest covers new vulnerabilities in general, not your servers. If you want to know which of them actually run in your infrastructure, that is what Secvalis does: it scans your machines and reports only what concerns them.