Het register komt voor de plicht: de Cyberbeveiligingswet en de grenzen van één inventarisatie

Toen het Nederlandse kadaster in 1832 van start ging, was het werk al ruim twee decennia aan de gang: onder Frans bestuur was in 1811 begonnen met meten, schatten en tenaamstellen, perceel voor perceel, en volgens het Kadaster zelf duurde het tot 1844 voordat heel Nederland was geregistreerd. De grondbelasting was politiek het onderwerp; het landmeten was waar de jaren in gingen zitten. Die volgorde is sindsdien niet veranderd, en zij verklaart waarom de wet die op 15 augustus 2026 in werking treedt in de praktijk om iets anders vraagt dan de meeste bestuurders verwachten.

Op die datum treden de Cyberbeveiligingswet (Staatsblad 2026, 187) en het bijbehorende Cyberbeveiligingsbesluit in werking. Nederland zet daarmee de NIS2-richtlijn om in nationaal recht — laat, zoals het merendeel van de lidstaten volgens de omzettingsstand van de Commissie, maar niet vrijblijvend. Het besluit zelf, Staatsblad 2026, 189, is op dezelfde dag ondertekend en bepaalt zowel de inhoud van de zorgplicht als het tijdstip waarop de wet gaat gelden. Een praktische toelichting voor entiteiten staat op de themapagina van het NCSC.

Wat er op 15 augustus verandert

Voor essentiële en belangrijke entiteiten ontstaan er drie soorten verplichtingen tegelijk: registratie in een nationaal register, een zorgplicht voor de beveiliging van netwerk- en informatiesystemen, en een meldplicht voor significante incidenten. De sectoren zijn ruimer getrokken dan onder de oude Wet beveiliging netwerk- en informatiesystemen. Zorg, onderzoek, afvalwater, digitale dienstverlening en delen van de maakindustrie komen nu in beeld — al bepaalt niet de sector maar de wettelijke definitie plus het omvangscriterium of een concrete organisatie werkelijk essentiële of belangrijke entiteit is. Voor wie er wél onder valt, is het vaak de eerste keer dat een sectorale toezichthouder op dit terrein meekijkt.

Bestuurders lezen zo'n wet doorgaans van achter naar voren: eerst de sancties, dan de meldtermijnen, dan de vraag wie tekent. Dat is begrijpelijk maar ongelukkig, want de operationeel zwaarste bepalingen staan in het midden van het besluit en lezen als huishoudelijke voorschriften.

De zorgplicht vraagt eerst om een lijst

De artikelen 6 tot en met 18 van het Cyberbeveiligingsbesluit werken de zorgplicht uit, en vier ervan verdienen de aandacht van de jurist. Artikel 16 verlangt beleid voor het beheer van assets: een actueel overzicht van de middelen en regels voor hun classificatie. Artikel 13 verlangt beleid over het gebruik van cryptografie. De artikelen 10 en 11 verlangen beveiliging van de toeleveringsketen en van het verwerven, ontwikkelen en onderhouden van systemen. Rollen en verantwoordelijkheden staan niet in artikel 16 maar algemener in artikel 6; dat een register per systeem een eigenaar bij naam noemt, is dus een verstandige governancekeuze en geen letterlijk voorschrift.

Eén beperking hoort er meteen bij. Artikel 4 van het besluit regelt de verhouding tot Uitvoeringsverordening (EU) 2024/2690: voor onder meer cloud-, datacenter-, managed-service-, marktplaats-, zoekmachine- en socialemediadiensten wijzen de artikelen 6 tot en met 18 door naar de Europese uitvoeringsregels. Dat is geen schone scheiding per organisatie maar per hoedanigheid: een entiteit die zowel clouddienst levert als in een andere hoedanigheid onder de wet valt, kan beide regimes naast elkaar op zich van toepassing zien. De onderliggende vraag verandert daarmee niet — de rechtsgrond wel, en dat is precies het soort onderscheid dat in een concernbrede compliance-aanpak sneuvelt.

