NIS2 Incident Response: The 72-Hour Reporting Obligation

Around 29,500 companies and public authorities in Germany fall under the new NIS2 directive. That is more than six times as many as before. With this expansion comes a central obligation you cannot afford to ignore: the duty to report cyber incidents. Anyone who fails to report a security incident within 24 hours risks fines of up to ten million euros or two percent of their global annual turnover.

This is no longer a theoretical threat. Germany's NIS2 law (NIS2UmsuCG) came into force on 6 December 2025. The BSI registration portal has been active since 6 January 2026. Your company must register if it falls under the regulations, and it must have a working incident response plan.

This article shows you what NIS2 specifically requires, how to build an incident reporting process, and why your suppliers affect you too.

What NIS2 specifically requires for incident management

The NIS2 directive breaks the reporting obligation down into three phases with strict time limits.

Phase 1: Early Warning (24 hours)

Once you become aware of an incident, you must inform the competent national authority (in Germany, the BSI or a CSIRT) within 24 hours. This is only a first warning, not a full analysis. You do not yet need all the details, but you do have to report that an incident has taken place.

For your company, this means you need a process to detect incidents and classify them immediately (or at the latest within a few hours). Not every security event is a "significant incident". A significant incident exists if it has caused or can cause severe operational disruption, or if it could affect other individuals or organisations with substantial damage.

Phase 2: Incident Notification (72 hours)

Within 72 hours, you submit a detailed notification. It includes an initial assessment of the severity, the suspected origin of the incident, and indicators of compromise (IoCs).

This means your team must have carried out a basic forensic analysis within 72 hours. That is a tight deadline. Many smaller companies underestimate how much time such an analysis takes.

Phase 3: Final Report (30 days)

No later than one month after the initial notification, a final report follows with a complete description of the incident, its root cause, and the measures you have taken.

These three phases are not optional. They are anchored in Article 23 of the NIS2 directive and apply to all "essential" and "important" entities. Which category you belong to depends on your sector and your size. The BSI has published guidance. If you are unsure, check now.

Who reports, and to whom?

This is where things get confusing the first time you read about it. You do not report to the police or the public prosecutor, but to a cybersecurity authority.

In Germany, the contact point is the Federal Office for Information Security (BSI). For specific sectors, it may also be a CSIRT (Computer Security Incident Response Team). The exact point of contact depends on your sector (energy, transport, health, finance, etc.).

The BSI activated a registration portal on 6 January 2026, which also handles incident notifications. The portal acts as both the registration and the reporting platform.

You have three months to register if you fall under NIS2. Missing this deadline already exposes you to formal warnings.

Why your suppliers are affected too

Here a common misinterpretation creeps in: not all of your suppliers become NIS2-regulated. But all of your suppliers have to meet certain security standards, because you are required to demand them.

The NIS2 directive obliges you to monitor and assess your "direct suppliers and service providers". These are software vendors, cloud providers, managed service providers, IT service providers and similar. You have to assess their security and write cybersecurity requirements into your contracts.

In practical terms: if a supplier is hacked and your systems are affected, you are in the boat with them. You had a duty of care to vet that supplier.

The NIST Framework calls this "Supply Chain Risk Management". It is not just about your direct IT security, but also about your dependencies.

For SMEs this means, concretely: make a list of your critical suppliers. Check their security certificates (ISO 27001, SOC 2, etc.). Write security requirements into contracts. Update these contracts regularly. It is tedious, but NIS2-compliant.

Building an incident response plan: practical steps for SMEs

A working IR plan consists of five elements.

1. Preparation (Prepare)

This is the most important part. Here you define who does what when things get serious.

Appoint an incident response manager (this can be a person or a team). This person must be notified immediately for every incident. They coordinate the response and the reporting.

Create a list of all critical systems and their dependencies. Which systems, if they go down, would cause operational disruption?

Set up monitoring and alerting. You need logs from your most important systems, and you need automatic alerts when suspicious activities happen. This has to work 24/7, also at night. Many small companies have a gap here.

Write an incident response playbook. It is a kind of recipe: if sign X is detected, then follow steps A, B, C. Who gets called? What is documented? How is something isolated? The playbook has to be tailored to your company, not generic.

Create contact lists: IT team, management, data protection officer, possibly lawyers, possibly customers. All of them must be immediately reachable.

2. Detection (Detect)

Logs alone are not enough. You need someone or something that reads the logs and spots anomalies.

That can be a SIEM system (Security Information and Event Management), i.e. software that collects logs and recognises patterns. For SMEs this is often expensive. Alternatively, you need someone who regularly checks logs, or you buy a managed service (SOC, Security Operations Center).

This step is also about taking internal and external reports seriously. If an employee says their password is not working, it could be that an attacker is just changing it. That is a sign.

3. Analysis and Containment (Analyze and Contain)

