Technical & Legal ExpertiseExperience From Numerous NIS2 ProjectsBased in Sindelfingen
§ 32 BSIG
When Does a Reporting Obligation Arise?
Not every security event triggers a reporting obligation. Only significant security incidents within the meaning of § 2 No. 11 BSIG must be reported — events that have caused or could cause significant operational disruption or damage.
Not a Significant Incident
No reporting obligation, but internal documentation is recommended:
Spam email with no harmful effect
A single failed login attempt
Technical errors with no security relevance
Potentially Significant Incident
Assess immediately, check the reporting obligation:
The reporting obligation has three stages. Crucially, the clock starts the moment the entity becomes aware of a significant incident — not once the internal investigation is complete.
Stage 1 — 24 Hours
Early Warning
Initial notification to the BSI: incident confirmed, preliminary assessment, impact as far as known.
Complete analysis, root cause investigation, lessons learned, preventive measures.
A critical mistake in practice: Many companies wait to submit the initial notification until everything has been internally clarified. This breaches the 24-hour deadline. The early warning must be submitted even with incomplete information — missing details are not grounds for delay.
What the Notification Must Contain
Content of an NIS2-Compliant Incident Notification
Name of the affected entity and contact details
Time of discovery and, if known, the start of the incident
Type of incident and affected systems
Initial assessment of severity and impact
Immediate measures taken so far
Cross-border impact (if applicable)
Whether personal data is affected (GDPR coordination)
Note: Many significant security incidents are simultaneously reportable data breaches under the GDPR. Both reporting paths must be served in parallel — which is why the data protection officer should be part of the incident team from the outset.