NIS2 24/72-Hour Incident Reporting Runbook
A practitioner runbook for the NIS2 24-hour early warning and 72-hour report — thresholds, decision triggers, templates, and German BSI specifics.
The hardest part of NIS2 incident reporting is not writing the report. It is the first 24 hours — when you have partial information, a noisy alert queue, and a legal clock that started the moment someone decided the incident was significant. Germany's NIS2UmsG has applied since 6 December 2025 with no transition period, so this is now an operational reality, not a planning exercise. This runbook is the one we hand to clients' security teams: it turns the directive's prose into decisions an on-call engineer can make at 02:00.
TL;DR / Key takeaways
- The NIS2 clock starts on awareness that an incident is significant, not when it began — so your hardest control is a crisp, pre-agreed significance threshold.
- Three deadlines, one timeline: 24-hour early warning, 72-hour incident notification, one-month final report, all to the BSI under the German NIS2UmsG.
- The 24-hour early warning is short and low-friction by design. Do not over-engineer it; the penalty is for silence, not for incomplete early information.
- Management is personally liable for oversight of risk-management measures — a missed report is a governance failure, not just an ops failure.
- Fines reach EUR 10M or 2% of global turnover for particularly important entities. Build the runbook before you need it.
Why the 24/72 model breaks naive incident processes
Most enterprises already have an incident response process. Almost none of them are wired for a regulatory clock that starts on awareness. A traditional SOC workflow optimises for accurate root cause before escalation. NIS2 inverts that: you must notify before you fully understand the incident. The early warning exists precisely because the regulator would rather know early and be corrected later than learn about a national-impact incident a week after the fact.
This is why the single most valuable artefact is a significance decision rule that an on-call lead can apply without waking the CISO. NIS2 defines a significant incident qualitatively — severe operational disruption, financial loss, or considerable damage to others — but a qualitative definition is useless at 02:00. You have to translate it into numbers your team owns.
Step 0: Define "significant" before the incident
If you are still debating significance during the incident, you have already lost hours off the 24-hour budget. Pre-agree quantitative triggers and review them quarterly. We typically codify something like this with clients, calibrated to their service criticality:
| Trigger dimension | Example threshold (calibrate to your business) | Default classification |
|---|---|---|
| Service downtime of a core service | > 1 hour, or any outage during peak | Likely significant |
| Customer/citizen records exposed | > 1,000 records, or any special-category data | Likely significant |
| Financial impact (direct + recovery) | > EUR 100k estimated | Likely significant |
| Suspected malicious/unlawful cause | Any confirmed intrusion or ransomware | Significant + flag as malicious |
| Cross-border / supply-chain spread | Any spread to another Member State or key supplier | Significant + flag cross-border |
The point is not the exact numbers — it is that the on-call lead reads a table, not a directive. Anything that trips a row triggers the 24-hour process automatically. Borderline cases default toward reporting; under-reporting carries far more regulatory and personal-liability risk than an early warning that is later downgraded.
The single timeline: three reports, one incident
NIS2 reporting is not three separate events. It is one incident observed at three resolutions. Confusing this is the most common mistake we see — teams treat the 72-hour report as a fresh document that contradicts the 24-hour warning, which immediately signals an immature process to the regulator.
| Stage | Deadline (from awareness) | Purpose | Detail level |
|---|---|---|---|
| Early warning | 24 hours | Flag that a significant incident occurred; state if malicious/unlawful and if cross-border | Minimal — facts known so far |
| Incident notification | 72 hours | Initial severity and impact assessment, affected services, IoCs | Moderate — first real assessment |
| Final report | 1 month | Root cause, full impact, mitigations applied and planned, cross-border effects | Complete — the closing record |
Where an incident is still ongoing at one month, NIS2 anticipates a progress report at the one-month mark and a final report once the incident is resolved. Treat the one-month report as a checkpoint, not necessarily the end.
What the 24-hour early warning must say — and what it must not
The early warning is deliberately thin. It answers three questions: did a significant incident occur, is it suspected to be caused by an unlawful or malicious act, and could it have cross-border impact. That is it. Teams routinely paralyse themselves trying to produce a forensic summary in 24 hours. Do not. The early warning's job is to start the clock with the regulator, not to be correct about root cause.
A workable early-warning template has four fields: entity and contact, time of awareness, one-paragraph description of observed impact, and the two yes/no/unknown flags (malicious cause, cross-border). "Unknown" is a valid and honest answer this early.
The runbook: detection to final report
- Declare and timestamp awareness. The instant an alert is correlated to a significance trigger, declare the incident in your tracker and record the awareness timestamp to the minute. This single timestamp anchors all three deadlines and must be defensible in hindsight. Make declaration a deliberate, logged act — not an implicit side effect of someone reading a dashboard.
- Stand up the incident structure. Appoint an incident commander who owns the reporting timeline, distinct from the technical lead who owns remediation. These roles compete for the same people under pressure; separating them is what keeps the 24-hour deadline from slipping while everyone firefights.
- Submit the 24-hour early warning to the BSI. Use the pre-built template. Send it even if you expect to downgrade later.
- Run containment and the 72-hour assessment in parallel. By 72 hours you owe an initial severity and impact assessment. This is where your SIEM, EDR, and asset inventory earn their keep — you cannot assess impact on assets you have not inventoried.
- Preserve evidence and a decision log throughout. Every containment action, every classification decision, every report submission gets timestamped. The decision log is what protects management when oversight is later questioned.
- Submit the one-month final (or progress) report. Root cause, full impact, mitigations applied and planned. Then run a retrospective and feed concrete changes back into this runbook.
Tooling implications
A 24-hour obligation is incompatible with purely manual triage. You need detections mapped to your significance triggers, automated alerting to compliance and legal (not just the SOC), and a pre-drafted reporting template living somewhere your on-call team can reach without hunting. We have delivered this on Microsoft Sentinel for several regulated clients, wiring analytics rules directly to a NIS2 severity taxonomy and an automated logic-app handoff that pages both the incident commander and legal counsel the moment a significance trigger fires. The technology is the easy part; the discipline of the significance table and the awareness timestamp is what actually keeps you compliant.
Common failure modes we see
- Starting the clock too late. Treating "awareness" as "after investigation" is the most expensive mistake. Awareness is when a reasonable team would conclude the incident is significant.
- Over-engineering the early warning. Spending 20 of your 24 hours drafting prose. The early warning is four fields.
- No separation of reporting and remediation ownership. One person cannot run the bridge call and draft regulatory notifications.
- Forgetting the supply chain. A significant incident at a key supplier can trip your own reporting obligations and your cross-border flag.
- Treating reporting as an IT-only matter. Management approval and oversight of risk-management measures is a legal duty; the board needs to know the runbook exists and works.
How this connects to the rest of your NIS2 programme
Incident reporting does not stand alone. You first need to confirm you are in scope — work through the thresholds in our NIS2 Germany scope test before anything else, because the reporting duty only bites once you are an important or particularly important entity. You then need to be registered with the BSI; our BSI registration walkthrough covers the portal that opened on 6 January 2026 and why late registration is still required. And because the consequences of getting this wrong land on individuals, read our analysis of management liability under the German NIS2UmsG — the personal-liability dimension is what turns this runbook from a nice-to-have into a board-level control.
A working incident-reporting capability is also a natural by-product of a Zero Trust architecture: strong identity, segmentation, and telemetry give you both the detection signal and the impact evidence the 72-hour report demands.
FAQ
When does the NIS2 24-hour clock start?
The clock starts the moment your organisation becomes aware that an incident is significant — not when the incident began, and not when you have finished investigating. Awareness is a low bar: a credible alert correlated to a meaningful impact is usually enough. Under the German NIS2UmsG this triggers the duty to submit an early warning to the BSI within 24 hours.
What is the difference between the 24-hour early warning and the 72-hour report?
The 24-hour early warning is a short notification flagging that a significant incident occurred and whether it appears to be caused by an unlawful or malicious act and could have cross-border impact. The 72-hour report is a fuller incident notification with an initial assessment of severity, impact, and indicators of compromise. A final report follows within one month.
Which incidents are significant enough to report under NIS2?
An incident is significant if it has caused or is capable of causing severe operational disruption to your services or financial loss, or if it has affected other parties through considerable material or non-material damage. Because the threshold is partly qualitative, you should pre-define quantitative triggers (downtime, records affected, financial impact) so on-call staff can decide quickly.
Who do German entities report NIS2 incidents to?
Entities in scope of the German NIS2UmsG report to the Bundesamt fuer Sicherheit in der Informationstechnik (BSI) through its reporting portal. The same portal is used for registration, which opened on 6 January 2026. Sector-specific obligations (for example for telecoms or energy) may add parallel reporting duties.
Is the management board personally liable for incident reporting failures?
Yes. Under the NIS2UmsG, the management of an entity must approve and oversee risk-management measures and can be held personally liable for failures of oversight. Missing reporting deadlines or failing to maintain a working reporting process is a governance failure, not merely an operational one.
What are the fines for failing to report under NIS2?
For particularly important entities, fines reach up to EUR 10 million or 2 percent of global annual turnover, whichever is higher. Reporting failures and inadequate risk management are both sanctionable. Beyond fines, regulators can issue binding instructions and, in serious cases, restrict management functions.
If you want a second pair of senior eyes on your NIS2 reporting runbook — the significance thresholds, the BSI handoff, the Sentinel wiring — our Zero Trust and cybersecurity practice builds and pressure-tests exactly this with European enterprises. We would rather you ran the drill with us than for the first time during a real incident.
Topics