When an incident is detected, you need to know quickly: how severe is it? Is it significant?

This is not an academic thought experiment. The answer determines whether you inform the BSI within 24 hours or not.

In the analysis you ask: which systems are affected? Which data could be exposed? How did the attacker get in? You get the answers from logs, network traffic analyses and, if necessary, forensics.

Containment is what most people think of as "what to do". Isolate infected systems from the network. Change critical passwords. Lock suspicious accounts. Document everything.

4. Eradication and Recovery

Once the spread is stopped, you have to remove the attacker completely (eradication). This often means deleting malware, closing backdoors, applying patches.

Then you bring systems back online (recovery). This is not simple. You have to be sure that the attacker is really gone, otherwise you end up in an endless loop: infected, cleaned, infected again.

5. Post-Incident Review and Lessons Learned

After the incident there is a formal post-mortem. This is not optional, NIS2 requires it.

You write a post-mortem report: what went wrong? Where should monitoring have caught the issue? Why was the password so easy to crack? Then you define concrete improvements and implement them.

You also need this report for the final notification to the authority (Phase 3, 30-day deadline).

Concrete tools for SMEs

For monitoring: the ELK stack (free, but complex), Splunk (expensive, but beginner-friendly), or a managed service such as Managed Detection & Response (MDR).

For incident tracking: a ticketing system like Jira or an incident management tool like Opsgenie.

For documentation: a simple Confluence wiki or Google Docs where the playbooks live.

You submit the BSI notification itself via the BSI reporting portal, which has been online since January 2026.

Overlaps with ISO 27001 and other frameworks

If your company is already ISO 27001 certified: that is a good start, but not full NIS2 compliance.

ISO 27001 requires incident management. You need an "Information Security Incident Response" procedure. But ISO does not require external reporting deadlines like "24 hours".

NIS2 and ISO 27001 overlap in documentation, training, supplier management and incident tracking. You can use ISO controls as a basis for NIS2, but you have to address NIS2-specific requirements (especially the reporting deadlines) separately.

The NIST Cybersecurity Framework 2.0, updated in April 2025, has six functions: Govern, Identify, Protect, Detect, Respond, Recover. Conceptually that is similar to the NIS2 requirements, except that NIST is older and more established. Many companies use NIST as their framework and then overlay NIS2 requirements on top.

The point: ISO 27001 certification does not make you NIS2-compliant. But it is a good foundation to build on.

What happens if you do not comply

The penalties here are not symbolic.

For "essential" entities (mostly infrastructure operators, banks, large telecommunications companies), the maximum fine is ten million euros or two percent of global annual turnover, whichever is higher.

For "important" entities (smaller critical infrastructure, service providers) it is seven million euros or 1.4 percent of turnover.

A mid-sized IT services company with 50 million euros in annual turnover therefore risks up to 700,000 euros in fines, simply for failing to report an incident within 72 hours.

On top of that there are administrative measures: the BSI can issue warnings, give binding instructions, appoint monitoring officers, or publicly state that you are not NIS2-compliant. This is not just expensive but also reputationally damaging.

In Germany, the BSI has been officially mandated to enforce these rules. The agency has signalled that it will not launch aggressive enforcement measures for now, but expects demonstrable progress on implementation.

In other words: now is the moment to be proactive. In six months it will be too late.

There is also personal liability: executives can be held personally liable if gross negligence is proven. That means the CEO cannot hide behind "I didn't know".

Checklist: is your company ready?

Answer these questions honestly:

1. Do I know whether my company falls under NIS2? (You may want to check with the BSI via the registration platform.)

2. Have I appointed an incident response manager?

3. Have I written a playbook that describes what happens in an emergency?

4. Do I have monitoring and alerting for critical systems?

5. Can I detect incidents within hours?

6. Do I know whether an incident is "significant" before I report it to the BSI?

7. Am I organisationally capable of writing a first notification within 24 hours?

8. Do I have a list of my critical suppliers and have I assessed their security?

9. Are NIS2 requirements included in my supplier contracts?

10. Do I have a post-mortem process to learn from incidents?

If you answer "no" to more than two questions, you need a plan. Fast.

Next steps

The first step is registration. If your company falls under NIS2, you must register with the BSI by 6 March 2026 (three months after the NIS2UmsuCG came into force on 6 December 2025). This is done via the BSI registration platform.

After that: have an IT security professional run an assessment. Not to reassure you, but to identify the gaps.

Then: prioritisation. Not everything can be done on day one. But incident response capability should be in your top three priorities.

And: training. Your team has to understand that an incident is not reported "sometime later", but within 24 hours. That changes how you operate.

NIS2 is not going away, even if not everyone knows about it yet. It is only going to grow. The first fine case will serve as a precedent, and then the pressure will increase. Acting now is cheaper than reacting later.