Cyberbeveiligingswet en informatiedeling: vrijwillig meedoen, verplicht melden

Uw klant zit sinds vorig najaar in een sector-ISAC van het NCSC. Verstandig: vroege waarschuwingen over de ransomwaregroepen die hun branche bewerken, in ruil voor eigen indicatoren terug in de pool.

Negen maanden later vraagt een toezichthouder welke afspraken over informatiedeling de entiteit heeft. De deelname is echt. De melding is er niet. Niemand heeft er een gedaan, omdat niemand verder las dan het woord "vrijwillig".

Dat is artikel 29 van NIS2. Onder de Cyberbeveiligingswet informatiedeling glipt deze plicht er juist doorheen omdat alles eromheen optioneel lijkt.

Artikel 29 maakt het delen vrijwillig en de administratie verplicht

Artikel 29, lid 1 verplicht lidstaten ervoor te zorgen dat entiteiten binnen — en waar relevant buiten — het toepassingsgebied vrijwillig relevante cyberbeveiligingsinformatie kunnen uitwisselen. De richtlijn noemt het op: cyberdreigingen, bijna-incidenten, kwetsbaarheden, technieken en procedures, indicators of compromise, tactieken van aanvallers, dreigingsactor-specifieke informatie, waarschuwingen en aanbevelingen voor de configuratie van detectietooling.

Er gelden twee doeltoetsen. Onder lid 1(a) moet het delen gericht zijn op het voorkomen, detecteren, beantwoorden of herstellen van incidenten, of het beperken van de gevolgen. Onder lid 1(b) moet het het cyberbeveiligingsniveau verhogen: bewustwording, het indammen van dreigingen, herstel en openbaarmaking van kwetsbaarheden, detectie en insluiting, mitigatie, respons en herstel, of gezamenlijk onderzoek tussen publieke en private partijen.

Lid 2 legt de vorm vast. De uitwisseling vindt plaats binnen gemeenschappen van essentiële en belangrijke entiteiten en, waar relevant, hun leveranciers of dienstverleners — via een regeling voor het delen van cyberbeveiligingsinformatie, juist omdat het materiaal gevoelig is.

En dan lid 4, de zin die vrijwel elk programma overslaat: lidstaten zorgen ervoor dat essentiële en belangrijke entiteiten de bevoegde autoriteiten in kennis stellen van hun deelname aan die regelingen zodra zij eraan deelnemen, en van hun terugtrekking zodra die van kracht wordt.

Geen drempel. Geen materialiteitstoets. Geen overgangstermijn in het artikel zelf.

Een regeling is geen appgroep

Het woord "regeling" doet hier echt werk, en daar gaat het in beide richtingen mis.

Geen regeling: vier security leads die IOC''s uitwisselen in een WhatsAppgroep. De publieke dreigingsblog van een leverancier. Een gesprek op de gang bij een congres.

Wel een regeling: een sector-ISAC met een charter en deelnemersvoorwaarden. Een MISP-community met vastgelegde TLP-afspraken. Een platform van het NCSC of een andere CSIRT. Een geformaliseerde afspraak met leveranciers die in het contract staat.

Lid 3 bevestigt die vorm: regelingen mogen operationele elementen vastleggen, waaronder specifieke ICT-platformen, automatiseringstools en de inhoud en voorwaarden van de uitwisseling. Is er lidmaatschap, zijn er regels en is er een classificatieschema, ga er dan van uit dat het meldplichtig is.

Het grijze gebied is de dreigingscommunity van een leverancier — het soort dat een EDR- of threat-intelpartij voor klanten draait. Heeft uw klant voorwaarden getekend en deelt hij terug, dan is het een regeling, hoe de marketingpagina het ook noemt.

Nederland: de ISAC''s zijn ouder dan de meldplicht

Dit is het Nederlandse probleem in één zin. De sector-ISAC''s draaien al jaren via het NCSC. De Cyberbeveiligingswet is pas op 15 augustus 2026 in werking getreden.

Dat betekent dat een flink deel van de bestaande lidmaatschappen dateert van vóór de wettelijke meldplicht en nooit is gemeld. Zo''n lidmaatschap corrigeert zichzelf niet: er is geen jaarlijkse bevestiging die het alsnog zichtbaar maakt.

De Rijksinspectie Digitale Infrastructuur is voor een groot deel van de sectoren de toezichthouder onder de Cyberbeveiligingswet; voor andere sectoren zijn sectorale toezichthouders aangewezen. U meldt bij de bevoegde autoriteit die de entiteit daadwerkelijk onder toezicht houdt, niet bij de partij die de ISAC organiseert. Twijfelt u welke dat is, begin dan bij artikel 26 NIS2 en de jurisdictietoets.

Werkt u ook in Vlaanderen, houd er dan rekening mee dat België via het CCB een eigen structuur en eigen meldkanalen heeft. Eén Nederlandse melding dekt een Belgische entiteit niet.

