Live · DACH ops
03:47 · QR-2 · Sektor B · 0 anomalies04:03 · QR-7 · Gate 4 · handover ack04:11 · QR-2 · Sektor B · patrol complete · 4.2 km04:14 · Filderstadt · ops ack · all green04:22 · QR-12 · Stuttgart-W · charge cycle 84%04:30 · QR-3 · Karlsruhe · perimeter sweep · pass 3/404:38 · QR-9 · Wien-N · weather check · IP65 nominal04:45 · QR-2 · Sektor B · thermal hit reviewed · benign04:52 · QR-15 · Zürich-O · escalation queue · empty05:00 · all units · shift turnover · zero incidents03:47 · QR-2 · Sektor B · 0 anomalies04:03 · QR-7 · Gate 4 · handover ack04:11 · QR-2 · Sektor B · patrol complete · 4.2 km04:14 · Filderstadt · ops ack · all green04:22 · QR-12 · Stuttgart-W · charge cycle 84%04:30 · QR-3 · Karlsruhe · perimeter sweep · pass 3/404:38 · QR-9 · Wien-N · weather check · IP65 nominal04:45 · QR-2 · Sektor B · thermal hit reviewed · benign04:52 · QR-15 · Zürich-O · escalation queue · empty05:00 · all units · shift turnover · zero incidents
← All articles
KRITIS · Umbrella Act · NIS-2

NIS-2 reporting: meeting the 24-hour deadline

NIS-2 reporting in detail: 24-hour early warning, 72-hour notification, final report. Reporting chain, sanctions and 90-day plan for the CISO.

Dr. Raphael Nagel (LL.M.) & Marcus Köhnlein
Investor & Author · Founding Partner
Follow on LinkedIn

The NIS-2 reporting obligation has three deadlines in practice, not one. Anyone who confuses 24 hours, 72 hours and one month risks fines and personal liability. This article separates the stages and shows the reporting chain from the sensor to the BSI portal.

NIS-2 reporting: the three deadlines at a glance

Directive (EU) 2022/2555 mandates a three-stage reporting procedure: early warning within 24 hours, incident notification within 72 hours, final report within one month (EUR-Lex, Directive 2022/2555).

Stage 1, early warning. Within 24 hours of becoming aware of a significant security incident, an initial report must be sent to the BSI. Content: suspicion of unlawful action, cross-border impact, affected service.

Stage 2, incident notification. Within 72 hours, the assessment follows, with severity, impacts, initial indicators (IOCs) and containment status.

Stage 3, final report. No later than one month after the incident notification, the entity documents root cause analysis, measures and cross-border effects.

The BSI can request an interim report at any time. This requirement is independent of the standard deadlines.

Critical point: the deadline starts at the time of awareness by the entity, not at the actual occurrence of the incident. An incident detected on Sunday at 23:50 triggers the early warning by Monday at 23:50. This applies regardless of the on-call model.

Next step: the NIS-2 compliance overview bundles all entity obligations into one matrix.

What counts as a significant security incident

Not every alarm is reportable. An incident is significant if it causes severe disruption to the service, triggers financial losses for the entity, or affects other natural or legal persons through material or immaterial damage.

Four example classes from operational practice:

  1. Ransomware with encryption of production systems: always reportable.
  2. DDoS with service outage above the thresholds of the KritisV: reportable (BSI-KritisV).
  3. Physical incidents at the perimeter: reportable as soon as they affect digital services. A break-in to a server room counts, even if no data was exfiltrated.
  4. Drone overflights with suspected sensor activity above KRITIS sites: subject to documentation and review. The early warning is triggered as soon as an impact on the service cannot be ruled out.

Suspicious cases without confirmed impact do not trigger an early warning to the BSI. They are subject to the internal logging obligation and must be auditable. Reporting too early creates noise. Reporting too late violates Section 38 BSIG-neu (BSIG-E, BMI ministerial draft).

Next step: the classification criteria are broken down by sector in the KRITIS Umbrella Act checklist 2026.

Reporting chain: from the sensor to the BSI portal

The reporting chain is a process with a stopwatch. Six steps:

  1. Detection. Sensors at the perimeter, in the SIEM or in the EDR register an event with a timestamp in UTC format. UTC is mandatory because communication with authorities is time-zone neutral.
  2. Escalation. The alarm is handed over to the SOC or the security control room within 30 minutes. This deadline is not statutory, but operationally necessary. It is the only way to hold the 24-hour deadline.
  3. Assessment. The incident response team checks within 4 hours against the NIS-2 threshold: severe service disruption, financial damage, third-party impact.
  4. Release. The CISO or a named deputy releases the early warning with signature. A deputy arrangement for weekends and vacation is mandatory.
  5. Submission. The report goes out via the BSI reporting portal. The BSI is the central reporting authority for NIS-2 incidents in Germany (BMI on NIS-2 implementation). Document the case number, set a follow-up for the 72-hour stage.
  6. Information of management. In parallel, not after. The personal liability under Section 38 BSIG-neu applies as soon as management knows about the incident and fails to act (BSIG-E, BMI ministerial draft).

Separating assessment and release is not a formality. It prevents a single analyst under time pressure from triggering or omitting a report.

Physical incidents and the NIS-2 reporting obligation

