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. For the digital providers listed in its Article 1, Commission Implementing Regulation (EU) 2024/2690 sets the criteria for a significant incident (Articles 3 to 14). §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, Art. 3(1)
An incident shall be considered to be significant for the purposes of Article 23(3) of Directive (EU) 2022/2555 with regard to the relevant entities where one or more of the following criteria are fulfilled: (a) the incident has caused or is capable of causing direct financial loss for the relevant entity that exceeds EUR 500 000 or 5 % of the relevant entity's total annual turnover in the preceding financial year, whichever is lower; [...] (e) a successful, suspectedly malicious and unauthorised access to network and information systems occurred, which is capable of causing severe operational disruption;
Applies only to the digital providers listed in CIR Article 1 (DNS, TLD registries, cloud, data centres, CDNs, MSPs, MSSPs, online marketplaces, search engines, social networks, trust services). Articles 5 to 14 add thresholds per service type, for example a cloud service completely unavailable for more than 30 minutes (Article 7). If a criterion is met, the threshold question is closed and reporting starts. For every other entity the test in Article 23(3) NIS 2 applies.
§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(6) 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. For the CIR's digital providers, Article 3 CIR sets criteria that make an incident significant once they are met. 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 (eighteen 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.
- Directive (EU) 2022/2555 (NIS 2), Article 23(3), 23(4), 23(6): eur-lex.europa.eu/eli/dir/2022/2555/oj
- Commission Implementing Regulation (EU) 2024/2690, Articles 3 and 5 to 14: 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
In de praktijk
Waar dit in de begeleide doorloop terugkomt
De begeleide doorloop maakt hier stappen van die u invult, met de wet bij elke stap uitgelegd. Open een stap om het scherm te zien, ingevuld voor een verzonnen bedrijf.
De doorloop zelf is in het Duits en het Engels.
Incident Handling
Know how to report an incident
Three reports to your authority, with fixed deadlines.
Moet u zich met NIS2 bezighouden?
We begeleiden u stap voor stap. U vult in, wij leggen elk punt in eenvoudige woorden uit, en aan het eind tekent de directie.
