NIS2 Reporting Templates: §32 BSIG Notification Stages

Written by the NIS2Compass editorial team | Last updated: August 2026

Under §32 BSIG, you report a significant security incident in three stages: an early warning within 24 hours, an initial notification after 72 hours, and a final report after one month. Below is a fully worded sample text for each stage — ransomware, data exfiltration, and DDoS — ready to adapt, not to type from scratch under time pressure. The NIS2Compass Guide walks you through the full reporting process in Chapter 4.

What notification stages does §32 BSIG require?

§32 BSIG requires essential and important entities to submit three consecutive reports: the early warning within 24 hours, the initial notification (colloquially the "full report") within 72 hours, and the final report no later than one month after that. All three run under the same incident ID in the BSI portal — updates, not three separate forms.

Given the current threat landscape, this cadence is no formality: according to Bitkom Wirtschaftsschutz 2025, 87 percent of German companies were affected by data theft, espionage, or sabotage in the past twelve months, with total damages of 289.2 billion euros. Knowing the deadlines in advance means not wasting time hunting for the right wording when it counts.

The three stages at a glance:

• Early warning: deadline 24 hours after becoming aware (§32 Abs. 1 Nr. 1 BSIG). A signal report noting suspicion of a malicious act and possible cross-border effects.
• Initial notification (the "full report"): deadline 72 hours after becoming aware (§32 Abs. 1 Nr. 2 BSIG). Confirms or updates the early warning, with a first assessment of severity, impact, and indicators of compromise.
• Final report: deadline 1 month after the initial notification (§32 Abs. 1 Nr. 4 BSIG). A complete description of the incident, root cause analysis, and remediation measures taken.

The law also allows for two special cases: the interim report (§32 Abs. 1 Nr. 3 BSIG), which the BSI requests only on demand and which has no fixed deadline, and the progress report (§32 Abs. 2 BSIG), which replaces the final report for incidents still ongoing.

Whether your case reaches the significance threshold at all is covered in When is a security incident reportable? (§32 BSIG) — this article picks up where that one leaves off, at wording the report itself. For a full overview of deadlines and recipients, see NIS2 incident reporting: when, what, and to whom?. NIS2Compass uses the incident ID as the thread connecting all three stages in the Guide; it's assigned automatically with your first report.

How to actually word the early warning is covered in the next section, with ready-to-use sample texts.

How do you word the early warning (24 hours)?

The early warning is a pure signal report: suspicion of a malicious act, possible cross-border effects, initial measures — that's all §32 Abs. 1 Nr. 1 BSIG requires in the first 24 hours. Below is a fully worded sample text for each scenario — ransomware, data exfiltration, and DDoS — ready to adapt directly.

In the BSI portal, you enter the following information, among other things, for the early warning:

• Classification: significant security incident, security incident, or near miss
• Situation assessment: color code red/orange/yellow/gray for a rough urgency rating
• Free-text description: what was detected and which systems are affected
• Time and duration: the moment of becoming aware and the incident's duration so far
• Spread: affected locations and possible cross-border effects
• Suspicion of a malicious act: yes/no with a brief assessment
• Immediate measures: steps already taken
• Contact person: name, role, phone, email

The three sample texts below follow the same case stories throughout the article; ransomware, data exfiltration, and DDoS return in the next section, at a considerably more advanced level of knowledge.

How brief the early warning may be follows directly from the current threat landscape. According to the BSI situation report on IT security in Germany 2025, newly discovered vulnerabilities per day rose 24 percent between July 2024 and June 2025. At that pace, there wouldn't be time for a solid root-cause analysis within 24 hours anyway — the early warning is meant to sound the alarm, not deliver a final assessment.

Example: Ransomware — specialty machinery manufacturer, 140 employees, important entity (Annex II BSIG), reported approx. 7.5 hours after becoming aware

On [date], at 06:15, the early IT shift discovered that several file servers at the main site are encrypted, with a ransom demand present on the affected systems. Affected: the central ERP data store and parts of manufacturing control; production has been interrupted on two lines since discovery. Suspicion of a malicious act (ransomware); no cross-border effects identifiable at this time. Initial measures: affected network segments isolated, the IT emergency team activated, external forensics engaged. A detailed root-cause analysis is not yet available and will follow with the 72-hour notification. Reporting contact: [name, role, phone, email].