Juridisch zijn dat vier zelfstandige verplichtingen: artikel 16 verlangt een volledige, actuele assetinventaris, terwijl de artikelen 10, 11 en 13 eigen beleids- en procesplichten opleggen. Ze delen wel hun feitelijke basis — vier vragen die alle bij hetzelfde gegeven beginnen: wat heeft u, waarmee is het versleuteld, wie heeft het geleverd, en wat is er sindsdien in veranderd. Wie op de eerste vraag geen betrouwbaar antwoord heeft, kan de andere drie alleen op papier beantwoorden. En anders dan een beleidsdocument laat een inventaris zich toetsen: een toezichthouder die vraagt welke systemen nog op een verouderd sleutelalgoritme draaien, vraagt niet naar voornemens. Dat pleit ervoor die gegevens in één register onder te brengen — een implementatiekeuze die wij aanbevelen, geen vorm die het besluit voorschrijft.

Hier zit ook de verklaring voor een verschijnsel dat wij bij eerdere incidentanalyses zagen — de reconstructie achteraf kost vrijwel altijd meer tijd dan de inbraak zelf, omdat de onderzoekers eerst moeten vaststellen wat er überhaupt draaide. De zorgplicht verplaatst dat werk naar voren, en dat is precies wat een meldtermijn van vierentwintig uur veronderstelt.

Verwante registers, verschillende rechtsgronden

De komende jaren wordt op drie niveaus naar verwante gegevens gevraagd, en die niveaus lopen niet gelijk — in tijd niet en in reikwijdte evenmin. De Cyberbeveiligingswet stelt de vraag op entiteitsniveau: welke organisatie draagt de zorgplicht. De Cyber Resilience Act stelt haar op productniveau, en doet dat in twee stappen: de meldverplichting voor actief misbruikte kwetsbaarheden uit artikel 14 geldt vanaf 11 september 2026, terwijl de overige hier relevante verplichtingen voor fabrikanten — waaronder de softwarestuklijst uit bijlage I — pas vanaf 11 december 2027 van toepassing zijn; hoofdstuk IV van de verordening geldt al sinds 11 juni 2026. Het derde niveau is geen wettelijk regime maar contractueel: afnemers nemen bepalingen op die leveranciers verplichten hun cryptografie tijdig te kunnen vervangen. Die praktijk groeit, maar de omvang ervan is publiek slecht gedocumenteerd en wordt hier dus niet als vaststaand gepresenteerd.

Die drie verzamelingen zijn niet identiek. Een softwarestuklijst onder de CRA hoort bij het product- en kwetsbaarhedendossier van een fabrikant; een inventaris onder het Cyberbeveiligingsbesluit beschrijft de middelen die een entiteit gebruikt. Ze overlappen gedeeltelijk, het sterkst bij de organisatie die beide hoedanigheden heeft: verwante datasets met gedeelde identificatoren en verschillende juridische reikwijdte. Wat zich laat delen zijn juist die identificatoren — welk systeem, welke component, welke versie, welke leverancier. Wie per aanleiding een nieuwe lijst met eigen sleutels laat maken, houdt drie verzamelingen over die niet meer op elkaar te leggen zijn. Wij beschreven eerder waarom de cryptografische inventaris een bestuursdossier wordt; wat daar de aanleiding was, is hier één kolom in een breder geheel.

De Nederlandse context maakt dat in één specifiek geval scherper. Waar een instelling haar systemen grotendeels heeft uitbesteed en de onderliggende contracten dateren van vóór de migratiediscussie, ontstaat een asymmetrie die de wet niet oplost: de verplichting landt bij de instelling, terwijl het vermogen om haar na te komen bij een leverancier ligt die er niets over heeft toegezegd. Hoe vaak dat patroon voorkomt is publiek niet vastgesteld; dat het bij oudere uitbestedingscontracten voorkomt, blijkt in de praktijk zodra een migratieclausule wordt gezocht en niet gevonden.

Waarom AI-systemen slecht in een assetregister passen

De klassieke inventarisatie gaat over servers, applicaties en netwerkcomponenten: dingen met een versienummer en een eigenaar. Een AI-systeem past daar maar half in. Het model zit vaak bij een aanbieder, de gewichten veranderen zonder dat de afnemer het merkt, de afhankelijkheid loopt via een API, en de feitelijke beveiligingsgrens ligt bij een partij waarmee geen technische relatie bestaat maar wel een contractuele.

