NIS2 Reporting Deadlines at a Glance: 24h, 72h, 1 Month — What Is Due When

Friday evening, 6:47 PM. Your admin notices unusual data traffic on the backup server. By Saturday morning, the suspicion is confirmed: ransomware has encrypted parts of your infrastructure. From that exact moment, the clock is ticking. You have 24 hours for the first report to the BSI. And that is just the beginning.

The NIS2 Directive introduces a three-stage reporting system that is significantly stricter than anything German companies have known from the IT Security Act or the DSGVO (GDPR). Missing the deadlines risks significant fines. Knowing them and being prepared means staying in control even in an emergency.

Who Do the NIS2 Reporting Deadlines Apply To?

Before we dive into the deadlines: The reporting obligations do not apply to every company. NIS2 distinguishes between essential entities and important entities. You are affected if your company operates in one of the 18 defined sectors and exceeds certain thresholds for employee count or revenue — details can be found in the NIS2 overview for SMEs.

For a company with around 100 employees in a sector such as IT services, manufacturing, or energy supply, the probability of being classified as an important entity is high. The reporting deadlines apply identically to both categories. The difference lies in the fine amounts and the intensity of regulatory oversight.

The Three Reporting Stages in Detail

NIS2 requires three successive reports for a significant security incident. Each has its own purpose, level of detail, and deadline.

Stage 1: Initial Report (Early Warning) Within 24 Hours

The initial report is deliberately kept low-threshold. You do not yet need a complete analysis, root cause identification, or final assessment. At this stage, the BSI primarily wants to know that something has happened.

What must be reported:

• That a significant security incident exists (or there is reasonable suspicion)
• Whether the incident is presumably attributable to unlawful or malicious actions
• Whether cross-border impact is likely

What you do not need to know at this point:

• The exact attack vector
• The full extent of the damage
• The identity of the attackers

The 24-hour deadline sounds tight, and it is. But the initial report is intentionally designed as an early warning. You report the incident so the BSI can warn other potentially affected entities early. Think of it like a fire alarm: It needs to come quickly, not in detail.

Stage 2: Assessment Update Within 72 Hours

After three days, the BSI expects a significantly more substantive report. Now it is about the first professional assessment of the incident.

What must be reported:

• Updated information from the initial report
• An initial assessment of the incident including severity and impact
• Known or suspected indicators of compromise (IoCs)
• Type of threat or cause, to the extent already identifiable

The 72-hour report is the core of the NIS2 reporting process. This is where your incident response process proves itself. You need reliable technical data at this point: Which systems are affected? What data may have been exfiltrated? What countermeasures are already underway?

For a company with 100 employees, this means concretely: Your IT team or external service provider must be able to deliver an initial forensic analysis within three days. Anyone who only starts searching for an incident response partner during an emergency will struggle to meet this deadline.

Stage 3: Final Report Within One Month

The final report is the comprehensive review of the incident. This is where everything is documented in detail: what happened, why it happened, and what the company learned from it.

What must be reported:

• Detailed description of the incident including severity and impact
• Type of threat or cause (root cause)
• Remediation measures taken and ongoing
• Any cross-border impact

If the investigation is still ongoing after one month, you submit a progress report instead of the final report. The definitive report then follows within one month of completing incident handling.

When Does the Clock Start Ticking?

One of the most important and simultaneously most misunderstood points: The deadlines begin from the moment of awareness of the significant security incident. Not from the time the attack took place. Not from the time the board was informed. But from the moment the organisation as an entity becomes aware.

What does awareness mean in concrete terms? If your monitoring system triggers an alert at 3:00 AM and your security analyst reviews it at 8:00 AM and classifies it as a significant incident, the deadline begins at 8:00 AM. However, if the alert was automatically sent by email to the responsible employee and they only read it the next day, it can be argued that awareness existed from the moment the information was received.

This is precisely why clean documentation of the chain of events is so important. In case of doubt, you must be able to prove when you knew what. A comprehensive incident log is not optional — it is your safeguard.

What Counts as a "Significant Security Incident"?

Not every IT incident triggers the reporting obligation. NIS2 defines a security incident as significant if it:

• has caused or may cause severe operational disruption of services,
• results in financial losses for the affected entity, or
• affects other natural or legal persons through substantial material or immaterial damage.

In practice, this means: A failed phishing attempt is not a reportable incident. A successful ransomware attack that takes down your production control system definitely is. Between these extremes lies a grey area that you should address in advance through clear assessment criteria in your incident response plan.

NIS2 vs. GDPR: Where Are the Differences?

Many companies are already familiar with the reporting obligation under the DSGVO (GDPR). There, data protection breaches must be reported to the competent data protection authority within 72 hours. The NIS2 reporting deadlines differ in several key respects:

A critical point: In a ransomware attack that also affects personal data, both reporting obligations apply in parallel. You report to the data protection authority under GDPR — see Reporting a GDPR data breach — and to the BSI under NIS2. The deadlines run independently of each other. This makes organisational preparation all the more important, because managing two parallel reporting processes simultaneously in an emergency requires clear responsibilities and prepared templates.

Consequences of Missed Deadlines

The NIS2 Directive relies on deterrent sanctions. The fine framework is deliberately modelled on the GDPR to ensure companies take reporting obligations seriously.

For essential entities:

• Up to EUR 10 million or 2% of global annual revenue (whichever is higher)

For important entities:

• Up to EUR 7 million or 1.4% of global annual revenue

These amounts are upper limits. The actual amount depends on the severity of the violation, whether the incident was intentional or negligent, and what measures the company took to limit the damage. A company that has a documented incident response process but misses a deadline by a few hours will be treated differently than one that cannot demonstrate any reporting structure at all.

In addition to fines, further consequences may apply:

• Personal liability of management in cases of gross negligence
• Public disclosure of the violation by the supervisory authority
• Orders to implement specific measures within a set deadline
• For essential entities: temporary suspension of certifications or authorisations

Example Timeline: Ransomware Attack at a Mid-Market IT Service Provider

Let us walk through the reporting deadlines using a concrete scenario. TechServ GmbH has 95 employees, operates managed IT services for around 40 clients, and falls under NIS2 as an important entity.

Day 0, Friday 6:47 PM

The SIEM system alerts: unusual encryption activity on the backup server. The on-call admin reviews the alert and escalates to IT management.

Day 0, Friday 9:30 PM

IT management confirms after initial analysis: Ransomware has encrypted the backup server and two file servers. Customer data is potentially affected. The reporting deadlines now begin.

Day 1, Saturday 9:30 PM (24h deadline)

TechServ GmbH submits the initial report to the BSI:

• Ransomware infection confirmed
• Presumably malicious act (external attack)
• Cross-border impact possible (customers in Austria)
• Initial containment measures initiated (affected systems isolated)

Day 3, Monday 9:30 PM (72h deadline)

The external incident response service provider has completed an initial forensic analysis. The interim report contains:

• Attack vector: compromised VPN account of an employee (stolen credentials from a previous data breach)
• Affected systems: 3 servers, approx. 2 TB of data encrypted
• Severity: high (customer data affected, services impaired)
• IoCs: specific IP addresses, ransomware variant identified
• Countermeasures: VPN reset, accelerated MFA rollout, clean backups identified

Day 30, three weeks after completion of recovery

The final report documents:

• Complete attack chain from initial access to encryption
• Root cause: missing MFA on VPN access, password reuse by an employee
• Recovery timeline (7 days to normal operations)
• Measures implemented: MFA for all remote access, password policy tightened, network segmentation revised, offline backups introduced
• Employee training measures

In parallel, TechServ GmbH submitted a separate GDPR report to the competent state data protection authority within 72 hours due to the affected customer data (which included personal data), and informed the affected customers.

Practical Tips: How to Organisationally Ensure You Meet the Deadlines

The theory is one thing. But how do you practically implement the reporting obligations in a company with 100 employees without maintaining a dedicated compliance team?

1. Link Incident Response Plan with Reporting Deadlines

Your incident response plan should include the reporting deadlines as fixed milestones. Not as a separate checklist, but directly integrated into the process. If your plan contains the step "classify incident," this must be immediately followed by "check reporting obligation and start 24h clock."