NIS2 Implementatiestatus per Land (2025–2026)
✅
Volledig van kracht
🇧🇪België
🇭🇷Kroatië
🇭🇺Hongarije
🇱🇹Litouwen
🇱🇻Letland
🇮🇹Italië
6 landen
📋
Aangenomen — eind 2025
🇩🇪Duitsland
🇨🇿Tsjechië
🇫🇮Finland
3 landen
⏳
In uitvoering — verwacht 2026
🇳🇱Nederland
🇫🇷Frankrijk
🇪🇸Spanje
🇵🇱Polen
🇦🇹Oostenrijk
🇸🇪Zweden
🇮🇪Ierland
7 landen

Artikel 29 is geen artikel 23 en geen artikel 30

Drie mechanismen worden in klantgesprekken standaard op één hoop gegooid.

Artikel 23 is de verplichte incidentmelding: vroege waarschuwing binnen 24 uur, melding binnen 72 uur, eindrapport binnen een maand. Zie onze uitleg van de NIS2-meldtermijnen.

Artikel 30 is de vrijwillige melding. Entiteiten mogen incidenten, dreigingen en bijna-incidenten onder de drempel melden; partijen buiten het toepassingsgebied mogen dat ook.

Artikel 29 loopt horizontaal — entiteit naar entiteit, niet entiteit naar staat. Het delen is vrijwillig. Het enige verplichte onderdeel is de mededeling dat u meedoet.

Twee faalmodi volgen daaruit: klanten die een artikel 29-melding doen en denken dat ze een incident hebben gemeld, en klanten die incidenten keurig melden maar nooit hebben verteld in welke drie communities ze zitten.

Geldt de meldplicht voor uw klant?

In deze volgorde.

Is de entiteit essentieel of belangrijk onder de Cyberbeveiligingswet? Zo niet, dan raakt lid 4 haar niet — al kunnen de voorwaarden van de regeling zelf wel gelden voor een leverancier.

Neemt de entiteit deel aan een gestructureerde regeling zoals hierboven beschreven?

Is er een melding gedaan bij de bevoegde autoriteit, gedateerd op of rond het moment van toetreden? "We hebben het genoemd bij de registratie" is geen melding.

Twee van de drie is geen naleving.

De terugtrekking is waar het misgaat

Toetreden wordt onthouden omdat iemand iets tekent. Uittreden niet.

Lidmaatschappen verlopen als de trekker vertrekt. Abonnementen worden niet verlengd. Een MISP-community wordt stil en niemand treedt formeel uit. Een securitypartner wordt vervangen en de klant verliest ongemerkt toegang tot de community die bij dat contract hoorde.

Lid 4 koppelt de melding aan het moment waarop de terugtrekking van kracht wordt. Iemand moet dat moment dus opmerken. In de praktijk is dat een registerprobleem, geen juridisch probleem.

Houd per klant één lijst bij: naam van de regeling, beheerder, datum van toetreding, datum van melding, kenmerk van de melding, interne eigenaar en verlengdatum. Loop die lijst na wanneer u de registratiegegevens actualiseert — dat dossier gaat toch al open. Zie onze uitleg over de registratieplicht.

Wat de toezichthouder opvraagt

Verwacht de vraag binnen een breder documentatieverzoek, niet als losse actie. De bewijsset is klein:

• De lijst met regelingen waaraan de entiteit deelneemt
• Bewijs van melding per regeling, met datum
• De voorwaarden of het charter van elke regeling
• Uw omgangsbeleid voor ontvangen informatie: classificatie, opslag, wie mag handelen
• Bewijs dat uitgaande informatie vooraf is getoetst

Dat laatste punt wordt onderschat. Indicatoren delen tijdens een lopend incident raakt tegelijk aan contractuele geheimhouding, aansprakelijkheid en de AVG. Leg vooraf vast wie uitgaande deling goedkeurt. Zie verder onze checklist met bewijsmateriaal voor NIS2-audits.

Zet het in de onboarding, niet in de jaarlijkse opschoning

De praktische fix kost ongeveer een uur per klant en hoeft daarna nooit meer opnieuw.

Voeg twee vragen toe aan uw intake: in welke dreigingscommunities zit deze organisatie, en wie is intern eigenaar van elk lidmaatschap. De meeste klanten noemen er één en vergeten er twee — controleer de securitytooling en de CSIRT-relaties voor de rest.

Doe daarna de ontbrekende meldingen, leg ze vast en zet het register op dezelfde cyclus als de registratiegegevens.

Wilt u eerst weten waar een klant staat op artikel 21, artikel 23 en de bestuursplichten voordat u begint met melden, voer dan een gratis NIS2-readinessscan uit en werk vanuit de gaten die daaruit komen.

Dreigingsinformatie delen is een van de weinige NIS2-verplichtingen die een organisatie meetbaar veiliger maakt in plaats van alleen beter gedocumenteerd. De meldplicht is het goedkope deel. Doe het één keer goed en houd het register bij.