The 24h/72h/30-day reporting cascade and what goes in each step

Step 4-2 of the NIS2 guide sets out the framework: a documented reporting process, three stages, clear deadlines. This article fills in the framework. It answers the question that remains after reading the guide step: what exactly must go into each of the three reports – and what can wait?

When the Clock Really Starts: The Kenntniserlangung Trap

Section 32(1)(1) BSIG requires the early warning to be submitted "without undue delay, at the latest 24 hours after becoming aware". What sounds like a clear rule contains an operational trap.

The 24-hour deadline does not start when the CISO is informed. It does not start when the incident response process is formally initiated. It does not start when management learns of the incident. It starts when any employee in your organisation becomes aware of the incident.

This is the decisive difference from the GDPR regime: Article 33 GDPR ties the deadline to the controller – the organisation at management level – gaining knowledge. The NIS2 regime is stricter. Section 32 BSIG contains no restriction to responsible persons. Any employee's awareness is sufficient.

What this means in practice: a tier-1 analyst acknowledging a monitoring alert at 2:34 a.m. A helpdesk employee opening a ticket about "unusual system behaviour". A department head reporting a suspicious email. Each of these moments is potentially Kenntniserlangung – and therefore a potential deadline trigger.

The most common mistake: organisations assume the deadline starts when the incident response team is assembled. Those who have not carefully prepared their internal escalation chain discover this error only after the 24 hours have already begun to run.

What This Means for Preparation

• Reporting officer + deputy: Both must be directly reachable 24/7 – not "reachable via escalation" but directly. Names, mobile numbers and cover arrangements committed to writing.
• Escalation chain: The path from tier-1 → CISO/ISB → reporting officer must run in under 60 minutes, not in 8 to 12 hours. This chain is the first lever for meeting the 24-hour deadline.
• Applies nights and weekends too: The deadline runs regardless of office hours. The on-call rotation from step 4-2-3 is therefore not an optional comfort feature – it is an operational compliance requirement.

The Early Warning (24 Hours): Minimum First, Completeness Later

What Section 32 BSIG Strictly Requires

Section 32(1)(1) BSIG, implementing Article 23(4)(a) NIS2 Directive, requires exactly two pieces of information in the early warning:

• Malicious or unlawful intent: Does the incident appear to stem from intentional or unlawful conduct? Answer: yes / no / suspected. A reasoned suspicion is sufficient – certainty is not required.
• Cross-border impact: Could other EU member states be affected – for instance because affected systems also serve users in other countries? Answer: yes / no / possibly. If yes, the BSI coordinates with the competent CSIRT of the affected member state.

That is the statutory minimum. Nothing more is strictly required. If you do not yet know whether a targeted attack is involved, mark it as "suspected". If you do not operate cross-border systems, answer the second question with "no".

What the BSI Portal Additionally Expects

The BSI portal (portal.bsi.bund.de) has been the mandatory reporting system for NIS2 entities since 6 January 2026. The portal form expects the following fields beyond the statutory minimum:

• Contact details: Name, role, telephone number and email of the reporting person.
• Timestamps: Discovery time (date + time, UTC) and suspected incident onset time – if different.
• Incident classification: Significant security incident / security incident / near-miss.
• Brief description: Nature of the disruption, affected systems or services, expected duration. An estimate is sufficient.
• Severity colour: red (complete outage) / orange (significant impairment) / yellow (minor impact) / grey (no impact).
• Immediate measures: What initial steps have already been taken. "Incident response team activated" is sufficient as an entry.
• External support: Whether an external IR provider or MSSP is engaged.

What the Early Warning Explicitly Does Not Need to Contain

The most common cause of delayed early warnings is not technical – it is a self-imposed quality standard. IT managers and security officers hesitate because the analysis is not yet complete, because the scope of damage is unknown, because no IoCs have yet been identified. The law does not require any of that.

The early warning does not need to contain:

