How to report an NIS 2 incident in 24 hours
Article 23 NIS 2 sets one cascade across the Union: early warning at 24 hours, incident notification at 72 hours, intermediate report on request, final report within one month. The clock starts when you become aware of the incident, not when it happened.
The short version
If a significant incident hits, you owe your national CSIRT (in Germany: the BSI) four reports in a fixed order. The first one is due 24 hours after you become aware of the incident. The trigger word is awareness, not occurrence. The minute someone in your house can say it is more than a glitch, the clock has started.
Article 23(4) NIS 2 names all four stages. Commission Implementing Regulation (EU) 2024/2690 §11 spells out what the reports must contain and lists incident categories that always count as significant. §32 BSIG and the BSI Meldeportal are the German channel for it.
This page walks the EU layer first, then the German operational layer. The cascade is the same across the Union. The portal and the contact desk change country by country.
Article 23(4) NIS 2 Directive (2022/2555)
Member States shall ensure that the entities concerned submit to the CSIRT or, where applicable, the competent authority: (a) without undue delay and in any event within 24 hours of becoming aware of the significant incident, an early warning; (b) without undue delay and in any event within 72 hours of becoming aware of the significant incident, an incident notification; (c) upon the request of a CSIRT or, where applicable, the competent authority, an intermediate report on relevant status updates; (d) a final report not later than one month after the submission of the incident notification under point (b).
Four stages, one cascade. The wording is binding across every member state. The clock anchor is the same on every step: from becoming aware, not from the moment the incident started.
CIR (EU) 2024/2690, Annex §11.6
An incident shall be considered significant where it causes or is capable of causing severe operational disruption of the services or financial losses for the entity concerned, or where it has affected or is capable of affecting other natural or legal persons by causing considerable material or non-material damage.
§11.6 lists categories that always qualify as significant: ransomware, exfiltration of personal or sensitive data, denial-of-service against essential services, loss of confidentiality or integrity of critical assets, and so on. If a category fits, the threshold question is closed. Reporting starts.
§32 BSIG (Germany)
Wesentliche und wichtige Einrichtungen melden erhebliche Sicherheitsvorfälle dem Bundesamt unverzüglich, spätestens innerhalb der in Artikel 23 Absatz 4 der Richtlinie (EU) 2022/2555 genannten Fristen.
Germany copies the directive cascade and points at the BSI Meldeportal as the operational channel. §32 BSIG is the German hook. Article 23(4) NIS 2 is the substantive rule the German text refers to.
Early warning
Within 24 hours of becoming aware of the incident, file an early warning with the BSI Meldeportal. You name the entity, signal whether you suspect a malicious act, and flag whether cross-border impact is possible. You do not need root cause, scope or attribution yet. The point is to put the CSIRT on alert and start coordination.
Incident notification
Within 72 hours of becoming aware, file the incident notification. Update what you said at 24 hours. Add an initial severity and impact assessment. Add indicators of compromise if you have them. This is the first time you are expected to characterise the incident, not just announce it. Best guess on partial data still beats silence.
Final report (and intermediate on request)
Between 72 hours and the final report, the CSIRT or competent authority can request an intermediate report on relevant status updates at any time. The final report itself is due no later than one month after the 72-hour notification. It carries the confirmed description of the incident, the root cause analysis, the mitigation measures applied, and any cross-border impact. If the incident is still ongoing at one month, file a progress report and a final one when it closes.
Speed over completeness, awareness over occurrence
The BSI puts it plainly: „Schnelligkeit vor Vollständigkeit“. Send the report with what you know now. Update later. The clock starts the moment someone with responsibility can say this is more than a normal disruption, not the moment the attack actually began. A late, complete report is non-compliance. A fast, partial report is compliance.
Reporting paths can run in parallel
If personal data is involved, Article 33 GDPR runs its own 72-hour clock to the data protection authority (in Germany: the BfDI or the relevant Landesdatenschutzbehörde). That clock is independent of the NIS 2 cascade. You can owe both at the same time. Filing one does not satisfy the other. The same applies to sector regulators where they exist.
BSI Meldeportal under §32 BSIG
You file through the BSI Meldeportal at meldeportal.bsi.bund.de. The portal walks you through the four stages and tracks deadlines. The BSI publishes guidance under the headline „Schnelligkeit vor Vollständigkeit“: do not wait for forensic certainty. Send what you have. The portal lets you update the same case across the cascade.
Article 33 GDPR — runs in parallel
If the incident involves personal data, you also owe a notification under Article 33 GDPR within 72 hours of becoming aware. That goes to the data protection authority, not the BSI. The 72-hour clock is the same number but a different clock and a different addressee. Filing through the BSI Meldeportal does not stop the GDPR clock. Track both.
ENISA coordination and sector regulators
Article 23(11) NIS 2 lets the competent authority and CSIRT share the report with peer authorities in other member states where cross-border impact is possible, and with ENISA. If you operate across borders, expect coordination, not duplicated filing. Where a sector regulator exists (financial under DORA, telecoms under TKG), file under that regime instead of or alongside NIS 2 as the relevant act prescribes.
We will report once we know what really happened.
By the time you know what really happened, the 24-hour window has closed and the 72-hour one is closing. Article 23(4)(a) does not require root cause at 24 hours. It requires the early warning. The root cause belongs in the final report, one month later. Waiting for certainty is the most common way to miss the first deadline.
Until we confirm it is significant, we do not file.
Confirming significance ahead of time is not the test. CIR §11.6 lists categories that are significant by definition. The early warning at 24 hours is built for exactly the situation where you are not yet sure. Skip the 24-hour step and you have already missed a deadline you cannot take back, even if it later turns out the incident was not significant.
We sent the notification, we are done.
The 72-hour notification is one of four stages, not the last. The intermediate report can be requested at any time. The final report is due one month after the 72-hour notification. Most fines in the early enforcement wave concentrate on the missing final report, not the early warning.
Tuesday 07:42, a Stadtwerk SOC analyst notices the billing application is unreachable and ransom notes are dropping on three file shares. At 08:10, the IT lead confirms encryption on a billing database. That is the awareness timestamp. The 24-hour clock starts at 08:10 Tuesday, the 72-hour clock starts at 08:10 Tuesday, the one-month final-report clock starts the moment the 72-hour notification is filed.
By 14:00 Tuesday the entity files an early warning through the BSI Meldeportal: ransomware suspected, malicious act yes, cross-border impact unclear (twelve hours before the deadline). By Friday 06:00 the entity files the 72-hour notification with initial severity and indicators of compromise from the EDR logs. On day 18, the BSI requests an intermediate report on restoration progress; the entity files. On day 29, the entity files the final report with confirmed root cause, mitigation applied, and the lessons-learned summary. Four reports, one clock anchor: 08:10 Tuesday.
The Incident module on the platform mirrors the four-stage cascade. When an incident is opened, the awareness timestamp anchors three countdown clocks: 24 hours, 72 hours, one month. Each clock has its own template prefilled with what Article 23(4) and CIR §11.6 ask for, so you fill in what you know now and the platform tells you what is still missing.
Filing happens through the BSI Meldeportal in Germany. The platform does not replace the portal. It prepares the content, tracks the deadlines, holds the audit trail, and reminds the responsible owner that the next step in the cascade is due. The reports themselves stay export-ready so you can paste them into the portal under time pressure.
- Directive (EU) 2022/2555 (NIS 2), Article 23(3), 23(4), 23(11) — eur-lex.europa.eu/eli/dir/2022/2555/oj
- Commission Implementing Regulation (EU) 2024/2690, Annex §11 — eur-lex.europa.eu/eli/reg_impl/2024/2690/oj
- BSI Act (BSIG), §32 in the version of the NIS2 Implementation and Cybersecurity Strengthening Act
- BSI Meldeportal — meldeportal.bsi.bund.de
- BSI Infopakete „NIS 2 Pflichten“ on incident reporting — bsi.bund.de/dok/nis-2-infopakete
- Regulation (EU) 2016/679 (GDPR), Article 33 — eur-lex.europa.eu/eli/reg/2016/679/oj