Example: Data exfiltration — regional hospital group, 320 employees, essential entity (healthcare sector), reported approx. 14.5 hours after becoming aware

On [date], at 19:20, a SIEM alert flagged an unusual data export from the patient management system; the IT on-call team confirmed the incident at 19:45. A compromised administrator account is presumed involved, through which extensive patient and employee records were exported. Suspicion of a malicious, unauthorized act; whether data was actually exfiltrated is still being investigated. No cross-border effects identifiable at this time. Initial measures: the affected account disabled, access to the patient management system restricted, forensic capture initiated. Reporting contact: [name, role, phone, email].

Example: DDoS — regional energy provider, 210 employees, essential entity (energy sector), reported approx. 5.8 hours after becoming aware

On [date], at 13:10, network monitoring detected a massive traffic spike on the customer portal; the portal and the online meter reading system have been unreachable ever since. A suspected DDoS attack; internal grid control and security of supply not affected at this time. Suspicion of a malicious act; no cross-border effects identifiable. Initial measures: traffic filtering activated via the hosting provider's upstream DDoS protection; the customer portal is temporarily reachable via a static fallback page with contact information. Reporting contact: [name, role, phone, email].

How do you word the initial notification after 72 hours (the "full report")?

The 72-hour notification confirms or corrects the early warning and, for the first time, delivers an assessment of severity, cause, and indicators of compromise. It updates the same incident ID, so it isn't a new form. The three examples below continue the cases from the previous section.

Compared with the early warning, the following information is added:

• Protection goal affected: confidentiality, integrity, and/or availability, named concretely rather than merely assumed.
• Attack type: classified as targeted or untargeted. Targeted means the attack was recognizably directed at the company; untargeted refers to broadly scattered attack waves.
• Cause: a preliminary assessment is acceptable here too, for example an exploited vulnerability or a phishing incident.
• Indicators of compromise (IOCs): IP addresses, file hashes, or suspicious domains, where available.
• Affected systems and users: estimated numbers.
• Financial damage: a rough estimate.
• Referral to law enforcement: where relevant, a note on a requested referral to the BKA and any criminal complaint already filed.

Details on the individual fields are in the BSI portal guide; the BSI uses this information to assess criticality and decide on further action.

In practice, only 48 to 50 hours often remain after the early warning to prepare this level of detail, since the 72-hour deadline runs from when the incident was discovered, not from when the early warning was filed. Submitting the early warning late shortens your own window for the second stage.

If personal data is affected, the independent 72-hour deadline under Art. 33 GDPR to the state data protection authority runs in parallel — both channels must be handled separately and don't automatically stay in sync.

Example: Ransomware, 72-hour notification

The ransomware incident reported on [date] is confirmed and updated as follows: confidentiality and availability of data on the encrypted systems are affected; no data exfiltration is identifiable so far, though forensic review continues. Presumed cause: exploitation of an unpatched VPN component (preliminary classification); indicators of compromise — two IP addresses and one file hash — are attached. The attack is classified as targeted. Backup recovery is underway, at around 60 percent; one manufacturing line is back in operation. A criminal complaint has been filed with the relevant state police, with a referral to the BKA requested.

Example: Data exfiltration, 72-hour notification

The reported incident is confirmed: through the compromised administrator account, records for approximately 4,200 patients and 85 employees were exported, including names, insurance numbers, and, in part, diagnostic data. Confidentiality is therefore demonstrably breached; availability and integrity of the systems are unaffected. Classified as targeted; cause: an administrator password obtained via phishing, lacking multi-factor protection. Indicators of compromise are available and being submitted. The relevant state data protection authority was notified in parallel under Art. 33 GDPR. A criminal complaint is being prepared.

According to the Bitkom Wirtschaftsschutz study 2025, around one in four German companies falls victim to a DDoS attack every year; the following incident belongs to that group.

Example: DDoS, 72-hour notification

The incident is confirmed: the customer portal was unreachable for around seven hours, affecting only the web application's availability; internal grid control and energy supply were not impacted at any point. Classified as targeted and volume-based (Layer 3/4 DDoS, peak load around 40 Gbit/s); no extortion attempt or ransom demand. An estimated 18,000 customers were affected by the outage. After filtering through the hosting provider's DDoS protection, the portal has been fully reachable again since [time]. Forensic analysis of the attack sources is ongoing.

