An Edge Built on Knowledge and Experience
NIS2 / BSIG § 30 (2) No. 2

Incident Response Framework Under NIS2

A security incident is not a question of if, but of when. NIS2 requires systematic preparation — we explain the structure, roles, and operational response.

Technical & Legal Expertise Experience From Numerous NIS2 Projects Based in Sindelfingen
Fundamentals

Which Incidents Does the NIS2 Obligation Cover?

§ 30 (2) No. 2 BSIG obligates affected entities to take measures to manage security incidents. The trigger is not every security event, but only a significant security incident.

Framework Structure

The Three Pillars of an NIS2-Compliant Incident Response Framework

1. Internal Reporting Channels

Employees must know who to contact — before an incident occurs. Low-threshold reporting processes determine whether the BSI reporting deadlines can be met at all.

  • Define a designated point of contact
  • Document and communicate the reporting process
  • Regular workforce awareness
  • Ensure 24-hour availability

2. Incident Team

An interdisciplinary team with clearly defined responsibilities — actively involved, not merely informed.

  • Who classifies the incident as significant?
  • Who informs management?
  • Who reports to the BSI?
  • Who brings in legal counsel?
  • Who coordinates recovery?

3. Response Plans

Concrete instructions for the most likely scenarios — regularly rehearsed, not merely documented.

  • Ransomware attack
  • Data exfiltration / data breach
  • Critical system outage
  • Supply chain attack
Operational Response

The Three Phases in a Real Incident

The actual work begins after the BSI notification. These three phases are not prescribed by law in detail, but without them sustainable damage limitation is not possible.

Phase 1
Containment
Stop the spread without destroying evidence. Isolate systems, block access, protect backups.
Phase 2
Evidence Preservation
RAM image, logs, network captures, forensic copies — before external specialists arrive.
Phase 3
Recovery
Restore systems from clean backups, close attack vectors, resume operations step by step.
Follow-up
Lessons Learned
Final report to the BSI, internal analysis, derive and document process improvements.

From practice: In exercises, things regularly stall after just a few minutes: who classifies the incident as significant? IT management and the data protection officer disagree, and executive management has no clear view. Exercises under realistic conditions reveal more in two hours than a year of maintaining documentation.

Frequently Asked Questions

Incident Response and NIS2

Do I have to document the framework in writing?
Yes. Response plans, responsibilities and reporting channels must exist in writing, be version-controlled, and be known to all those involved. In a real incident and during regulatory reviews, this is exactly the documentation that will be requested.
How often must the framework be tested?
The BSIG does not prescribe a minimum frequency, but the BSI recommends regular tabletop exercises. At least annually, ideally after every significant change to the IT infrastructure or after an actual incident.
What is the difference between incident response and the reporting obligation?
The reporting obligation and incident response are separate paths that run in parallel. The notification to the BSI must be made within 24 hours of becoming aware — in parallel with, not after completion of, the internal response. Reporting only once everything is resolved breaches the reporting obligation.
Related Topics

Further NIS2 Topics

Build and Test Your Incident Response Framework

We develop your response plans, train your incident team, and support your first exercise — so the framework works in practice, not just on paper.

Request Consultation Now
Tilsiter Str. 6 · D-71065 Sindelfingen, Germany · +49 (0) 7031.4181-860 · contact@consuvation.com