Sinds 15 augustus 2026 is de Cyberbeveiligingswet van kracht, gepubliceerd als Staatsblad 2026, 187. Circa 8.000 organisaties vallen in scope. Registratie bij het NCSC is sinds die datum verplicht.
Deze maand publiceert elke IT-consultant in het land een stuk over wat de wet vereist. Ik doe dat hier niet. De vraag die een bestuurder er in de praktijk bij heeft, is een andere: wat gebeurt er als iemand daadwerkelijk komt kijken?
Niet welk beleid je moet schrijven. Niet welk normenkader het meest indruk maakt. Maar: als er iemand aan je bureau zit, wat klik je dan open?
De toezichthouder — de Rijksinspectie Digitale Infrastructuur, kortweg RDI — is daar ongewoon direct over geweest.
Wat een certificaat niet doet
“Nee, het voldoen aan een eigen normenkader betekent niet dat een organisatie aan de zorgplicht voldoet.”
— Rijksinspectie Digitale Infrastructuur
Op diezelfde pagina staat direct de kanttekening, en die hoort erbij — een citaat zonder zijn eigen nuance is een half verhaal:
“Een normenkader kan wel houvast geven bij het beheersen van de risico’s van de beveiliging van de netwerk- en informatiesystemen.”
— Rijksinspectie Digitale Infrastructuur, dezelfde pagina
Een normenkader is dus niet nutteloos. Het is alleen niet het bewijs. Het is een manier om risico’s te ordenen, geen vervanging voor de vraag of het werkt.
En ze mogen kijken
De tweede uitspraak staat op een andere pagina, over het toezicht zelf:
“Ook mogen we ter plekke uw systemen inkijken.”
— Rijksinspectie Digitale Infrastructuur
Dat is het punt waar dit stuk over gaat. Niet het papierwerk. De systemen zelf.
Het onderscheid dat ertoe doet
Een certificaat beschrijft wat je bedoelde. Een inspectie kijkt naar wat er draait.
Die twee lopen uit elkaar zodra niemand meer controleert of ze nog samenvallen. Het normenkader dateert van vorig jaar; de server is drie keer bijgewerkt sindsdien, een leverancier is vervangen, iemand kreeg toegang die nooit meer is ingetrokken. Op papier klopt het nog. Op het scherm niet meer.
Die drift is niet het gevolg van nalatigheid. Het is wat er sowieso gebeurt in een organisatie die groeit, mensen aanneemt, mensen ziet vertrekken en van leverancier wisselt. Het enige verschil tussen een organisatie die dat bijhoudt en een organisatie die dat niet doet, is of er iemand kijkt vóórdat de toezichthouder dat doet.
Dus: wat leg je op tafel als iemand het wil zien? Niet vier hoofdstukken beleid, maar vier dingen die je kunt aanwijzen — een scherm, een log, een gedateerd record, een lijst.
Toegang die vastligt en te herleiden is
Je zou moeten kunnen inloggen op één plek waar alle toegang samenkomt — single sign-on, meervoudige authenticatie — en daar een toegangsmatrix laten zien die klopt met wie er nu werkelijk bij kan. Niet de matrix die ooit is opgesteld. De actuele.
Daarnaast een log. Niet “we loggen dat”, maar een concrete query: wie kreeg op welk moment toegang tot wat, en wie heeft die toegang weer ingetrokken toen iemand vertrok. Als je die vraag niet binnen een paar minuten kunt beantwoorden vanaf een scherm, heb je een beleidsdocument, geen toegangsbeheer.
Dit is ook de plek waar de meeste organisaties het eerst door de mand vallen. Niet omdat er geen wachtwoordbeleid is, maar omdat er niemand meer weet wie er nog bij kan sinds die ene collega drie functies geleden vertrok.
Herstel dat getest is, niet aangenomen
Een back-upschema is een belofte. Een teruggezette back-up is een feit. Bij een groter implementatietraject hoort daar een daadwerkelijk uitgevoerde restore bij, met een datum, een doorlooptijd en een uitkomst op papier — niet de intentie om ooit te testen, maar het record van de keer dat het is gebeurd.
Een back-up waarvan nooit is teruggezet, is geen herstelvermogen. Het is een aanname die nog niemand heeft tegengesproken.
Het verschil is meteen zichtbaar op het scherm. Een schema dat draait, toont een volgende geplande taak. Een geteste restore toont een afgeronde taak, met een tijdstip erbij — en dat tweede scherm bestaat bij lang niet elke organisatie.
Een dossier dat de werkelijkheid beschrijft
Niet een document dat zegt wat er zou moeten gebeuren, maar een lijst die klopt met wat er draait: welke maatregel op welk systeem actief is, wie ervoor tekent, welke leverancier erachter zit en welke eisen je die leverancier hebt opgelegd.
Dat laatste wordt vaak overgeslagen. De ketenbeveiliging van je eigen organisatie stopt niet bij je eigen infrastructuur — hij stopt bij de zwakste schakel van je leveranciers, en die moet je kunnen aanwijzen, niet vermoeden.
Vraag jezelf bij elke leverancier op die lijst: als deze partij vanmiddag wordt gehackt, wat weet ik dan al, en wat moet ik dan nog uitzoeken? Als het antwoord “alles” is, staat er wel een naam op de lijst, maar geen dossier.
Een bestuur dat weet wat er van hem verwacht wordt
In de praktijk wordt dit bij het bestuur neergelegd: het is degene die eindverantwoordelijk is voor de zorgplicht. Wat je daarvoor kunt tonen, is geen mission statement over veiligheid, maar een gedateerde bestuurssessie: wanneer die plaatsvond, wie erbij was, en welke besluiten er zijn genomen — niet welke presentatie er is gegeven.
Een bestuur dat kan uitleggen welke afweging het heeft gemaakt, staat er anders voor dan een bestuur dat kan uitleggen dat het is voorgelicht.
Mijn eigen situatie
Ik draai de stack die ik aanraad zelf, op eigen hardware, in mijn eigen rack. Niet als demonstratie, maar omdat ik er dagelijks mee werk. Als de toezichthouder ooit ter plekke wil kijken, is ze welkom.
Dat is precies het verschil waar dit stuk over gaat. Een certificaat kun je inkopen. Een systeem dat overeind blijft als iemand het openklapt, kun je alleen bouwen.