
NIS2 Incidentmelding: De 24-uurstermijn en hoe u eraan voldoet (2026)
NIS2-incidentmelding vereist een 24-uurs vroegtijdige waarschuwing, 72-uurs melding en eindrapport binnen een maand. Ontdek wat als significant incident geldt, wat elk rapport moet bevatten en hoe u de operationele meldcapaciteit opbouwt.
NIS2 Incidentmelding: Hoe u daadwerkelijk aan de 24-uurstermijn voldoet
Een incidentresponsplan bestaat in elk ISMS. Het beschrijft wie wat doet in een noodgeval, welke escalatiepaden van toepassing zijn en hoe het incident wordt gedocumenteerd. Allemaal correct, allemaal belangrijk — en niets ervan is wat NIS2 daadwerkelijk beoordeelt.
NIS2 beoordeelt niet of er een plan bestaat. NIS2 beoordeelt of een organisatie een gecoördineerde, op feiten gebaseerde vroegtijdige waarschuwing kan leveren aan autoriteiten binnen 24 uur — terwijl het incident nog gaande is. Dit is geen documentatieprobleem. Het is een probleem van het operationele systeem.
Ga naar:
- Het driefasen rapportageregime in detail
- Waarom 24 uur korter is dan u denkt
- Wat een incidentmanagementsysteem moet leveren
- De vijf vragen die in de eerste 24 uur moeten worden beantwoord
Wat er is veranderd met NIS2
Onder de oorspronkelijke NIS-richtlijn bestonden meldingsverplichtingen — maar ze waren minder specifiek, troffen minder organisaties en werden in de praktijk zelden gehandhaafd. NIS2 heeft dit fundamenteel veranderd.
Artikel 23 van de NIS2-richtlijn introduceert een bindend driefasen rapportageregime — met concrete termijnen, concrete inhoudelijke vereisten en concrete gevolgen bij niet-naleving. Nationale implementaties specificeren de rapportagekanalen: in Duitsland gaan meldingen naar het BSI als centraal CSIRT.
Tegelijkertijd is het toepassingsgebied massaal uitgebreid. Alleen al in Duitsland vallen circa 30.000 organisaties onder de nieuwe vereisten. Voor velen van hen is het indienen van een gestructureerd incidentrapport bij een overheidsinstantie volledig nieuw terrein.
Het driefasen rapportageregime in detail
Fase 1: Vroegtijdige waarschuwing — Binnen 24 uur
Zodra een organisatie zich bewust wordt van een significant beveiligingsincident, moet een vroegtijdige waarschuwing worden ingediend bij de relevante autoriteit binnen 24 uur. "Significant" onder NIS2 betekent: het incident heeft ernstige operationele verstoringen of financieel verlies veroorzaakt of kan dit veroorzaken, of het heeft andere personen getroffen of kan hen treffen door aanzienlijke materiële of immateriële schade te veroorzaken.
De vroegtijdige waarschuwing moet aangeven: of het incident vermoedelijk is veroorzaakt door onrechtmatige of kwaadaardige handelingen, en of het een grensoverschrijdende impact zou kunnen hebben.
De vroegtijdige waarschuwing is bewust ontworpen als een snelle eerste melding — snelheid boven volledigheid. Maar "snel" betekent niet "informeel": het rapport moet worden ingediend via officiële kanalen en de vereiste elementen bevatten.
Fase 2: Gekwalificeerde melding — Binnen 72 uur
Binnen 72 uur na bewustwording van het incident volgt een gekwalificeerde incidentmelding. Deze werkt de vroegtijdige waarschuwing bij en omvat een initiële beoordeling: ernst en impact, getroffen systemen en diensten, en — waar beschikbaar — indicatoren van compromittering.
Dit is waar het verschil tussen documentatie en operationele capaciteit voor het eerst tastbaar wordt: binnen 72 uur moet een organisatie het incident niet alleen technisch hebben geanalyseerd, maar ook de resultaten kunnen presenteren in een gestructureerd, traceerbaar formaat van autoriteitsgraad.
Fase 3: Eindrapport — Binnen één maand
Uiterlijk één maand na de initiële melding is een eindrapport verschuldigd. Dit omvat een gedetailleerde beschrijving van het incident, analyse van de grondoorzaak, de genomen tegenmaatregelen en — waar relevant — grensoverschrijdende effecten.
Daarnaast kunnen autoriteiten te allen tijde tussentijdse rapporten opvragen. Exploitanten van kritieke infrastructuur worden in hun nationale implementaties met aanvullende detailvereisten geconfronteerd.
Waarom 24 uur korter is dan u denkt
Vierentwintig uur klinkt als een volledige dag. In de realiteit van een lopend beveiligingsincident is het een uiterst krap venster. Dit is wat er doorgaans binnen die 24 uur gebeurt — gelijktijdig:
Uur 0–4: Detectie en initiële triage. Een alert gaat af — of iemand meldt iets ongewoons. Het beveiligingsteam begint met triage: is dit een echt incident? Hoe ernstig? Welke systemen zijn getroffen? In veel organisaties is zelfs deze fase chaotisch omdat verantwoordelijkheden onduidelijk zijn of de juiste mensen niet bereikbaar zijn.
Uur 4–12: Parallelle escalatie. Terwijl de technische analyse doorgaat, moeten parallel beslissingen worden genomen: wie informeert het bestuur? Wie coördineert met Juridische Zaken en Communicatie? Zijn er contractuele meldingsverplichtingen naar klanten? Moet de functionaris gegevensbescherming worden betrokken? Elk van deze vragen vereist coördinatie tussen functies die in het dagelijks werk zelden samenwerken.
Uur 12–20: Feitenvergaring onder onzekerheid. De technische feiten zijn nog onvolledig. Het bestuur wil duidelijkheid. Juridische Zaken wil weten wat wel en niet kan worden gezegd. Communicatie heeft richtlijnen nodig voor de berichtgeving. Ondertussen moet de vroegtijdige waarschuwing worden opgesteld — met verplichte inhoud die betrouwbaar moet worden geformuleerd ondanks onvolledige informatie.
Uur 20–24: Rapportage. De vroegtijdige waarschuwing moet worden ingediend via het officiële portaal. Het moet de vereiste elementen bevatten, het moet worden ingediend door een bevoegd persoon, en het moet worden gedocumenteerd — voor het eigen bewijsspoor van de organisatie.
Daarom is een incidentresponsplan als PDF niet genoeg. Niet omdat het plan slecht is, maar omdat de operationele uitdaging ligt in coördinatie — en coördinatie onder tijdsdruk werkt alleen met een systeem, niet met een document.
De vijf vragen die in de eerste 24 uur moeten worden beantwoord
Elk van deze vragen klinkt eenvoudig. Geen ervan is dat wanneer het incident nog gaande is:
1. Wat is er gebeurd — en hoe erg is het?
Triage en initiële classificatie: is dit een significant incident onder NIS2? Welke systemen, diensten en gegevens zijn getroffen? Zijn er indicatoren van een actieve dreiging? Deze beoordeling moet snel plaatsvinden, ook al is de informatie schaars.
2. Wie beslist wat — en op basis waarvan?
Het bestuur draagt persoonlijke aansprakelijkheid. Maar het bestuur kan niet alleen beslissen — zij hebben verwerkte informatie nodig van Security, IT, Juridische Zaken en mogelijk Gegevensbescherming. Wie levert deze informatie? In welk formaat? Via welk kanaal? En wie heeft de bevoegdheid om de vroegtijdige waarschuwing goed te keuren voor indiening?
3. Welke externe meldingsverplichtingen gelden?
NIS2 is niet de enige verplichting. Een AVG-melding bij de toezichthouder voor gegevensbescherming kan parallel vereist zijn (72-uurstermijn). Er kunnen contractuele meldingsverplichtingen naar klanten bestaan. Exploitanten van kritieke infrastructuur worden met aanvullende vereisten geconfronteerd. Dit alles moet parallel worden beheerd — niet sequentieel.
4. Hoe coördineren de betrokken functies?
Security analyseert. Juridische Zaken beoordeelt. Communicatie stelt op. Het bestuur beslist. IT isoleert. In theorie is dit helder. In de praktijk — om 3 uur 's nachts, met onvolledige informatie en extreme tijdsdruk — breekt deze coördinatie regelmatig af. Wat nodig is: gedefinieerde rollen, gedefinieerde communicatiekanalen en een systeem dat bijhoudt wie wat wanneer heeft gedaan.
5. Hoe wordt alles gedocumenteerd — terwijl het gebeurt?
NIS2 vereist traceerbaarheid. Dit betekent: de gehele incidentrespons moet worden gedocumenteerd terwijl het plaatsvindt — niet achteraf gereconstrueerd. Wie heeft wanneer welke beslissing genomen? Op basis van welke informatie? Welke communicatie heeft plaatsgevonden? Welke versie van de situatiebeoordeling was actueel op het moment van rapportage? Deze documentatie is niet alleen relevant voor autoriteiten — zij beschermt het bestuur op de vraag van persoonlijke aansprakelijkheid.
Incidentresponsplan vs. incidentmanagementsysteem
Dit onderscheid is cruciaal — en wordt in de markt te zelden gemaakt:
Een Incidentresponsplan (IRP) beschrijft wat er in een noodgeval moet gebeuren: rollen, escalatiepaden, processtappen, contactlijsten. Het is een document — en als zodanig onmisbaar. ISO 27001 vereist het, en het vormt de basis voor elke incidentrespons.
Een Incidentmanagementsysteem (IMS) is de operationele infrastructuur die het plan uitvoert: real-time coördinatie tussen functies, gestructureerde communicatie, geversioneerde documentatie, geïntegreerd bewijsbeheer, statusoverzicht voor het bestuur en het vermogen om betrouwbare rapporten te produceren binnen wettelijke termijnen.
| Capaciteit | Incidentresponsplan | Incidentmanagementsysteem |
|---|---|---|
| Rollen en verantwoordelijkheden gedefinieerd | ✅ | ✅ |
| Escalatiepaden beschreven | ✅ | ✅ |
| Processtappen gedocumenteerd | ✅ | ✅ |
| Real-time coördinatie tussen functies | ❌ | ✅ |
| Geversioneerde documentatie tijdens het incident | ❌ | ✅ |
| Parallel beheer van meerdere meldingsverplichtingen | ❌ | ✅ |
| Geïntegreerd bewijsspoor voor autoriteiten | ❌ | ✅ |
| Real-time statusoverzicht voor het bestuur | ❌ | ✅ |
| Tijdige rapportage onder tijdsdruk | ❌ Afhankelijk van individuen | ✅ Systeemondersteund |
Een IRP zegt "zo hoort het te werken." Een IMS zorgt ervoor dat het ook daadwerkelijk werkt — om 3 uur 's nachts, wanneer de CISO op vakantie is, wanneer drie meldingsverplichtingen tegelijkertijd worden geactiveerd.
NIS2 beoordeelt niet het plan. NIS2 beoordeelt de capaciteit.
Wat organisaties nu moeten doen
1. Test uw IRP tegen NIS2-termijnen
Niet theoretisch, maar praktisch: tabletop-oefening met een realistisch scenario en de concrete vraag — kunnen we binnen 24 uur een vroegtijdige waarschuwing produceren die de vereiste elementen bevat? Waar breekt het proces? Wie is niet bereikbaar? Waar ontbreekt informatie?
2. Definieer rollen voor de rapportageketen
Wie heeft de bevoegdheid om de vroegtijdige waarschuwing goed te keuren? Wie bereidt de inhoud voor? Wie dient het in via het officiële portaal? Deze rollen moeten op naam zijn toegewezen — met plaatsvervangers. "Security handelt het af" is geen roltoewijzing.
3. Breng parallelle meldingsverplichtingen in kaart
NIS2, AVG, contractuele verplichtingen, sectorspecifieke vereisten — welke meldingsverplichtingen gelden voor welk incidenttype? Binnen welke termijn? Aan welke autoriteit? Dit overzicht moet bestaan vóór een incident, niet tijdens een incident worden ontwikkeld.
4. Bereid sjablonen voor
Sjablonen voor de 24-uurs vroegtijdige waarschuwing, de 72-uurs melding en het eindrapport — vooraf opgesteld, vooraf goedgekeurd, vooraf getest. Organisaties die het formaat tijdens een incident moeten definiëren, verliezen kritieke tijd.
5. Maak documentatie een real-time proces
Incidentrespons moet worden gedocumenteerd terwijl het plaatsvindt — niet achteraf. Dit betekent: een centrale, geversioneerde locatie voor situatiebeoordelingen, beslissingen, communicatie en bewijs. Verspreide e-mails, chatberichten en persoonlijke notities zijn geen bewijs van autoriteitsgraad onder NIS2.
6. Oefen regelmatig
Tabletop-oefeningen ten minste tweemaal per jaar — met wisselende scenario's, met betrokkenheid van alle relevante functies inclusief het bestuur. Elke oefening onthult hiaten die in een echt incident tijd kosten.
De regelgevende gevolgen
De gevolgen van niet-naleving van meldingsverplichtingen zijn duidelijk gedefinieerd:
Voor essentiële entiteiten: boetes tot EUR 10 miljoen of 2% van de wereldwijde jaaromzet. Voor belangrijke entiteiten: tot EUR 7 miljoen of 1,4%. In Duitsland daarnaast: persoonlijke aansprakelijkheid van het bestuur onder § 38 BSIG.
Maar het regelgevende gevolg is niet het enige risico. Een organisatie die na een beveiligingsincident niet binnen de vereiste termijn kan rapporteren, heeft een dubbel probleem: het incident zelf — en het bewijs dat zij niet aan haar verplichtingen heeft voldaan. Het tweede probleem is vaak het grotere.
Bronnen
- Richtlijn (EU) 2022/2555 (NIS2-richtlijn) – Volledige tekst – Publicatieblad van de Europese Unie. Artikel 23 over meldingsverplichtingen voor significante beveiligingsincidenten.
- OpenKRITIS - NIS2-Umsetzungsgesetz in Deutschland – § 32 BSIG over het driefasen rapportageregime.
- OpenKRITIS - NIS2-Umsetzungsgesetz in Deutschland - #nis2know informatiepakket: NIS-2 meldingsplicht – BSI-informatiepakket over de implementatie van meldingsverplichtingen.
- ENISA – Implementatierichtlijnen voor NIS2-beveiligingsmaatregelen – Implementatierichtlijnen van ENISA, specifiek over incidentafhandeling en rapportage.
- ENISA – Technische implementatierichtlijnen NIS2 – Technische richtlijnen over rapportageformaten, termijnen en bewijsvereisten.