NIS2 Initial Report to the BSI: Content, Deadlines, and Template

TL;DR

The NIS2 initial report must reach the BSI within 24 hours of becoming aware of a significant security incident.
Mandatory content includes details about the incident, affected services, suspected cause, and cross-border impact.
An incident is considered significant if it can cause severe operational disruption, financial losses, or substantial harm to third parties.
Preparing the reporting process with templates, contact details, and clear responsibilities saves critical hours in an emergency.

Why the Initial Report Is So Critical

A ransomware attack takes down the central inventory management system on Monday morning. The IT department identifies the incident at 8:14 AM. From that exact moment, the clock is ticking: 24 hours to submit an initial report to the Federal Office for Information Security (BSI). Not 24 business hours, but 24 hours from the moment of discovery — even if the incident occurs on a Friday afternoon.

The EU's NIS2 Directive and its German transposition into the BSI Act (BSIG) have significantly tightened the reporting obligations for operators of essential and important entities. The initial report is the first of three mandatory steps. It is designed to enable the BSI to quickly assess the situation and, if necessary, warn other potentially affected entities.

The problem in practice: When an emergency strikes, stress levels are high. Systems are down, management wants answers, customers are calling. If you only start wondering what exactly belongs in the report at that point, you lose valuable time. This article gives you everything you need for a correct and timely initial report.

When Does a NIS2 Report Become Due?

Not every IT incident triggers a reporting obligation. The NIS2 Directive deliberately refers to a significant security incident. The threshold is therefore higher than for everyday technical problems, but significantly lower than many companies assume.

Definition: Significant Security Incident

A security incident qualifies as significant under NIS2 if at least one of the following criteria applies:

Severe operational disruption: The incident significantly impairs the delivery of your services. For a company with around 100 employees, this would be, for example, the failure of the ERP system that brings the entire order processing to a halt.
Financial losses: The incident causes or may cause substantial financial damage. There is no fixed euro threshold, but if the damage is proportionally significant relative to annual revenue, the threshold is reached.
Harm to third parties: Other natural or legal persons may suffer substantial material or immaterial damage as a result of the incident. A data leak involving customer data clearly falls into this category.

Practical Examples: Reportable or Not?

Scenario	Significant?	Reasoning
Ransomware encrypts all file servers	Yes	Severe operational disruption, potential data loss
Phishing email opened, but malware blocked by endpoint protection	No	No actual damage occurred
Attacker exfiltrates customer database with 5,000 records	Yes	Substantial harm to third parties (personal data)
DDoS attack takes down web shop for 6 hours	Probably yes	Severe operational disruption if the web shop is an essential service
Misconfiguration allows unauthorised access to internal test server without production data	No	No significant operational disruption, no sensitive data affected
Compromise of VPN gateway with potential access to the entire network	Yes	Severe operational disruption possible, extent initially unclear

When in doubt: report. The BSI has repeatedly emphasised that a report that later turns out to be less severe has no negative consequences. A late or missing report, however, does — the potential NIS2 fines are significant.

The Three Reporting Stages at a Glance

NIS2 provides for a tiered reporting process. Each stage has its own purpose, its own deadlines, and its own content requirements.

Stage 1: Initial Report (Early Warning)

Deadline: 24 hours after becoming aware of the incident
Purpose: Rapid situational assessment for the BSI, warning to other entities
Level of detail: Basic facts, no complete analysis expected

Stage 2: Updated Assessment

Deadline: 72 hours after becoming aware of the incident
Purpose: In-depth assessment based on initial analysis results
Level of detail: Initial assessment of severity and impact, indicators of compromise (IoCs)

Stage 3: Final Report

Deadline: No later than 1 month after the initial report
Purpose: Complete documentation of the incident and measures taken
Level of detail: Root cause analysis, scope, countermeasures, lessons learned

Between the updated assessment and the final report, the BSI may also request interim reports, particularly if the incident is still ongoing. The deadlines for stages 1 and 2 run in parallel from the moment of discovery. The deadline for the final report begins with the initial report.

