NIS2 24-Hour Incident Reporting: The Engineering Runbook to Build Before an Incident

The hardest deadline in NIS2 is not an audit date. It is the 24-hour clock that starts the moment your team becomes aware of a significant incident. NIS2 incident reporting requires essential and important entities to submit an early warning to their national CSIRT or competent authority within 24 hours of awareness, a fuller incident notification within 72 hours, and a final report within one month. Teams that try to figure out what counts as "significant", who files the report, and which portal to use while production is on fire will miss the window. The fix is unglamorous: build the runbook now, while nothing is burning.

This post lays out that runbook in five parts: classification, detection, the notification chain, report templates, and drills. It assumes you already know whether you are in scope. If you do not, start with our overview of what NIS2 means for mid-size SaaS teams and come back.

What the NIS2 incident reporting timeline actually demands

The directive defines a three-stage reporting cascade, and each stage has a different job:

Stage	Deadline	Content
Early warning	24 hours from awareness	Whether the incident is suspected to be caused by unlawful or malicious acts, and whether it could have cross-border impact
Incident notification	72 hours from awareness	Initial assessment of severity and impact, plus indicators of compromise where available
Final report	One month after the incident notification	Detailed description, root cause, mitigation applied, and cross-border impact

Two details trip up engineering teams. First, the clock starts at awareness, not at confirmation. If your on-call engineer sees strong evidence of a breach at 02:00 on Saturday, the 24-hour window is already running. Second, the early warning is deliberately lightweight. Regulators do not expect a forensic analysis in 24 hours; they expect a short, structured heads-up. Teams that miss the deadline usually miss it because nobody knew who was responsible for sending it, not because the analysis was too hard.

In Germany, reports go to the BSI through its online reporting portal, and the national NIS2 implementation act (NIS2UmsuCG) follows this cascade. Other member states designate their own CSIRT or authority, so if you operate entities in several countries, your runbook needs a per-country routing table.

Step 1: Decide what "significant" means before anyone is tired and scared

NIS2 obliges you to report significant incidents: those causing or capable of causing severe operational disruption or financial loss, or affecting other parties with considerable material or non-material damage. That definition is too abstract to apply at 03:00. Translate it into concrete thresholds for your product, written down and approved in advance.

A workable classification matrix for a B2B SaaS looks like this:

• Report (significant): customer data confirmed or plausibly exfiltrated; full platform outage longer than your published RTO; ransomware or destructive malware on production systems; compromise of a signing key, identity provider, or CI/CD pipeline; an incident at a supplier that degrades your service for a substantial share of customers.
• Probably report (escalate to decision-maker): partial outage of a core feature for several hours; suspected but unconfirmed unauthorized access; vulnerability confirmed exploitable with evidence of scanning.
• Do not report (track internally): failed attack attempts with no impact, single-customer misconfiguration, degraded performance within SLA.

The matrix must name a single decision-maker (plus a deputy) who can classify an incident as significant. Ambiguity here is the number one cause of blown deadlines: engineers debate severity in a channel for six hours while the clock runs. Give one person the explicit authority to say "this is reportable" and make over-reporting the default when in doubt. A withdrawn report is embarrassing; a late one is a compliance finding.

Step 2: Make detection produce a timestamp you can defend

The 24-hour window is measured from awareness, so your monitoring stack defines your deadline. Three engineering requirements follow:

Alerting must reach a human with authority. A critical security alert that lands in a dashboard nobody watches does not delay awareness in a regulator's eyes; it just means you were aware and slow. Route security-critical alerts (authentication anomalies, data egress spikes, integrity check failures, EDR detections) to an on-call rotation with paging, not to email.

Log what you will need for the 72-hour report. The incident notification expects an initial severity and impact assessment. That is only possible if authentication events, admin actions, data access, and deployment events are logged centrally with retention long enough to reconstruct a timeline. If your audit logging is thin, fix that first; it is also what enterprise customers check in procurement. Our work in code quality consulting regularly starts with exactly this gap, because an unauditable system cannot produce a credible incident report.

Record the awareness moment explicitly. The first responder should post a timestamped "incident declared" message in the incident channel. That single message anchors every subsequent deadline and removes any later argument about when the clock started.