2. Prepare Templates

In an emergency, there is no time to draft a report from scratch. Prepare a template for each of the three reporting stages that only needs to be filled in with case-specific details. The BSI is expected to provide standardised reporting forms. Until then, orient yourself to the minimum requirements of the NIS2 Directive.

A good initial report template includes:

• Company details (pre-filled)
• Contact person for queries
• Time of awareness
• Brief description of the incident (free text, 3–5 sentences)
• Checkboxes: malicious act yes/no, cross-border yes/no
• Immediate measures taken

3. Define Clear Roles and Reachability

Who reports? Who decides whether a report is necessary? Who provides the technical information? These questions must not be left until an emergency. Define at least three roles:

• Incident Manager: Coordinates incident handling and manages the reporting process
• Technical Analyst: Provides the forensic findings for the reports
• Reporting Officer: Drafts the reports and communicates with the BSI

In a 100-person company, these roles often overlap across two or three people. That is fine, as long as responsibilities are clearly documented and deputies are designated. Because incidents do not respect office hours.

4. Ensure Reachability Outside Business Hours

The 24-hour deadline does not recognise weekends. If your monitoring detects an incident on Saturday evening, someone must be able to act. This does not mean you need to set up 24/7 on-call duty. But you need an escalation chain with registered mobile numbers and a clear rule about who decides in case of doubt.

5. Conduct Exercises

Once a year, you should run a reporting exercise. Not as a theoretical tabletop session, but as realistically as possible: roll a scenario, fill in the initial report under time pressure, create the interim report with fictional forensic data. This way you identify gaps in your process before an actual emergency exposes them.

6. Involve External Partners in Advance

If you use (or want to use) an external incident response service provider, clarify the contractual terms in advance. Agree on response times that align with your reporting deadlines. If your service provider needs 48 hours to start forensic analysis, you will not be able to populate the 72-hour report with reliable data.

7. Document from the Very First Moment

Maintain an incident log from the first moment of suspicion. Every finding, every measure, every decision is documented with a timestamp. In ISMS Lite, the three countdown timers for 24h, 72h, and 30 days run automatically as soon as you mark an incident as potentially significant. This log is the foundation for all three reports and the evidence that you met the deadlines. In an emergency, you forget details faster than you think.

What This Means for Your ISMS

The NIS2 reporting deadlines should not be viewed in isolation. They are one building block in a larger system. If your company already operates an ISMS based on ISO 27001, the incident management process (A.5.24–A.5.28) gives you a solid foundation. However, you need to supplement this process with the specific NIS2 requirements: the three-stage reporting obligation, the concrete deadlines, and communication with the BSI.

If you do not yet have a formalised ISMS, the reporting deadlines are a strong argument for building one. Because without structured incident management, you will have to improvise in an emergency. And improvisation and 24-hour deadlines do not mix well.

The good news: You do not need an enterprise ISMS with hundreds of pages of documentation. A lean system tailored to your company size that covers the essential processes is sufficient. What matters is that the incident response process is lived and the reporting deadlines are firmly embedded in it.

Conclusion: Preparation Beats Speed

The NIS2 reporting deadlines are demanding, but they are achievable. The 24-hour initial report does not require a perfect analysis — just a rapid early warning. The 72-hour interim report assumes you are forensically capable. And the final report after one month gives you enough time for a thorough review.

The real key is not being particularly fast in an emergency. It is having created the right structures beforehand. A prepared incident response process, reporting templates in the drawer, clear roles, and practised procedures make the difference between controlled crisis management and hectic chaos.

Further Reading

• NIS2 Initial Report to the BSI: Content, Deadlines, and Template
• Detecting, Assessing, and Reporting Security Incidents — The Complete Process
• Creating an Incident Response Plan: Template and Practical Example
• NIS2 Fines: Who Is Liable and How High Are the Penalties?
• NIS2 for SMEs: What You Need to Know and What to Do Now

Start today. Not with the perfect process, but with a functioning one. The first reporting exercise will show you where you stand. Everything else is iteration.