What Must Be Included in the Initial Report?

The initial report is deliberately designed as an early warning. You do not need to know every detail after 24 hours. What you must provide are the basic facts that enable the BSI to make an initial assessment.

Mandatory Content of the Initial Report

1. Details of the reporting entity

Full name of the entity
BSI registration number (after NIS2 registration)
Contact details of the designated contact point (name, email, phone)
Industry and sector

2. Description of the incident

Type of incident (e.g. ransomware, data exfiltration, DDoS, supply chain compromise)
Time of discovery (date and time)
Suspected or known start of the incident, if different
Brief description of how the incident unfolded, to the extent known at this point

3. Affected services and systems

Which of your services are impaired or down?
Estimated number of affected users or customers
Estimated impact on service delivery

4. Cross-border impact

Are services in other EU member states affected?
Are customers or partners in other countries affected?

5. Suspected cause

Initial assessment of the cause (if already possible)
Indication that the cause is still unknown

6. Immediate measures taken

What initial countermeasures have been initiated?
Has an external incident response service provider been engaged?

7. Assessment of malicious intent

Whether the incident is presumably attributable to a malicious act
This assessment may be preliminary

What You Do Not Need to Know After 24 Hours

The initial report expressly does not require a complete analysis. The following items are reserved for the 72-hour assessment or the final report:

Exact root cause analysis
Complete list of all affected systems
Detailed forensic results
Final damage assessment
Indicators of Compromise (IoCs) in detail

You may and should honestly write in the initial report: "Cause is still under investigation" or "Extent not yet fully known." The BSI expects a rapid situational report after 24 hours, not a finished analysis.

Template for the NIS2 Initial Report

The following template is based on the requirements of the NIS2 transposition in the BSIG and the BSI's publications to date. Adapt it to your company and keep it readily accessible.

NIS2 Initial Report (Early Warning) to the BSI

Reporting entity

Name: [Company Name GmbH]
BSI registration number: [NIS2-XXXX-XXXX]
Sector: [e.g. Manufacturing / Digital infrastructure / ...]
Contact point: [Name, email, phone of designated reporting contact]

Incident data

Time of discovery: [DD.MM.YYYY, HH:MM]
Suspected start: [DD.MM.YYYY, HH:MM / Unknown]
Type of incident: [Ransomware / Data exfiltration / DDoS / Unauthorised access / Other]

Description [2–4 sentences: What happened? How was the incident discovered? Which systems are immediately affected?]

Example: On 14 March 2026 at 08:14 AM, the IT department discovered that several file servers had been encrypted. The malware was presumably introduced through a compromised email. The ERP system, central file server, and email server are affected. The attack first became visible through unusual network activity at 03:22 AM.

Affected services

[Service 1]: [Status: Down / Impaired]
[Service 2]: [Status: Down / Impaired]
Estimated affected users/customers: [Number]

Cross-border impact

Services in other EU states affected: [Yes, which / No / Not yet known]
Customers/partners in other countries affected: [Yes / No / Not yet known]

Initial assessment

Suspected cause: [e.g. Phishing email with malware attachment / Still under investigation]
Malicious act suspected: [Yes / No / Unclear]

Immediate measures taken

[e.g. Affected systems isolated from the network]
[e.g. External IR service provider engaged]
[e.g. Backup integrity being verified]
[e.g. Password reset initiated for all administrative accounts]

Next steps

Forensic analysis is underway, updated assessment will follow within 72 hours
Contact point is reachable at [phone/email]

This template covers all mandatory fields. In an acute stress situation, it is enormously helpful to only have to fill in the brackets rather than draft a free-text document under pressure. Tools like ISMS Lite generate the BSI initial report directly from captured incident data, so you do not have to start from scratch within the 24-hour deadline.

Who Reports and Where?

The Contact Point