For the 72-hour notification, the NIS2Compass Template Library provides the "Full Report Notification Form" (§32 Abs. 1 Nr. 2 BSIG) as a ready-to-use Word template.

If certain details are still missing at this point — for example because the forensic analysis isn't finished — that doesn't have to delay the report: a justifiably incomplete 72-hour notification is permissible.

How do you word the final report (1 month)?

The final report is the complete documentation: a concrete cause instead of a category, all implemented and ongoing remediation measures, and the final severity rating. If an incident takes longer than a month to resolve, a progress report under §32 Abs. 2 BSIG takes its place — the final report then follows later.

Unlike the earlier reporting stages, the BSI is no longer asking for initial impressions here, but for solid facts. The severity rating, only provisionally estimated in the early warning, is now determined conclusively.

The quality benchmark for the final report is cause as a finding, not a category. "Phishing attack" or "ransomware" describe only the incident type, not its origin. §32 Abs. 1 Nr. 4 BSIG instead requires a detailed description of the threat type or root cause: which vulnerability was exploited, how long it had been known, and exactly how the attacker proceeded.

For an exploited software vulnerability, what matters is whether a patch was already available at the time of the attack; for stolen credentials, whether a safeguard such as multi-factor authentication was missing.

Complete documentation includes not only measures already finished but also those still underway at the time of reporting, for example a multi-stage rollout of new access rules.

If the follow-up work takes longer than a month, the final report doesn't simply disappear — under §32 Abs. 2 BSIG, a progress report takes its place: an interim update reflecting the current state of knowledge rather than a definitive assessment. In practice: anyone not finished after 30 days still reports, just an interim status instead of a conclusion. The actual final report follows once the incident is genuinely resolved.

The link to fines is close here: under §65 BSIG, a missing, incorrect, incomplete, or late final report is a separate offense, carrying fines of up to 10 million euros for essential entities and up to 7 million euros for important ones. This stage is taken just as seriously as the early warning and the 72-hour notification.

Here's what the three case stories from this guide look like at the final-report stage. Each follows the same structure: date, concrete cause, final severity rating, remediation measures implemented.

Example: Ransomware, final report (day 27)

The incident was resolved as of [date, 27 days after becoming aware]. Cause: a VPN component unpatched for seven weeks, combined with a successful phishing email to an employee in manufacturing control, which gave the attacker access to the internal network and let them encrypt the central file servers. Severity: significant, with a four-day disruption across two manufacturing lines and estimated damages of around 260,000 euros. Remediation implemented: complete rebuild of the affected systems, mandatory multi-factor authentication for all remote access, and a revised patch process with a maximum 14-day deadline for critical vulnerabilities. No cross-border effects. The incident is considered resolved; a progress report is not required.

Example: Data exfiltration, final report (day 24)

The incident was resolved as of [date, 24 days after becoming aware]. Cause: an administrator account without multi-factor authentication, its credentials obtained via a phishing email; within roughly 90 minutes, the attacker exported records for 4,238 patients and 85 employees. Severity: significant, with material damage arising mainly from external forensic support and notifying those affected, estimated at 95,000 euros; no disruption to patient care. Remediation: mandatory multi-factor authentication for all administrator accounts, reduced access rights under the least-privilege principle, and notification of affected individuals under Art. 34 GDPR completed. No cross-border effects.

Example: DDoS, final report (day 12)

The incident was resolved as of [date, 12 days after becoming aware]. Cause: a volume-based DDoS attack on the publicly accessible customer portal, presumably via a rented botnet; no claim of responsibility or ransom demand was received. Severity: significant, due to the roughly seven-hour unavailability of a customer-facing service at an energy-sector operator; the energy supply itself was unaffected. Remediation: a permanent switch to scalable DDoS protection with greater capacity headroom, a separate emergency page independent of the main infrastructure, and an update to the emergency plan for the scenario "availability attack without data impact." No cross-border effects.

The three scenarios are constructed examples and are intended solely for illustration.

What does the early warning explicitly NOT need to be?

The early warning is not a forensics report: the BSI explicitly does not require a complete case description, only a quick signal within 24 hours. Anyone who waits to report until every fact is confirmed misses the deadline needlessly — in practice, this is the most common mistake made under time pressure.

