Make the NIS2 reporting clock visible before an incident

NIS2 incident reporting should be prepared as a timed decision process, not discovered during the incident. Record when the organisation became aware of a potentially significant incident, who assesses significance, what evidence is available and who is authorised to send each notification.

Article 23 of Directive (EU) 2022/2555 generally requires an early warning within 24 hours of becoming aware of a significant incident and an incident notification within 72 hours, both without undue delay. Intermediate reports may be requested. The final report is generally due within one month after the incident notification. If the incident is still ongoing then, Article 23(4)(e) provides for a progress report followed by a final report within one month of handling the incident.

The 72-hour limit is not universal. For significant incidents affecting the provision of trust services, Article 23(4) requires trust-service providers to notify within 24 hours of awareness, without undue delay. NIS2 Directive Article 23

For Germany, confirm the applicable national and sector rules. Section 32 BSIG sets the general German reporting sequence; section 28 defines scope and exemptions. Where section 32(2) applies, an ongoing incident requires a progress report at the final-report stage and a final report after the incident has been fully handled. Record the applicable legal basis, recipient and deadline in the entity's reporting procedure.

For Germany, the BSI says important and particularly important entities must establish incident-response measures and report significant security incidents to BSI under the current BSIG. Entity classification, significance and other sector rules need competent case-specific assessment. BSI #nis2know Incident Response

Start the clock from recorded awareness, not from a convenient later meeting. Distinguish the early warning from the incident notification, and record the deadline applicable to the entity and incident. Preserve uncertainty instead of waiting for perfect facts. Route other legal, contractual and customer notifications through a coordinated matrix.

Document how a technical alert becomes organisational awareness. Include monitoring providers, help desks, site teams and suppliers that may be the first to see disruption. If reports can arrive outside business hours, assign an acknowledgement route and deputy.

The directive's significance test includes severe operational disruption or financial loss, and considerable material or non-material damage to other persons. Build prompts around those effects. Do not reduce the decision to a cyber-severity label that has no relationship to the legal test.

Record the first reliable awareness timestamp, source, affected service and decision owner. If awareness is disputed, preserve the evidence and escalate immediately. Resetting the clock after a handoff is not a control.

Prepare a minimum early-warning record for the facts reasonably available in the first 24 hours, including whether unlawful or malicious acts are suspected and whether cross-border impact may exist. Mark unknown items as unknown and assign an owner to investigate them.

For the incident notification, add the initial assessment of severity and impact and available indicators of compromise. Check for a shorter applicable deadline before adopting the general 72-hour limit. Keep a change log so the later report explains what was learned, corrected or ruled out.

Prepare an intermediate-update route and a final-report evidence folder. Article 23 identifies detailed incident description, severity and impact, likely threat or root cause, mitigation and any cross-border impact among the final-report elements. Do not wait until the final report to organise that evidence.

An incident may also involve personal data, financial services, telecommunications, contractual service levels, insurers or law enforcement. Build a notification matrix with trigger, recipient, deadline, owner and approved communication channel for each applicable duty.

The matrix should show which assessment is shared and which legal test is different. A NIS2 early warning does not automatically satisfy another regime, and a customer update is not necessarily the regulatory notification.

Protect sensitive incident information. Define secure collaboration, access, retention and out-of-band communication before the event. Keep the reporting pack usable if normal identity or messaging systems are unavailable.

Assume a fictional managed-service team detects unusual privileged activity at 03:20 and sees customer-service disruption at 04:05. The on-call lead records both times and escalates the potential significant-incident assessment. The legal and incident leads do not wait for full root-cause confirmation before preparing the early warning.

The early warning states what is known, what remains uncertain and the possible cross-border effect. Assuming the general 72-hour incident-notification deadline applies to this fictional entity, that package updates impact and indicators; a shorter applicable deadline must be followed instead. A decision log records who approved each submission and the reporting channel used.

This example is hypothetical. It does not decide that the incident is legally significant or prescribe a report for any real entity.

Fictional desk example; no incident or regulatory submission occurred. For arithmetic only, assume competent assessment establishes awareness of a significant incident at 04:05 UTC on 12 October 2026, and that the general German section 32 sequence applies. This assumption does not decide when awareness arises in a real incident.

The first alert and assumed awareness differ by 45 minutes. Retaining both prevents a shift handover from silently replacing the earlier evidence. The record should also contain the recipient, authorised submitter and submission receipt when an actual report is sent.

The final-report calendar must be built from the applicable legal rule and the actual notification, including the ongoing-incident route. This example deliberately leaves that field unresolved rather than inventing a submission. Local time conversions, significance and awareness require separate confirmation.

Run a tabletop using a clearly labelled exercise scenario. Test awareness logging, significance escalation, deputy authority, secure access to the reporting route and evidence handoff. Do not submit a test notification through a live regulatory channel unless BSI explicitly authorises the method.

Use the separate guide to test whether the incident contact tree reaches a decision maker. Record delays and ambiguities as actions, then retest the affected step.

No. The staged sequence recognises that facts develop. Report available information and uncertainty through the applicable route without delaying the initial stage for a perfect diagnosis.

No. Article 23 concerns significant incidents, and national applicability matters. Use competent assessment of the entity, incident and current German requirements.

Contracts may allocate operational support, but the organisation should verify its own legal responsibility, authority and evidence. A third-party handoff must not leave the clock owner unable to confirm what was sent and when.

This article is general information. Verify current requirements and seek qualified advice for your specific circumstances.

Spotted an issue? Contact our editorial desk.