Every NIS2-regulated entity must designate a contact point with the BSI. This person (or functional role) is the official point of contact for all reports. In a company with around 100 employees, this is typically the Information Security Officer (ISO) or the IT manager.

Important: The contact point must be reachable around the clock. This does not mean the ISO can never sleep, but there needs to be an arrangement for deputies and on-call duty. If the primary contact is on holiday or falls ill, a deputy must be designated and known to the BSI.

Recommendations for practice:

Primary contact: ISO or IT manager
Deputy: IT team lead or external IT security service provider
Set up a functional mailbox (e.g. security@company.com) monitored by multiple people
Register a mobile number for emergencies

The Reporting Channel

The initial report goes to the BSI as the central reporting authority. The exact channel is handled via a reporting portal provided by the BSI as part of the NIS2 implementation. In parallel, reporting via email to the known BSI contact addresses remains possible.

If your company is additionally subject to the DSGVO (GDPR) — and that is virtually always the case when personal data is involved — a report to the competent data protection supervisory authority may also be required alongside the BSI report. The two reports have different legal bases and do not replace each other. In a ransomware attack that also affects customer data, you may need to report to two authorities.

Assessment Criteria: When Is an Incident Significant?

Determining whether an incident reaches the reporting threshold is one of the most difficult decisions in the incident response process. Here are the criteria you should systematically check.

Checklist for Significance Assessment

Check each of the following points. If you answer at least one with "yes," a reportable incident is likely:

Service outage: Has an essential service of your entity failed or been severely impaired?
Duration: Is the impairment expected to last longer than a tolerable downtime?
Affected users: Is a significant number of users or customers affected?
Data loss: Has data been deleted, encrypted, modified, or accessed without authorisation?
Personal data: Is personal data affected?
Financial impact: Does the estimated damage exceed an amount that is significant for your company?
Spread: Could the incident spread to other systems, services, or entities?
Recurrence: Does the incident indicate a systemic vulnerability that could enable further attacks?

Grey Areas and Rules of Thumb

In practice, there are many cases that are not clear-cut. The following rules of thumb help:

If you spend more than 10 minutes wondering whether you need to report: Report. The fact that you are unsure indicates a certain level of severity.
If management needs to be informed: Then the incident is probably also reportable.
If you call an external service provider for help: That is a strong indicator of significance.
If backups need to be restored: The incident has obviously impaired productive systems so severely that normal operations were no longer possible.

Preparation: What You Can Do Now

The best time to prepare for a security incident is long before it occurs. The following measures cost little time and save hours in an emergency.

1. Prepare and Store the Reporting Template

Take the template from this article (or create your own based on the BSI requirements) and store it so that it is accessible even during a system outage. An encrypted file server is no use to you if that is exactly where the reporting template is stored.

Recommendations:

Print the template and keep it in the incident response folder
Keep a copy in cloud storage outside your own infrastructure
Make the template available on the ISO's mobile phone

2. Keep Contact Details Up to Date

Ensure the following contact details are always readily accessible:

BSI reporting portal (URL and login credentials)
BSI emergency reporting hotline number
Contact details for external IR service provider (if applicable)
Contact details for the competent data protection supervisory authority
Internal escalation chain: Who informs whom?

3. Clarify Responsibilities

Define in advance and in writing:

Who decides whether an incident is classified as significant?
Who fills in the report?
Who approves the report (four-eyes principle)?
Who submits the report to the BSI?
Who informs management?
Who handles the parallel GDPR report?

In a 100-employee company, this could look like: The IT manager discovers the incident and escalates to the ISO. The ISO assesses significance, fills in the initial report, and briefly coordinates with management. The ISO then submits the report to the BSI and simultaneously tasks the Data Protection Officer with reviewing whether a GDPR report is required.

4. Conduct a Test Run

At least once a year, you should run through the reporting process as a tabletop exercise. Simulate an incident and have the team actually fill in the initial report. This is where typical weaknesses emerge: Where does it get stuck? What information is missing? How long does it take until the report is ready?