• Complete root cause analysis
• Proven or quantified scope of damage
• Indicators of Compromise (IoCs)
• Exact count of affected systems or users
• Final severity classification

Incomplete entries marked as "preliminary" or "unknown at time of reporting" are legally correct and complete. The 72-hour full notification fills in and corrects.

The rule of thumb: A good-enough early warning at hour 23 is better than a perfect notification at hour 25. A missed 24-hour deadline is an independent administrative offence – regardless of how well the rest of the reporting process went.

The Full Notification (72 Hours): First Real Assessment

The clock for the full notification runs from the same starting point as the early warning – not 72 hours after the early warning, but 72 hours after Kenntniserlangung. An organisation that files its early warning at hour 23 has around 49 hours remaining for the full notification.

What Section 32 BSIG Adds

Section 32(1)(2) BSIG, implementing Article 23(4)(b) NIS2 Directive, requires three things in the full notification:

• Update: Confirmation or update of all information from the early warning. Anything that has changed since the initial report is corrected here.
• Initial assessment: An assessment of the severity and the actual and potential impact of the incident. This is not a final verdict – it is a documented, best-effort assessment with explicit notes on what is still unknown.
• Indicators of Compromise (IoCs): Where already identified: IP addresses, file hashes, domain names, registry keys or other technical indicators that characterise the incident.

What the BSI Portal Expects for the 72-Hour Notification

The full notification builds on the early warning and expands it. The portal form expects:

• CIA objective affected: Which of the three security objectives is impacted – confidentiality / integrity / availability. Multiple selections are possible and often correct.
• Attack type: targeted (aimed specifically at your organisation) / untargeted (opportunistic, mass campaign) / unknown.
• Cause and attack method: Technical cause description via dropdown and free text – e.g. "ransomware via phishing email, exploitation of CVE-XXXX".
• Vulnerability details: CVE reference (if applicable), affected product and vendor, patch status (available / pending / unavailable), current mitigation measures.
• Affected systems and assets: List of affected IT systems, services and data categories – estimates are explicitly acceptable at this stage.
• Number of users: Estimated number of affected users or customers.
• Financial damage: Estimated damage amount – may still be incomplete at the time of the 72-hour notification, but should give a first order of magnitude.
• BKA referral: Whether you wish the report forwarded to the Bundeskriminalamt for criminal prosecution. If a criminal complaint has already been filed: provide the case reference number.
• Other authorities: Which other authorities have already been informed – data protection authority, BNetzA, BaFin, gematik or other sector-specific bodies.

The Parallel GDPR Notification Obligation

Where personal data is affected by the incident, a GDPR notification obligation under Article 33 GDPR runs in parallel with the NIS2 report. Both obligations must be met independently and on time – they are not interchangeable.

• Different recipients: The NIS2 notification goes to the BSI. The GDPR notification goes to the competent supervisory authority (Landesdatenschutzbehörde or BfDI).
• Different deadline triggers: Article 33 GDPR starts the 72-hour clock when the controller – not any employee – gains knowledge of the breach. The NIS2 trigger may therefore be earlier.
• Different content: Both notifications have different required fields and scope. One does not substitute for the other.

Article B-10a covers the coordination of both reporting obligations in detail.

The Final Report (30 Days): What Section 32 BSIG Actually Requires

This section covers the statutory content requirements of the final report – what §32 BSIG requires the document to contain. The forensic methodology behind it – how a root cause analysis is substantiated and what BSI auditors examine in the final report – is covered in article A-27.

Statutory Minimum: Four Mandatory Elements

Section 32(1)(3) BSIG, implementing Article 23(4)(c) NIS2 Directive, prescribes four mandatory elements:

• Detailed description: Severity and actual consequences of the incident. At this point, "potential" impacts are no longer the focus – the final report requires a definitive assessment: which services were unavailable for how long, how many users were actually affected, what financial damage actually materialised.
• Threat type or root cause: What triggered the incident. This is the most demanding element of the final report (see the next section).
• Remediation measures taken and ongoing: What was done to resolve the incident and what is still in progress. Ongoing measures do not need to be complete – they must be named and given an expected completion date.
• Cross-border impact: Definitive assessment of whether and to what extent other EU member states were affected. The BSI draws on this assessment when coordinating at the EU level.

What "Root Cause" in the Final Report Actually Means

"Root cause" is not a category – it is a specific finding. The difference determines whether the final report withstands a BSI review.

A category sounds like: "phishing attack" or "human error". It describes what happened, not why it was possible.

A finding sounds like: "Unpatched Exchange server CVE-2023-XXXX (security advisory published 14 March 2023), patch not applied because no defined patch process existed for server software outside protection category A. Attacker exploited the vulnerability on [date] to gain initial access."

The BSI review team does not assess whether a finding sounds comfortable. It assesses whether the documented forensic artefacts actually support the claimed root cause. Article A-27 describes what artefacts are required for this.

What a robust finding includes:

• Specific technical vulnerability or misconfiguration – with designation, CVE where applicable
• Timeline: when the vulnerability was known, when it was exploited
• Why the vulnerability was not closed earlier: process, prioritisation, resources
• How the attacker technically exploited the vulnerability

The Progress Report: When the Incident Is Still Active at 30 Days

If the incident is still active 30 days after the 72-hour notification – for example because a ransomware cleanup is ongoing, an APT group is still present in the network, or full system restoration is not yet complete – a final report cannot be produced.

In this case, Section 32 BSIG requires a progress report (Fortschrittsbericht). It takes the place of the final report and documents the current state of the response. The final report is submitted once the incident has been definitively resolved.

Important: The absence of a progress report at the 30-day mark is an independent compliance breach – even if the incident objectively continues. The progress report demonstrates that the response process is active. It is not an admission of weakness; it is a compliance requirement.

Consequences of Missed Deadlines

Sections 65(2)(4) and 65(2)(5) BSIG establish the administrative offences. The trigger in each case is: submitting a report "not at all, incorrectly, incompletely or not on time". This applies to each stage of the cascade independently.

Fine Framework

• Essential entities (Section 28(1) BSIG): up to €10,000,000 or 2% of global annual turnover – whichever is higher.
• Important entities (Section 28(2) BSIG): up to €7,000,000 or 1.4% of global annual turnover – whichever is higher.

Three Points Frequently Underestimated

• Each stage is an independent offence: An organisation that misses both the 24-hour and the 72-hour deadline has committed not one but two independent administrative offences – each carrying the full fine framework.
• Technically sound incident response does not mitigate procedural breaches: An organisation that handled the incident exemplarily but submitted the early warning three hours late has still committed an offence. The outcome of the incident is irrelevant to the procedural violation.
• Management liability under Section 38(2) BSIG: Management is personally liable to the organisation for negligently caused BSIG breaches. This liability is in addition to the entity's own liability as the subject of the administrative fine – it does not replace it.

Where This Article Fits in the Guide

This article covers the content requirements for all three reporting stages. What it does not cover:

• Significance threshold: Whether an incident is reportable at all is covered by article A-07.
• Forensic methodology: How to substantiate a root cause analysis and what BSI auditors examine in the final report is covered by article A-27.
• Portal walkthrough: Step-by-step guidance on submitting reports via the BSI reporting portal is covered by article B-10.

In guide step 4-2-2 you create the reporting templates for all three stages based on the content requirements set out in this article. Ready-to-use templates for the early warning, full notification and final report are available in the guide.

Next in the guide: step 4-3 covers the incident response exercise. Article A-28 explains which exercise formats Section 30(2)(6) BSIG requires and what must be documented.

This article does not constitute legal advice. For questions about the specific legal classification of your situation, consult a lawyer specialising in IT law or cybersecurity law.