NIS-2 is not a pure cyber directive. Physical incidents with service impact are reportable.

Four categories from control room practice:

  • Unauthorized access to data centers, network distribution points or control stations. The reporting obligation arises as soon as an impact on the service cannot be ruled out.
  • Sabotage of cooling, backup power or fiber routes. The 24-hour deadline starts with detection by the control room.
  • Theft of hardware with potentially exploitable data or access tools (keys, tokens).
  • Drone overflights with suspected sensor activity. Without evidence preservation, only suspicion logging remains.

QR-2 patrol robots document timestamps, geo-coordinates and image material in an audit-proof way. The QR-3 with LiDAR and drone detection additionally delivers forensic data for the final report: 3D point clouds of the scene, RF spectra on drone detection, gapless patrol logs.

What works: the audit log of the robot patrol replaces manual guard book records. It closes evidence gaps that are routinely flagged in NIS-2 audits (incomplete patrol logs, missing timestamp synchronization).

What does not work: robotics without connection to SOC and ticketing. A robot that records incidents but does not escalate helps with the final report, not with the 24-hour deadline.

The Robotics-as-a-Service model integrates sensors, escalation and audit log in one contract. A calculation against classic manned guarding is in the guard service cost comparison.

Sanctions for late or omitted reporting

Fines differ between two classes:

Personal liability of management under Section 38 BSIG-neu. Board members and managing directors are personally liable with their private assets for breaches of duty. This concerns risk management as well as reporting practice. A D&O insurance only covers gross negligence to a limited extent.

For repeated or severe violations, the BSI can issue a temporary ban on management functions. This sanction is directed against the responsible managing director personally. This sanction is new in German supervisory law and follows the GDPR supervision model.

Reputational damage: the BSI can order public disclosure of the incident. This affects shareholders, customers and insurers alike.

Details on the liability situation are in Board liability under NIS-2.

Tools and templates for the reporting chain

A reporting chain without prepared tools fails on the first weekend patrol. Five building blocks:

Reporting form with mandatory fields. Timestamp of detection (UTC), sector under KritisV, affected service, indicators (hashes, IPs, MAC addresses, physical traces), initial assessment. The form is available offline, because the failure of the IT infrastructure can block online access.

Escalation matrix. Named deputies for 24/7 availability. At least three persons per role (CISO, data protection officer, management), tested through unannounced calls.

Tabletop exercise. At least twice a year, with documented results. Scenario: simulated incident on Friday evening with stopwatch validation of the 24-hour deadline.

Interface between physical control room and cyber SOC. Shared ticketing logic. An incident gets one case number, whether it was detected at a turnstile or in the SIEM.

Communication releases. Pre-agreed language with the supervisory board and press office. Whoever looks for the press release approval only during the incident loses four hours.

Interaction with the KRITIS Umbrella Act (KRITIS-Dachgesetz) and sector-specific obligations

The KRITIS-Dachgesetz complements NIS-2 with the obligation to report physical security incidents to the BBK (Bundestag-Drucksache 20/9262). The BBK coordinates these reports and maintains the register of critical installations (BBK Bundesamt für Bevölkerungsschutz).

Consequence for hybrid incidents: double reporting. A break-in to the data center with subsequent data theft triggers two reports. The cyber component goes to the BSI under NIS-2, the physical component to the BBK under the KRITIS-Dachgesetz. Both reports follow different deadlines and forms.

Sector-specific regulations may prescribe shorter deadlines. Energy, water and health each have their own sector regulations with differing thresholds and reporting channels. Before standardizing internal processes, the sector situation must be checked.

Group structure: the reporting obligation applies to the regulated entity, not the parent company. A holding does not report for its subsidiaries. Anyone operating a shared service structure clarifies contractually who triggers the early warning.

Cross-border incidents: if an incident affects other EU Member States, the BSI informs the competent national authorities. The entity does not have to coordinate this itself, but documents it in the final report.

The BBK side of the process is described step by step in BBK registration step by step.

Operational rollout in the first 90 days

A build plan for security managers without an existing NIS-2 reporting chain:

Week 1 to 2: inventory. Which reporting channels exist? Who has release authority today? Gap analysis against the three deadlines. Result: gap list with owners.

Week 3 to 6: escalation matrix and training. Build the named deputy arrangement. Train the control room, SOC and on-call duty on the thresholds and forms. Three dry runs without a stopwatch.

Week 7 to 10: integration of physical sensors. Robotics, access control, video analytics and drone detection are connected to ticketing. Shared case numbers for cyber and physical incidents.

Week 11 to 12: tabletop exercise with stopwatch. Simulated incident on Friday at 17:30. Validation of the 24-hour deadline under realistic conditions, including absence of the primary responsible.

From day 90: standard operation. Quarterly review of the reporting chain by internal audit. Annual review by an external auditor experienced in NIS-2 and KRITIS-Dachgesetz. Results feed into the report to the board and supervisory board.

Anyone who runs through the 90 days with discipline has an auditable reporting chain. Anyone who cuts corners risks that the first real crisis exposes the weaknesses.

The templates for reporting form, escalation matrix and tabletop scenario are available for download in the NIS-2 compliance overview.

Translations

Call now+49 711 656 267 63Free quote · 24 hCalculate price →