NIS2 Incidentmelding: De 24-uurstermijn en hoe u eraan voldoet (2026)
Published 22 feb 2026
By Anna Bley

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
Beveiliging
Compliance

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:


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.

CapaciteitIncidentresponsplanIncidentmanagementsysteem
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

  1. Richtlijn (EU) 2022/2555 (NIS2-richtlijn) – Volledige tekst – Publicatieblad van de Europese Unie. Artikel 23 over meldingsverplichtingen voor significante beveiligingsincidenten.
  2. OpenKRITIS - NIS2-Umsetzungsgesetz in Deutschland – § 32 BSIG over het driefasen rapportageregime.
  3. OpenKRITIS - NIS2-Umsetzungsgesetz in Deutschland - #nis2know informatiepakket: NIS-2 meldingsplicht – BSI-informatiepakket over de implementatie van meldingsverplichtingen.
  4. ENISA – Implementatierichtlijnen voor NIS2-beveiligingsmaatregelen – Implementatierichtlijnen van ENISA, specifiek over incidentafhandeling en rapportage.
  5. ENISA – Technische implementatierichtlijnen NIS2 – Technische richtlijnen over rapportageformaten, termijnen en bewijsvereisten.

Gerelateerde artikelen

NIS2 Incidentmelding: De 24-uurstermijn en hoe u eraan...