Step 3: Build the notification chain as a checklist, not tribal knowledge

When classification says "report", the path to the regulator must be mechanical. The runbook section for notification should contain, literally written out:

1. Who files: named primary and deputy (typically CISO, CTO, or managing director). Both have accounts on the reporting portal created in advance. Portal registration during an incident wastes hours you do not have.
2. Where: the exact URL of the BSI reporting portal (or your member state's equivalent), plus login prerequisites. If you registered as an essential or important entity, keep the registration number in the runbook.
3. What: the early warning needs only suspected cause (malicious or not) and possible cross-border impact. Prepare these as two questions the incident commander answers, not as an essay.
4. Who else: legal counsel, data protection officer (a personal data breach also triggers the separate 72-hour GDPR notification to the data protection authority), affected enterprise customers per contract, and your cyber insurer. List names, phone numbers, and the order of calls.
5. Escalation outside business hours: the on-call engineer must be able to reach the filing officer at 03:00 on a holiday. If that path does not exist, the runbook is fiction.

Step 4: Pre-write the reports

Every report you can draft before an incident, you should. Keep three templates in the repository next to the runbook:

• Early warning template: entity name and registration number, contact person, incident start time, suspected malicious cause yes/no/unknown, potential cross-border impact yes/no/unknown, one-paragraph free-text summary.
• 72-hour notification template: the early warning fields plus affected services, estimated number of affected customers, severity assessment, indicators of compromise, and mitigation taken so far.
• Final report skeleton: timeline table, root cause section, applied and planned mitigations, cross-border impact assessment.

Pre-filled fields (entity data, contacts, registration number) should already be populated. During a real incident, the team fills in perhaps ten fields instead of writing prose from scratch under pressure.

Step 5: Drill the runbook twice a year

A runbook that has never been executed will fail in some boring way: a portal password that expired, a phone number that changed, a deputy who left the company. Run a tabletop exercise twice a year. Pick a scenario (ransomware on a worker node, leaked API token with confirmed data access), start a timer, and walk the chain: detection, declaration, classification, early warning drafted, stakeholders notified. Measure the time to a submittable early warning. If it is over four hours in a calm exercise, it will not survive a real Saturday night.

Drills also surface architectural weaknesses that no document review catches: monitoring blind spots, logs that rotate too early, single points of failure in the people chain. Treat the findings like production bugs with owners and deadlines. If the drill shows your platform cannot produce the forensic data the 72-hour report needs, that is an engineering project, and one worth scoping properly; our custom software development engagements often include exactly this kind of observability and audit-trail work for regulated SaaS products.

Frequently asked questions

Does the 24-hour deadline apply on weekends and holidays? Yes. The directive makes no allowance for business hours. This is why the on-call path to the filing officer matters as much as the template.

What if we report and it turns out to be a false alarm? You can update or withdraw. Regulators across the EU have signaled that a good-faith early warning later downgraded is far better than a late report. Design your thresholds to over-report at the early warning stage.

Do we report to every country we have customers in? You report to the authority of the member state where you are established (main establishment rules apply for digital providers). Cross-border impact is a field in the report, not a reason to file twenty reports. If you operate separate legal entities in several member states, map each entity to its authority in the runbook.

We are a supplier to an essential entity but not in scope ourselves. Can we ignore this? Practically, no. Your in-scope customers must manage supply chain risk and will contractually pass reporting duties to you, often with windows shorter than 24 hours. The same runbook serves both purposes. See our post on supply chain security and NIS2 readiness for the supplier-side view.

Build it before you need it

The pattern behind every step is the same: move decisions, registrations, and writing out of the incident and into calm preparation. Classification thresholds, portal accounts, contact chains, and templates cost a few focused days to set up. Done in advance, the 24-hour early warning becomes a checklist exercise. Improvised, it becomes the second crisis of the night.

If you want a second pair of eyes on your incident reporting readiness, from audit logging and detection coverage to the runbook itself, write to us at hello@wolf-tech.io or visit wolf-tech.io. We help SaaS teams turn regulatory deadlines into engineering checklists.