Artikel 15 van de AI-verordening stelt voor systemen met een hoog risico eisen aan nauwkeurigheid, robuustheid en cyberbeveiliging. Dat een aanbieder daarvoor moet weten welke componenten die eigenschappen dragen, staat er niet met zoveel woorden; het is onze lezing van wat de bepaling in de praktijk vergt. Onder die lezing is het dezelfde veronderstelling als in artikel 16 van het Cyberbeveiligingsbesluit, maar aan de andere kant van de keten. De juridische kwalificatievraag — welk regime raakt welk systeem — hebben wij eerder uitgewerkt naar aanleiding van identieke software met verschillende toepassingsdata; de administratieve vraag komt daar nu bij. Een organisatie kan een AI-toepassing correct classificeren en tegelijk niet kunnen zeggen welke versie er vorige week draaide.

Zes vragen die een register bruikbaar maken

Onderscheidend is niet de volledigheid van de lijst, maar of zij een vraag van een toezichthouder overleeft. Zes controlevragen, in deze volgorde:

1. Kan de lijst binnen een werkdag worden opgeleverd, of moet zij eerst worden samengesteld? Alleen het eerste is een register.
2. Staat er per systeem een verantwoordelijke functionaris bij naam, niet alleen een afdeling?
3. Is per systeem vastgelegd welke cryptografie het gebruikt, en wie dat kan wijzigen — de instelling of de leverancier?
4. Is er een softwarestuklijst voor de componenten die u zelf op de markt brengt, en sluit die aan op dezelfde identificatoren als het register?
5. Zijn AI-componenten opgenomen met hun aanbieder, versie-afspraak en wijzigingsclausule, of ontbreken zij omdat niemand ze als asset zag?
6. Wat gebeurt er met de lijst als de contactpersoon bij de leverancier vertrekt?

De laatste vraag is de meest voorspellende. Registers verouderen zelden door een besluit; ze verouderen doordat de persoon die ze bijhield iets anders ging doen. Wie wil weten hoe dit uitpakt in de eigen leveranciersafspraken: onze contractscan beoordeelt bestaande contracten op ketenbeveiliging, wijzigingsbeheer en cryptografische migratieclausules, met een vaste omvang en een schriftelijke bevinding per contract.

Wat er op het spel staat buiten de compliance-afdeling

Het is verleidelijk om dit als administratieve last te lezen, en voor een deel is het dat ook. Maar de entiteiten die op 15 augustus in beeld komen leveren drinkwater, behandelen patiënten, beheren onderzoeksdata en houden afvalwaterzuiveringen draaiend. Bij een storing is de eerste vraag van een burger niet welke richtlijn van toepassing was, maar hoe lang het duurt. Het antwoord op die vraag wordt bepaald door wat de organisatie vooraf van zichzelf wist.

Daarmee raakt het register aan meer dan techniek. Toezicht werkt in de praktijk zover als de feiten kenbaar zijn: een toezichthouder die niet kan vaststellen wat er draaide, komt niet verder dan de vraag stellen. En een bestuur dat zijn eigen systemen niet in beeld heeft, kan zijn verantwoordelijkheid moeilijk waarmaken — hoe de aansprakelijkheid in een concreet geval uitpakt, is een andere vraag, die van feiten en normen afhangt. De negentiende-eeuwse landmeters begrepen het praktische deel ervan: pas toen de percelen op de kaart stonden, kon er een zinnig gesprek worden gevoerd over wie waarvoor moest opdraaien. De sloten in de polder liggen er nog, en ze lopen nog altijd precies waar iemand ze ooit heeft ingetekend.

Bronnen: Cyberbeveiligingswet, Staatsblad 2026, 187 en Cyberbeveiligingsbesluit, Staatsblad 2026, 189 (beide ondertekend 8 juli 2026, inwerkingtreding 15 augustus 2026); Uitvoeringsverordening (EU) 2024/2690; Verordening (EU) 2024/2847 (Cyber Resilience Act), artikel 14 van toepassing vanaf 11 september 2026 en de overige fabrikantsverplichtingen vanaf 11 december 2027; Verordening (EU) 2024/1689 (AI-verordening), artikel 15; NIS2-omzettingsoverzicht van de Europese Commissie; Kadaster over de periode 1800-1850. Publieke stand van zaken geraadpleegd op 13 augustus 2026. Dit is gepubliceerde analyse, geen juridisch advies.