NIS2 Content Hub
NIS2 Reporting Obligation: 24h/72h/30d Chain per § 32 BSIG
Practical guide for NIS2 security-incident reporting: three reporting stages, what goes in each, downloadable CC-BY template. Based on § 32 BSIG-neu.
NIS2 mandates a three-stage reporting chain under § 32 BSIG for "significant security incidents": an early warning within 24 hours, a formal notification within 72 hours, and a final report within 30 days. Missing any of these deadlines risks a fine of up to EUR 500,000 per incident under § 65(1) No. 3 BSIG. This guide explains each stage in detail, the required content, and provides a CC-BY-licensed template as a PDF download for your internal preparation.
When Does the Reporting Obligation Apply?
The obligation applies to "significant security incidents" as defined in § 32(2) BSIG. An incident is considered significant if it has caused or could cause a severe disruption of service continuity, results in considerable financial losses, substantially affects other natural or legal persons, or involves an unauthorised exfiltration of data.
The key question is whether there is an actual or potential impact on service continuity. The initial assessment rests with the company itself. When in doubt: report and correct later, rather than stay silent and face enforcement action.
Examples of reportable incidents:
- •Ransomware encryption of critical systems causing production downtime
- •DDoS attack with measurable service-availability drop
- •Compromise of privileged accounts (Admin, Domain Admin, Root)
- •Unauthorised data exfiltration from production systems
- •Insider sabotage with access to critical infrastructure
- •Failure of a critical infrastructure component due to a cyberattack
Non-reportable events:
- •Phishing attempts without successful compromise
- •Daily malware detections and blocks by endpoint protection
- •Port scans and automated reconnaissance without intrusion
- •Internally discovered and immediately remediated misconfigurations with no impact
Stage 1: Early Warning (24 Hours)
Deadline: 24 hours from awareness of the significant security incident under § 32(1) No. 1 BSIG. The 24-hour clock starts once a responsible person at the company becomes aware of the incident — not when the analysis is complete.
Recipient: Federal Office for Information Security (BSI) via the BSI portal at portal.bsi.bund.de.
Mandatory information for the early warning:
- 1.Entity registration number from your BSI registration
- 2.Time of awareness (not necessarily the time of the incident itself)
- 3.Initial assessment: malicious (attack) or unintentional (technical failure)
- 4.Cross-border impact: Are other EU member states affected?
- 5.Contact details of the notifying person
The early warning does not require a complete analysis. The BSI understands that full forensic clarity is impossible within 24 hours. What matters is the early signal so the BSI can coordinate if needed.
Common mistake:
Waiting for a complete forensic investigation before reporting. The 24-hour deadline runs from awareness, not from the conclusion of analysis.
Stage 2: Notification (72 Hours)
Deadline: 72 hours from awareness under § 32(1) No. 2 BSIG. The 72-hour notification is an update and deepening of the early warning with a first structured assessment. This intentionally mirrors GDPR Art. 33, so that both notifications can be prepared in parallel.
Required content for the 72-hour notification:
- •Incident assessment: category, severity, type of attack
- •Known indicators of compromise (IoCs): IP addresses, hashes, domains
- •Impact assessment: affected systems, services, data categories
- •Measures taken: isolation, patches, password resets, notifications
- •Update to the early warning: corrections or new findings
- •Whether cross-border impacts are present or have been ruled out
Format: structured form in the BSI portal. It is recommended to run the internal incident response team in parallel with the reporting process and to document in real time. Filling out the notification form for the first time in the middle of an active crisis wastes critical minutes. Our template helps you pre-fill the known fields in advance.
Stage 3: Final Report (30 Days)
Deadline: 30 days from awareness under § 32(1) No. 3 BSIG. The final report is the most comprehensive submission and serves as the BSI's basis for systemic analysis and recommendations to other entities.
Required content for the final report:
- •Detailed technical description of the incident and its timeline
- •Root cause analysis: technical, organisational, and human factors
- •Applied remediation measures: what was done to limit the damage
- •Security measures taken to prevent recurrence
- •Impact on third parties or other EU member states
- •Lessons learned and planned structural improvements
Format: structured BSI portal form with document upload capability. For particularly complex or extended incidents, the BSI may request interim reports. The 30-day deadline does not automatically extend, but the BSI can grant exceptions with a reasonable justification.
Setting Up the Internal Reporting Process
§ 33 BSIG requires a 24/7 contact point. This is not merely a registration formality — it is the operational prerequisite for meeting the 24-hour reporting obligation at all. Without clear roles and escalation paths, the deadline expires before anyone has taken responsibility.
Recommended escalation path:
- 1.Security Operations / IT Operations detects and documents the incident, activates the incident response playbook
- 2.Security Lead / IT Security Officer assesses severity and determines whether reporting is required
- 3.CISO / CSO coordinates the BSI notification and briefs senior management
- 4.Senior Management is informed (liability under § 38 BSIG) and makes strategic decisions (customer communication, criminal complaint)
Clearly separate communication responsibilities: Who reports to the BSI? Who informs customers? Who informs the data protection officer if personal data is involved? Who handles press communications? A lack of clarity here causes dangerous delays in a crisis. Document all roles in an incident response playbook.
Parallel Obligations: GDPR Notification
If personal data is affected by a NIS2-reportable security incident, the GDPR applies additionally. Art. 33 GDPR requires notification to the competent supervisory authority within 72 hours of awareness. Art. 34 GDPR further requires notifying affected individuals if the incident is likely to result in a high risk to their rights and freedoms.
Key distinction: the NIS2 notification goes to the BSI, the GDPR notification goes to the competent data protection authority. The deadlines happen to be identical (72 hours), but the recipients, forms, and required content differ. In practice, both notifications should be prepared in parallel since much of the content overlaps. Ensure the data protection officer is embedded in the escalation path.
Fine Framework for Non-Compliance
§ 65(1) No. 3 BSIG provides for a fine of up to EUR 500,000 per unreported or late-reported incident under § 32 BSIG. Each missed deadline (24h, 72h, 30d) can be sanctioned independently. Structural violations — where reporting failures recur — trigger § 65(2) BSIG, with fines of up to EUR 10 million or 2% of global annual turnover.
Full details on the fine framework and personal executive liability are available on our NIS2 Penalties and Sanctions page.
Avoiding Common Mistakes
- 1.Reporting only after the incident is resolved: Deadlines start from awareness, not from remediation. Waiting for the incident response to conclude typically means the deadline has passed.
- 2.Filing only the 24h stage and forgetting the rest: The three-stage chain is mandatory. An early warning without a 72h notification and 30d final report is a legal violation, even if the early warning was correctly submitted.
- 3.No clear internal responsibility: "Unclear responsibility" is not a defence in a crisis. Roles and escalation paths must be defined in advance and exercised regularly.
- 4.Forgetting the GDPR notification: Where personal data is involved, the BSI notification and GDPR notification must be prepared in parallel. A missed GDPR notification can result in a separate fine.
- 5.Never tested the BSI portal: Opening the portal login and notification form for the first time during an active incident wastes critical time. Test the process during normal operations.
Download: NIS2 Reporting Template (CC-BY-4.0)
Download our structured NIS2 reporting template as a PDF. The template contains three sections for the 24h, 72h, and 30d stages with pre-labelled fields aligned to the BSI portal structure. This allows you to quickly fill in the known information during an incident and prepare the notification in a structured way.
Licence: CC-BY-4.0 — free use with attribution "Kopexa GmbH, kopexa.com". The template is structurally aligned with the BSI portal fields but cannot replace the portal form itself.
Related Resources
- →NIS2 Registration with BSI – Prerequisite: entity number required for notifications
- →NIS2 Requirements Under Art. 21 – Incident handling as one of ten mandatory measures
- →NIS2 Penalties and Sanctions – Fine framework and executive liability
More NIS2 Topics
NIS2 Overview
Applicability check and complete overview
Calculator
Industry-specific applicability check
Roadmap
The 5 phases of NIS2 compliance
Checklist
10-step plan for NIS2 compliance
Implementation
Practical guide with timeline
Costs
Honest NIS2 cost comparison 2026
Requirements
All obligations under Art. 21 in detail
Registration
Step by step through the BSI portal
Supply Chain
Supplier security per § 30(2) No. 4 BSIG
Penalties & Sanctions
Fines and executive liability
ISO 27001 Mapping
Map NIS2 requirements to ISO controls
Threshold Database
142 BSI-KritisV thresholds, machine-readable
Let’s assess where you stand together
Free & non-binding