5. Document Timestamps

From the moment a suspicion of a significant incident arises, you should consistently record timestamps — a structured procedure for detecting and reporting security incidents helps with this. When was what discovered? When was who informed? When was which measure initiated? You need this documentation not only for the report but also for the subsequent forensic review and the final report.

6. Ensure Reachability Outside Business Hours

An attack does not follow your office hours. Clarify how the contact point can respond in the evenings and on weekends. A simple on-call model where two to three people rotate weekly is sufficient for many mid-market companies.

Common Mistakes in the Initial Report

From practice, several typical errors can be identified that you should avoid:

Reporting too late because you want to clarify everything first. The 24-hour deadline begins with discovery, not with the completion of the analysis. Report with what you know and provide details in the 72-hour assessment.

Miscalculating the start of the deadline. The deadline begins when the entity gains knowledge. This is the point in time when a person with decision-making authority or a responsible function (e.g. SOC, IT management) recognises the incident as potentially significant. Not when management has been informed.

Endlessly coordinating the report internally. In an emergency, the clock is ticking. A brief sign-off by management makes sense, but a three-stage approval process involving legal, PR, and the board costs time you do not have. Clarify this process beforehand.

Not keeping a copy. Always save a copy of the submitted report with a timestamp. You need it for follow-up reports and as evidence of timely reporting.

Forgetting the GDPR report. If personal data is affected, the BSI report alone is not sufficient. The report to the data protection supervisory authority runs through a separate channel with its own deadlines (72 hours under GDPR Art. 33).

How ISMS Lite Supports the Reporting Process

When the pager goes off in the middle of the night, you do not want to start searching for templates and calculating deadlines. ISMS Lite takes exactly this mechanical work off your hands so you can focus on the actual incident response.

Incident Module with Live Countdown

As soon as you create a security incident in ISMS Lite and mark it as potentially significant, three countdown timers start automatically:

24h timer for the initial report (early warning)
72h timer for the updated assessment
30-day timer for the final report

The timers run in real time and are immediately visible on the dashboard. As a deadline approaches, you receive notifications via email and within the system. This way, you keep an overview even when technical remediation is running in parallel.

AI-Generated Initial Report

ISMS Lite can generate a draft of the BSI initial report from the incident data you capture during incident response anyway. You enter the known facts into structured fields (type of incident, affected systems, time of discovery, initial measures), and the system creates a submission-ready text covering all mandatory fields.

This saves you the effort of drafting under pressure and ensures that no mandatory field is forgotten. You review the draft, adjust it if necessary, and approve it.

Central Documentation

All information about the incident — from initial detection through the reports to the final report — is in one place. This facilitates not only the follow-up reports but also subsequent review and evidence for auditors that the reporting process was completed on time and in full.

Preparation During Normal Operations

Even outside an active incident, ISMS Lite supports your preparation. The contact details for the BSI reporting authority, the internal escalation chain, and external service providers are stored in the system. The reporting template is accessible at any time. And with the integrated exercise function, you can regularly test the reporting process without an actual report going to the BSI.

Your Next Steps

The NIS2 reporting obligation is not a paper tiger. Fines for late or missing reports can be severe, and the personal liability of management is a real concern. But the actual motivation should be different: A well-prepared reporting process is part of a functioning incident response. And that protects not only against fines but against the real damage of a security incident.

Your next steps:

Check whether your company is NIS2-regulated. If so, ensure that BSI registration has been completed and a contact point has been designated.
Prepare the reporting template. Take the template from this article as a starting point and adapt it to your company. Print it out and store it in an offline-accessible location.
Clarify responsibilities. Who decides, who reports, who approves? Write it down and communicate it to the team.
Conduct a test run. Simulate an incident and fill in the report under time pressure.
Set up technical support. A tool like ISMS Lite with automatic countdowns and reporting templates takes the mechanical work off your hands in an emergency.