De meldplicht is een van de meest operationeel uitdagende verplichtingen van de Cyberbeveiligingswet. Binnen 24 uur na ontdekking van een significant incident moet een eerste melding zijn gedaan. Binnen 72 uur volgt een volledige melding met een gedetailleerde beoordeling. Zonder een voorbereide pipeline — detectie, triage, dossiervorming, escalatie — is dat tijdspad in de praktijk vrijwel onhaalbaar.

Behandel de meldplicht dan ook niet als procedure maar als een engineeringsvraagstuk: bouw het proces voordat je het nodig hebt.

Wat de Cyberbeveiligingswet precies vraagt

NIS2 Artikel 23 verplicht essentiële en belangrijke entiteiten om significante incidenten te melden bij de bevoegde nationale autoriteit — in Nederland het NCSC of een sectorale autoriteit — en in specifieke gevallen ook aan getroffen afnemers wanneer de dienst substantieel wordt beïnvloed.

Een incident is significant als het een ernstige operationele verstoring veroorzaakt of kan veroorzaken, finansiële verliezen tot gevolg heeft of kan hebben, of andere personen en organisaties raakt via verstoring of reputatieschade. De tijdlijn is strak: 24 uur voor de eerste “early warning”, 72 uur voor de volledige melding met initiële beoordeling en classificatie, en 30 dagen voor de eindrapportage met volledige analyse.

Incidentdefinitie en hoe je triage structureert

Niet elk beveiligingsevent is meldplichtig. De eerste stap in de pipeline is een heldere drempel voor triage. In de praktijk werkt een eenvoudige matrix met twee assen: bereik en impact. Bereik zegt iets over het aantal getroffen systemen, diensten of gebruikers. Impact gaat over beschikbaarheid, integriteit, vertrouwelijkheid en financieel of reputationeel gevolg.

De operationele richtlijn is simpel: classificeer binnen maximaal twee uur na detectie. Als je na twee uur twijfelt over de drempel, behandel het incident als meldplichtig en schaal later af als dat gerechtvaardigd is. Voorzichtigheid kost je bij een non-incident weinig; een gemiste melding bij een serieus incident kost je veel meer.

Welk bewijsmateriaal je altijd nodig hebt

Een NIS2-melding zonder onderbouwend bewijsmateriaal is onvolledig. Je hebt in elk geval de volgende artefacten nodig: een tijdlijn van events met tijdstempel en tijdzonecorrectie, de betrokken systemen en IP-ranges, de gebruikte accounts — inclusief service- en beheeraccounts — en logbestanden van minimaal de 48 uur voorafgaand aan de detectie.

Bij datalekken of exfiltratie komen daar de betrokken datasets bij inclusief hun classificatie, bewijs van toegang of extractie zoals transfer logs of DLP-alerts, en documentatie van de melding aan de Autoriteit Persoonsgegevens. Bij ransomware of malware heb je de hash van aangetroffen bestanden nodig, de C2-domeinen en IP-adressen, de geïdentificeerde variant waar mogelijk, en cruciale informatie over de backup-status op het moment van de aanval.

Bewaar incidentartefacten minimaal vijf jaar, of conform sectorspecifieke retentievereisten die strenger zijn.

Van SIEM naar meldingssjabloon: automatisering loont

Een handmatig meldproces haalt de 24-uur deadline zelden als er daadwerkelijk iets ernstigs gebeurt. Structureer de pipeline in lagen. In de detectielaag zorg je voor SIEM-regels die zijn gekoppeld aan je drempeldefinities: ongeautoriseerde privilegeescalatie, massale encryptie-activiteit, exfiltratievolumes en authenticatiefailures boven een gedefinieerde drempel.

In de triage-laag vindt automatische enrichment plaats van SIEM-alerts met contextdata over assetclassificatie, gebruikersrol en netwerkzone. Het resultaat is een vooraf geclassificeerde severity-score die de SOC-analist als startpunt gebruikt, niet als eindoordeel. In de dossierlaag centraliseert geïntegreerd case management alle logs, screenshots, tijdlijnentries en communicatie. Alles is tijdgestempeld en gekoppeld aan de analist die er actie op heeft ondernomen — dat vormt je auditspoor voor de toezichthouder.

Bereid twee sjablonen voor: één voor de 24-uur early warning, één voor de 72-uur volledige melding. Vul de statische velden vooraf in. Tijdens een incident vul je alleen de incidentspecifieke velden in. Dat scheelt kostbare tijd.

Oefenen is niet optioneel

Bouw elk kwartaal een tabletop-oefening in waarbij je een fictief scenario door de volledige pipeline laat lopen. Doelstelling: de 24-uur melding binnen vier uur kunnen opleveren.

Evalueer na elke oefening welke stap het langst duurde, welke logs ontbraken, of de severity matrix eenduidig was en of de sjablonen de relevante velden bevatten. Post-incident reviews zijn alleen nuttig als ze leiden tot concrete aanpassingen in de pipeline.

Standpunt

De meldplicht is een van de onderdelen van NIS2 waar ik het meest uitgesproken over ben. Niet vanwege de tijdsdruk — die is strak maar realistisch als je goed voorbereid bent — maar vanwege wat de verplichting eigenlijk vraagt.

Melden is ongemakkelijk. Het vereist dat je als organisatie openbaar maakt dat er iets mis is gegaan. Dat voelt als zwakte, maar is in werkelijkheid het tegenovergestelde: het is de professionele norm dat je eerlijk bent over incidenten, zodat anderen ervan kunnen leren en de toezichtketen zijn werk kan doen.

Ik vind het ook positief dat NIS2 melden uitdrukkelijk wil ontkoppelen van boetes en sancties. Het doel is informatie-uitwisseling en tijdige respons, niet het bestraffen van slachtoffers van aanvallen. Die intentie verdient het om serieus te worden genomen.

Wat ik in mijn werk bij CyberSecurity AD zie is dat de meldplichtverplichting ook een goede aanleiding is om te nadenken over de bredere detectie- en responsinfrastructuur. Wie zijn pipeline bouwt voor de meldplicht, bouwt tegelijkertijd een betere SOC-werking. Dat is een positief nevengevolg dat de investering meer dan waard maakt.

Voor advocatenkantoren die onder NIS2 vallen — en sommige grotere kantoren vallen inderdaad in scope — is dit een extra reden om de technische infrastructuur grondig te beoordelen. Een platform als CyberSecurity AD dat auditsporen produceert die voldoen aan de forensische normen van de strafrechtspraktijk, voldoet ook aan de logvereisten die NIS2 stelt. Dat is geen bijkomstigheid; het is een directe uitkomst van bouwen volgens de hoogste technische standaarden.