NIS2 incident reporting: the 24-hour, 72-hour and one-month path as a runbook, not a policy

Three deadlines, three different questions

NIS2 Article 23 does not ask for one incident report. It asks for a sequence, and each step wants different information:

When	What	What it must say
Within 24 hours of becoming aware	Early warning	Whether the incident is suspected to be caused by unlawful or malicious acts, and whether it could have a cross-border impact
Within 72 hours	Incident notification	An update to the early warning; an initial assessment of severity and impact; indicators of compromise where available
On request	Intermediate report	Relevant status updates
Within one month of the notification	Final report	Detailed description including severity and impact; the type of threat or root cause; applied and ongoing mitigation; cross-border impact where applicable

Two more obligations sit beside the sequence: where relevant, inform the recipients of your services without undue delay of significant incidents likely to affect them; and, for significant cyber threats, of measures they can take.

Read as a policy, that is a page. Read as a runbook, it is a set of decisions with a clock on each — and most of the information the reports need already exists as records somewhere in the organisation. The runbook’s job is to say which record answers which question, and who is allowed to send it.

The 24-hour report is not “everything we know”. It is two yes/no answers and a form. The hard part is deciding, fast, that the clock has started.

Step 0 — “Significant” is a decision with an owner

The clock starts when the entity becomes aware of a significant incident: one that has caused or is capable of causing severe operational disruption or financial loss, or that has affected or is capable of affecting others by causing considerable damage. That threshold has to be applied by a named role, at any hour, from information the on-call team can actually see. Write down: who decides, on what criteria (your national implementing act may add specifics), and how the decision and its time are recorded — because “when did you become aware” is the first question a competent authority asks.

Step 1 — the 24-hour early warning

Two questions: malicious or not (suspected is enough), cross-border or not. Answer them from records, not from a war room:

• Malicious? — the incident classification your handling process already assigns (deliberate vs. failure vs. unknown).
• Cross-border? — the affected services and the functions they support: if a service is delivered to customers or entities in another Member State, or depends on a provider there, the answer is “possibly yes”. This is why the incident must be linked to the assets and services it hit — the answer is a walk through the inventory, not a guess.

The early warning goes to the CSIRT or competent authority your Member State designates. Put the address, the portal and the template in the runbook, not in someone’s mailbox.

Step 2 — the 72-hour notification

Update the two answers, add an initial severity and impact assessment, add indicators of compromise if any. Severity in NIS2 terms is about affected users, duration, and geographic spread — figures that come from the same links: which functions, how many recipients, since when. If those links exist, the 72-hour report is filled from them; if not, it is a spreadsheet at 2 a.m.

Step 3 — the final report within a month

Detailed description, root cause, mitigation applied and ongoing, cross-border impact. This is where the incident becomes evidence for the rest of the framework: the root cause becomes a finding with an owner, the mitigation becomes actions with due dates, and the incident feeds Article 21(2)(f) — assessing the effectiveness of your measures. A final report that lives only in the authority’s portal is a lost record; keep it, dated, linked to the affected assets and controls.

Step 4 — recipients and threats

Where relevant, tell the recipients of your services. That needs a list of who those recipients are per service — again a property of the service record — and a decision on the message. For significant cyber threats (not yet incidents) the obligation is measures they can take; that is a communication procedure, and it belongs next to the crisis-communication plan.

The runbook, on one page

1. Detect → classify (existing incident process; classification includes malicious / non-malicious).
2. Decide “significant” — named role, written criteria, time recorded.
3. T+24 h — early warning: malicious? cross-border? — from the classification and the affected-services links.
4. T+72 h — notification: severity, impact, IoCs — from affected functions and recipients.
5. On request — intermediate status.
6. T+1 month — final report; root cause → finding; mitigation → actions; report kept as evidence.
7. In parallel — inform recipients where relevant; crisis communication owner named.
8. After — post-incident review feeds effectiveness assessment; findings closed with verification.

Rehearse it once with a fictional incident and a stopwatch. The rehearsal record is itself evidence for Article 21(2)(b) and (f).

In Secantra

Secantra does not run incidents — there is no incident-management module in the current release, and we say so on the product pages. What it holds are the records the runbook reads from and writes to: the CMDB links from an affected asset to the IT services and business functions above it (and to the third-party providers behind them), so “which functions, cross-border, how many recipients” is a walk; the governance documents for the reporting procedure and the crisis-communication plan, versioned and approved; findings with severity, owner and status for root causes; treatment actions with due dates for mitigation; evidence items with a collection date for the reports and the rehearsal.

Checklist

• “Significant incident” defined for your entity, with a named decider and a recorded time of awareness
• CSIRT / competent authority contact, portal and templates in the runbook
• 24 h: malicious? cross-border? answered from classification and service links
• 72 h: severity, impact, IoCs from affected functions and recipients
• One month: final report kept as dated evidence; root cause a finding; mitigation as actions
• Recipient and threat communication procedures written; crisis-communication owner named
• Rehearsed once, with a stopwatch, and the rehearsal recorded