NIS2 Reporting Obligation: 24h/72h and Final Report per § 32 BSIG

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 free 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.

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 Incident Report (English) helps record the incident, supporting evidence and response decisions.

Stage 3: Final Report (One Month)

Deadline: no later than one month after submitting the 72-hour notification, under § 32(1), first sentence, No. 4 BSIG. For an ongoing incident, submit a progress report first. 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. 1.Security Operations / IT Operations detects and documents the incident, activates the incident response playbook
2. 2.Security Lead / IT Security Officer assesses severity and determines whether reporting is required
3. 3.CISO / CSO coordinates the BSI notification and briefs senior management
4. 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.

Template: Incident Report

Download the Incident Report: a 25-page fillable PDF covering initial assessment, affected people and systems, business and financial impact, evidence, response decisions, recovery, root cause analysis and corrective actions. Reporting obligations and actual notifications are recorded separately.

Preview the report and its contents →

This is an internal incident record; official notifications must still use the applicable reporting channel.

Frequently asked questions

Related Resources