The BSI itself frames it this way (paraphrased from the German original):

An incident should be reported as early as possible, regardless of what information is available at the time. — BSI, NIS-2 reporting obligation

What doesn't belong in the early warning?

The following items belong in the 72-hour notification or the final report, not in the first 24 hours:

• Root-cause analysis: the technical cause of the incident
• Quantified scope of damage: affected records, financial impact
• Complete IOC list: all indicators of compromise in detail
• Final system inventory: every affected system named individually
• Confirmed attacker identity: attribution to a specific threat actor group
• Complete GDPR assessment: the detailed data protection classification

In short: speed over completeness. An incomplete but timely early warning is not a legal problem, since corrections are made via the 72-hour notification and the final report — not a new report. The violation actually subject to fines is lateness, not incompleteness.

Even a statement like "we don't yet know whether this is ransomware or another type of incident" is acceptable as an early warning, as long as the timestamp and mandatory fields — such as suspicion of a malicious act and cross-border effects — are answered as best as possible.

An analogy from data protection law shows how seriously supervisory authorities take late reports: the Dutch Data Protection Authority fined Booking.com 475,000 euros in 2021 — not for the incident itself, but because the notification reached the authority only after 25 days instead of the required 72 hours. No published NIS2 fine decisions exist yet, but the underlying supervisory logic is likely comparable.

Where and how do you submit the report?

All three reporting stages run through the same BSI portal (portal.bsi.bund.de); access is via "Mein Unternehmenskonto" (MUK) using an ELSTER organization certificate — there is no separate BSI account. The deadline begins when an employee becomes aware of the incident, not with the incident itself or a pure machine alert.

A BSI-MELDIS or a separate meldestelle.bsi.bund.de no longer exists — both names are outdated. Registered entities report exclusively through MUK; entities not yet registered can use an online form without prior registration on a transitional basis.

What starts the deadline is the moment an employee actually recognizes the incident during working hours, not the technical timestamp of the incident. Reports from service providers or customers count from the moment they reach your own organization. A pure alert from a monitoring system without human review doesn't yet trigger the 24-hour deadline.

Round-the-clock reachability of the registered contact point is only required for KRITIS operators. Essential and important entities can get by with a functional mailbox monitored during business hours. Since the deadline can still run at night or on weekends, extending your internal reporting chain's reachability is worthwhile anyway.

Don't store BSI portal credentials exclusively on a system that could itself be affected by ransomware. The registration deadline ended on 6 March 2026; anyone not yet registered should catch up immediately. Step 4-2 of the NIS2Compass Implementation Guide walks you through building your BSI reporting process: from defining what counts as significant, through templates for all three stages, to portal setup.

Frequently Asked Questions

What goes into the early warning if I still don't know all the details after 24 hours?

Report anyway. The early warning is a signal report with minimal mandatory information — suspicion of a malicious act, possible cross-border effects, initial immediate measures. A preliminary, incomplete but timely report is significantly better than a late, complete one. Corrections follow via the 72-hour notification.

Do I have to fill out a new form for each of the three reporting stages?

No. All three reporting stages run under the same incident ID in the BSI portal. The 72-hour notification and the final report are updates to the early warning you already submitted, not new cases. Open the existing incident via "Meine Sicherheitsvorfälle" in the portal and add the new information there.

Do I need a separate BSI account to submit a report?

No. Access to the BSI portal (portal.bsi.bund.de) works through "Mein Unternehmenskonto" (MUK) using an ELSTER organization certificate. A separate BSI account with its own password or its own two-factor app no longer exists. Set up access well in advance of your first incident — not under time pressure.

Does my reporting chain need to be reachable around the clock?

Only operators of critical facilities (KRITIS) are required to keep their registered contact point reachable at all times. Essential and important entities can get by with a functional mailbox monitored during business hours. Since the 24-hour deadline runs from the moment of becoming aware, though, it's still worth extending reachability beyond regular office hours.

Can I withdraw or correct a BSI report that has already been submitted?

You can't withdraw it. Once submitted, a report can only be corrected or supplemented through follow-up reports — the 72-hour notification and the final report exist precisely for that purpose. This is established practice, as also described in the NIS2Compass pillar article on NIS2 reporting obligations.