Friday afternoon, 4:47 PM. An employee opens a convincingly realistic email – supposedly from the IT department. He clicks the link and enters his credentials. Three minutes later, ransomware is spreading through the network.
From the moment someone in your company becomes aware of this: 24 hours until the mandatory report to the BSI.
Since December 6, 2025, §32 BSIG has been in effect – the NIS2 reporting obligation. For approximately 29,500 companies in Germany, this is no longer a theoretical scenario but binding law. And the most common trigger for reportable incidents is email.
What Is the NIS2 Reporting Obligation Under §32 BSIG?
The NIS2 reporting obligation requires essential and important entities to report significant security incidents to the Federal Office for Information Security (BSI). The legal basis is §32 of the revised BSI Act (BSIG), which came into force on December 6, 2025.
Reporting is done exclusively through the BSI Reporting and Information Portal (MIP), which has been active since January 6, 2026. The BSI's principle is clear: Speed over completeness. An incomplete report is better than a late one.
When Does an Email Incident Become Reportable?
Not every spam message and not every phishing attempt triggers the reporting obligation. The decisive factor is the concept of a "significant security incident" under §2 para. 1 No. 11 BSIG.
An incident is considered significant if it:
- Has caused or could cause serious operational disruptions, or
- Has caused or could cause financial losses for the entity, or
- Has caused or could cause significant material or immaterial damage to other natural or legal persons
The wording "could cause" is crucial here. An incident does not need to have already caused damage. As soon as the damage potential is significant, the reporting obligation applies.
Specific Email Scenarios and Their Classification
| Incident | Reportable? | Reasoning |
|---|
| Phishing email lands in quarantine, no click | No | No damage potential realized |
| Employee clicks phishing link, enters credentials | Likely yes | Potential compromise of access credentials |
| Ransomware spreads after phishing email | Yes | Serious operational disruption |
| BEC attack leads to wire transfer | Yes | Financial loss incurred |
| Customer data compromised through unencrypted email | Yes | Damage to third parties |
| DDoS attack takes email system down for 2 hours | Review | Depends on severity of operational disruption |
The 3 Deadlines: What Must Reach the BSI When
The NIS2 reporting obligation is structured in three stages. All deadlines begin with the point of becoming aware – the moment an employee of your entity (during working hours) learns about the incident.
Stage 1: Early Warning – Within 24 Hours
The first report has the character of an early warning. It does not need to contain a complete analysis. Required are:
- Classification of the incident (significant security incident / security incident / near miss)
- Preliminary description: What happened, which systems are affected?
- Assessment: Is there suspicion of malicious or unlawful action?
- Assessment: Could there be cross-border implications?
- Contact details of the reporting party
The BSI explicitly emphasizes: Do not wait for the complete root cause analysis. Report immediately, even with incomplete information.
Stage 2: Full Report – Within 72 Hours
The second report expands the early warning with an initial assessment of the incident:
- Confirmation or update of information from the early warning
- Severity and impact of the incident
- Indicators of compromise (IOCs), as far as already known
- Remedial measures taken and ongoing
- Cross-border implications, if applicable
Stage 3: Final Report – No Later Than 1 Month After Initial Report
The final report contains the complete post-mortem:
- Type of threat and underlying cause
- Complete description of the incident timeline
- Remedial measures taken and their effectiveness
- Preventive measures for the future
If the incident is still ongoing after one month, a progress report is submitted instead of the final report.
Important: The deadlines apply even if your company has not yet registered on the BSI portal. In that case, use the transitional form in the MIP and complete registration without delay.
Practical Scenario: Phishing Attack – Minute by Minute
A concrete example of how the deadlines play out in reality:
Friday, 4:47 PM – Employee opens phishing email, enters credentials on a fake login page.
Friday, 5:23 PM – IT alert: Unusual login attempts with the compromised credentials. An IT employee becomes aware. The 24-hour clock starts now.
Friday, 6:00 PM – Credentials locked, incident response initiated. Initial analysis: Access to shared directories with customer data was possible.
Saturday, 5:23 PM – Deadline for early warning to the BSI. This must be submitted even on weekends. The BSI communicates during emergencies at night and on holidays as well.
Monday, 5:23 PM – Deadline for the full report (72h after becoming aware).
April 24, 2026 – Deadline for the final report (1 month after initial report).
Why Audit Logs Make BSI Reporting Possible in the First Place
This is the critical operational bottleneck: To report to the BSI, you need to know exactly what happened. This requires comprehensive logging of email traffic – and that must already be in place before the incident.
Specifically, you need the following for the BSI report:
- When exactly was the phishing email received and delivered?
- Which email address received the email?
- Which other recipients could be affected?
- Were attachments opened or links clicked?
- What data was potentially in the affected mailboxes?
Without email tracing and tamper-proof audit logs, these questions cannot be answered within 24 hours.
What MailGuard Provides for Reporting Obligations
Conbool MailGuard logs every email event in a 90-day audit log:
- Complete email tracing: Ingress, delivery, opening, clicks
- Quarantine log: Which emails were blocked and why?
- Detected threat types: Phishing, malware, BEC, spoofing
- IOC data: Sender IP, links, file hashes
- Exportable compliance reports – BSI-ready at the push of a button
In the event of an incident, you can export a complete email trace within minutes. That is the difference between a timely report and a fine for delayed reporting.
How Encryption Prevents Reporting Obligations – Not Just Documents Them
The reactive aspect – reporting after an incident – is important. But even more important is the preventive aspect: If incidents are prevented through encryption, no reporting obligation arises.
The example makes it clear: If an employee opens a phishing email, but MailGuard has already isolated the malicious attachment at the gateway, there is no reportable incident. If an email with sensitive customer data is intercepted, but was encrypted through SecureMail, no data protection or NIS2 incident occurs.
The goal is not to report better, but to have to report less.
The Two Protection Layers Against Reporting Obligations
Layer 1: Prevention – MailGuard AI-based detection of phishing, malware, and BEC attacks before they reach the mailbox. SPF, DKIM, DMARC, and ARC validation as baseline protection. Zero-day protection through behavioral analysis.
Layer 2: Damage Mitigation – SecureMail Even if an email is intercepted: Encrypted contents cannot be read. No readable data loss = no reportable incident for third-party damages.
NIS2 Reporting Obligation: Checklist for Email Incidents
Immediately (0–2 hours):
- ☐ Escalate incident internally and initiate incident response
- ☐ Document the time of becoming aware – the clock starts now
- ☐ Start email tracing: Which emails, which recipients, which attachments?
- ☐ Preemptively lock affected accounts or reset passwords
- ☐ Assess: Is this a significant security incident?
Within 24 hours:
- ☐ Submit early warning via the BSI MIP (even with incomplete information!)
- ☐ Classify incident as significant / not significant
- ☐ In parallel: Check GDPR reporting obligation (72h to data protection authority)
Within 72 hours:
- ☐ Full report with IOCs and initial assessment to the BSI
- ☐ Document measures taken
- ☐ Audit log export for traceability
After 1 month:
- ☐ Final report with root cause analysis and remedial measures
- ☐ Document preventive measures
Frequently Asked Questions About the NIS2 Reporting Obligation
Does the 24-hour deadline apply on weekends too? Yes. The deadline begins when an employee becomes aware – regardless of time of day or day of the week. The BSI communicates during emergencies at night and on holidays as well. Designated contacts must therefore be reachable outside of business hours.
What happens if we haven't registered with the BSI yet? The reporting obligation applies regardless. Unregistered entities use the transitional form in the BSI MIP and complete registration without delay. Non-registration does not change the legal situation.
Do we need to report under GDPR and NIS2 in parallel? Yes, if personal data is affected. The NIS2 report (24h to the BSI) and the GDPR report (72h to the competent data protection authority) run in parallel. Both processes must be prepared.
What is the difference between a security incident and a significant security incident? Only significant security incidents are reportable. The threshold lies at serious operational disruptions, financial losses, or significant damage to third parties. A briefly compromised functional mailbox without data exfiltration typically does not exceed this threshold.
Can the report to the BSI be delegated? Yes. The responsibility lies with the entity, but the actual report can be delegated to authorized employees or external service providers. Management remains personally responsible under §38 BSIG for oversight.
What fines are imposed for missed reporting? Essential entities: up to EUR 10 million or 2% of global annual revenue. Important entities: up to EUR 7 million or 1.4% of annual revenue.
Conclusion: Preparation Is Everything
The NIS2 reporting obligation is not a bureaucratic exercise – it is proof of whether your incident management truly works. Companies that cannot report within 24 hours in an incident typically have a structural problem: missing audit logs, missing tracing infrastructure, or missing processes.
Conbool solves the technical part: MailGuard provides the audit logs and IOC data, SecureMail prevents reportable data incidents through encryption, and together they turn a reactive reporting obligation into a controllable compliance process.
Try free for 30 days →
Further reading:
