§32 BSIG

NIS2 Incident Reporting Playbook

§32 BSIG requires three-stage incident reporting to the BSI: 24-hour early warning, 72-hour notification, and 1-month final report. Missing any deadline is a separate violation – independent of the incident itself.

Incident Reporting Under NIS2

§32 BSIG implements Article 23 of the NIS2 Directive. It establishes a mandatory three-stage reporting regime for significant security incidents. Every entity classified as a besonders wichtige Einrichtung or wichtige Einrichtung must report to the BSI when an incident meets the significance criteria. This obligation cannot be delegated to a managed security service provider – the entity itself is responsible for timely reporting.

The reporting timelines are strict and begin when the entity becomes aware of the incident – not when the investigation is complete. This is a critical distinction: the 24-hour early warning must be submitted based on initial awareness, even if the full scope and impact are unknown. Waiting for complete information before reporting is itself a violation.

Three-Stage Reporting Timeline
Each stage has a specific deadline, required content, and purpose. The deadlines run from the moment the entity becomes aware that an incident is – or is likely to be – significant.
1

Early Warning (Frühwarnung)

Within 24 hours

The initial notification to the BSI that a potentially significant incident has been detected. Must be submitted within 24 hours of becoming aware of the incident. The purpose is to enable the BSI to assess cross-sector impact and issue warnings to other entities if necessary.

  • Confirmation that a significant incident has occurred or is suspected
  • Whether the incident is suspected to be caused by unlawful or malicious acts
  • Whether the incident could have cross-border impact
  • Entity name, sector, and contact details for follow-up
2

Incident Notification (Meldung)

Within 72 hours

A more detailed notification updating the early warning with additional information gathered during the initial response. Must be submitted within 72 hours of awareness. Updates the BSI on the incident's nature, severity, and initial impact assessment.

  • Updated assessment of the incident's severity and impact
  • Indicators of compromise (IoCs) where available
  • Initial assessment of the nature and cause of the incident
  • Measures taken or planned to mitigate the incident
  • Cross-border impact assessment if applicable
3

Final Report (Abschlussbericht)

Within 1 month

A comprehensive final report submitted within one month of the incident notification (or the resolution of the incident, if later). If the incident is still ongoing at the one-month mark, an interim progress report is required, with the final report due within one month of incident resolution.

  • Detailed description of the incident, including severity and impact
  • Root cause analysis – the type of threat or vulnerability that caused the incident
  • Measures applied and ongoing to mitigate the incident and its effects
  • Cross-border impact if applicable
  • Lessons learned and corrective actions planned or implemented
What Makes an Incident 'Significant'
Not every security event triggers the §32 BSIG reporting obligation. An incident is significant if it meets one or more of the following criteria, as defined in Article 23(3) NIS2 Directive and specified further in CIR 2024/2690 Article 3.

Service disruption

The incident has caused or is capable of causing severe operational disruption to the services provided by the entity. For DNS providers and TLD registries, the CIR specifies thresholds including availability below 99.9% or incorrect DNS response delivery.

Financial loss

The incident has caused or is capable of causing financial loss to the entity. CIR 2024/2690 Article 3 specifies a threshold of EUR 500,000 or 5% of annual turnover – whichever is lower. This includes direct costs (remediation, forensics) and indirect costs (revenue loss, contractual penalties).

Impact on other entities

The incident has caused or could cause considerable damage to other natural or legal persons. This includes incidents that propagate through supply chains, affect shared infrastructure, or expose data belonging to third parties.

Data breach

The incident involves unauthorised access to, destruction of, or alteration of data. Note that NIS2 incident reporting under §32 BSIG is separate from and additional to GDPR breach notification under Art. 33/34 GDPR – both obligations may apply simultaneously.

Extended outage

The incident has caused or is expected to cause a prolonged disruption to the entity's services. The duration threshold is not fixed in the Directive but CIR 2024/2690 provides entity-specific criteria. Extended outages affecting critical services are presumed significant.

Required Reporting Fields
The BSI reporting portal requires structured information. Having these fields prepared in advance significantly reduces the risk of missing the 24-hour deadline.
  • Entity identification

    Company name, BSI registration number, sector classification, NACE code, and designated contact point for incident coordination. This information should be pre-configured in your incident response plan – not looked up during a crisis.

  • Incident nature and classification

    Type of incident (ransomware, DDoS, data breach, insider threat, supply chain compromise, etc.), affected systems and services, timeline of events from detection to current state, and initial severity classification.

  • Impact assessment

    Number of affected users or customers, services disrupted, estimated financial impact, data categories affected (if any), and duration of disruption. For the early warning, estimates are acceptable – precision comes in the 72-hour notification and final report.

  • Cross-border impact

    Whether the incident affects or could affect entities or citizens in other EU member states. This triggers information sharing between national CSIRTs and may involve ENISA coordination. Must be assessed in both the early warning and subsequent notifications.

  • Response measures

    Actions taken to contain, eradicate, and recover from the incident. Includes technical measures (isolation, patching, credential rotation), communication measures (customer notification, stakeholder briefing), and organisational measures (crisis team activation, external support engagement).

Where and How to Report
Reporting is exclusively through the BSI's digital reporting portal.

All incident reports under §32 BSIG must be submitted via the BSI's official reporting portal. The BSI does not accept reports by email, telephone, or letter as a substitute for portal submission – though telephone contact with the BSI's incident response team (CERT-Bund) is appropriate for coordinating response to critical incidents in parallel with the formal report.

The reporting portal is available at the BSI's website under the NIS2 section. Access requires prior registration under §33 BSIG – which means unregistered entities face a compounded problem: they cannot file incident reports through the proper channel because they have not completed the prerequisite registration. This is another reason why BSI registration must not be delayed.

Penalties for Reporting Failures
Non-reporting is penalised independently of the incident itself. A company that suffers an incident and handles it well technically but fails to report faces separate enforcement action.

Up to EUR 10,000,000 or 2% of turnover

Besonders wichtige Einrichtungen

The higher of EUR 10 million or 2% of worldwide annual turnover of the preceding business year. This applies to essential entities in sectors listed in BSIG Annex 1 (energy, transport, banking, health, water, digital infrastructure, space, public administration).

Up to EUR 7,000,000 or 1.4% of turnover

Wichtige Einrichtungen

The higher of EUR 7 million or 1.4% of worldwide annual turnover. This applies to important entities in sectors listed in BSIG Annex 2 (postal services, waste management, chemicals, food, manufacturing, digital providers, research).

Personal liability – §38 BSIG

Management (Geschäftsleitung)

If management was aware of an incident and failed to ensure timely reporting, this constitutes a violation of the oversight duty under §38(1) BSIG. Management can be held personally liable to the company for damages arising from the reporting failure – separate from penalties imposed on the company itself.

Sources
  • NIS2 Directive (EU) 2022/2555 – Article 23 (Reporting obligations)
  • BSIG – §32 (Meldepflichten bei erheblichen Sicherheitsvorfällen)
  • BSIG – §38 (Billigung, Überwachung, Schulung – Geschäftsleitung)
  • BSIG – §65 (Bußgeldvorschriften)
  • CIR (EU) 2024/2690 – Article 3 (Significance of incidents), Article 4 (Recurring incidents)
  • ENISA – Guidance on NIS2 incident reporting obligations and templates (2024)
  • BSI – NIS2 reporting portal documentation and FAQ
Be Reporting-Ready Before the Incident Hits
The platform pre-configures your BSI reporting fields, maintains an incident register with classification workflows, and tracks the 24h/72h/1-month deadlines – so you meet every obligation under pressure.