Wat de Cyberbeveiligingswet precies verplicht
De Cyberbeveiligingswet zet de Europese NIS2-richtlijn om in Nederlands recht. Vanaf 15 augustus 2026 gelden voor de organisaties die eronder vallen vier hoofdverplichtingen:
- Registratieplicht: je meldt je organisatie aan in het entiteitenregister bij het Nationaal Cyber Security Centrum, inclusief de internetdomeinen waarvoor je verantwoordelijk bent
- Zorgplicht: je voert risicoanalyses uit en treft passende maatregelen om de continuïteit van je dienstverlening en de gebruikte informatie te beschermen
- Meldplicht: significante incidenten meld je in drie stappen, een vroegtijdige waarschuwing binnen 24 uur, een uitgebreidere melding binnen 72 uur en een eindrapport binnen een maand
- Bestuurlijke verantwoordelijkheid: het bestuur keurt de maatregelen goed, houdt toezicht op de uitvoering en moet verplichte scholing volgen, waarvoor maximaal twee jaar na inwerkingtreding beschikbaar is
Naast de Cyberbeveiligingswet treedt op dezelfde dag de Wet weerbaarheid kritieke entiteiten in werking, die zich richt op ongeveer 500 organisaties en over fysieke weerbaarheid gaat. De twee wetten overlappen deels in doelgroep.
Waarom dit ook geldt voor bedrijven buiten de achttien sectoren
Hier zit de kern voor de meeste lezers. De zorgplicht is niet beperkt tot wat er binnen de eigen muren gebeurt. Organisaties die onder de wet vallen moeten ook het risico beheersen dat via hun leveranciers binnenkomt. Dat is geen theoretische bepaling: de grootste incidenten van de afgelopen jaren kwamen niet binnen via de voordeur van het slachtoffer, maar via een beheertool, een koppeling of een softwareupdate van een derde partij.
Praktisch betekent dat het volgende. Zodra jouw klant onder de Cyberbeveiligingswet valt, moet die klant kunnen onderbouwen dat jij als leverancier geen onbeheerst risico vormt. Dat komt bij je binnen als:
- Beveiligingsbijlagen bij nieuwe of te verlengen contracten, met concrete eisen over patching, toegangsbeheer en incidentmelding
- Vragenlijsten over hoe jij ontwikkelt, test, uitrolt en wie er bij productiedata kan
- Meldafspraken met een termijn die korter is dan die van je klant, want jouw klant moet binnen 24 uur bij het NCSC melden en heeft jouw signaal dus eerder nodig
- Eisen aan onderaannemers en aan de clouddiensten die jij gebruikt
Je hoeft je niet te registreren en je krijgt geen boete van de toezichthouder. Maar je verliest wel opdrachten als je deze vragen niet kunt beantwoorden.
Wat je als softwareleverancier concreet moet kunnen laten zien
De vragen die je krijgt zijn redelijk voorspelbaar en gaan bijna altijd over dezelfde zes gebieden:
- Toegangsbeheer: wie heeft toegang tot code, servers en productiedata, is dat met tweefactorauthenticatie, en wordt toegang ingetrokken als iemand vertrekt
- Kwetsbaarhedenbeheer: hoe weet je dat je afhankelijkheden veilig zijn, hoe snel patch je een kritieke kwetsbaarheid, en waar leg je dat vast
- Veilig ontwikkelen: code review, gescheiden omgevingen voor ontwikkelen, testen en productie, en geen productiedata in testomgevingen
- Logging en detectie: kun je achteraf reconstrueren wie wat wanneer deed, en hoe lang bewaar je die logs
- Incidentproces: wie bel je binnen hoeveel uur, wie beslist, en wie informeert de klant
- Continuïteit: back-ups die je aantoonbaar hebt teruggezet, en een herstelplan dat een keer geoefend is
Dat is geen certificeringstraject, dat is documentatie van wat een professioneel ontwikkelteam grotendeels al doet. Het verschil zit in aantoonbaarheid. Wij werken volgens ISO 27001, wat betekent dat deze onderwerpen vastgelegd en periodiek getoetst zijn. Dat scheelt onze klanten een hoop discussie bij hun eigen leveranciersbeoordeling.
Koppelingen en integraties zijn het gevoeligste punt
Ketenrisico wordt in de praktijk vooral concreet bij integraties. Een koppeling tussen een klantsysteem en een ERP, CRM of zorgsysteem is per definitie een verbinding die de grens van twee organisaties oversteekt, vaak met verregaande rechten en zonder dat iemand er dagelijks naar kijkt.
Waar het misgaat is meestal hetzelfde. Een integratie draait onder een technisch account met veel meer rechten dan nodig, omdat dat bij de bouw het snelst werkte. Sleutels staan in een configuratiebestand in plaats van in een secrets manager. Er wordt niet gelogd welke records via de koppeling zijn gelezen of gewijzigd. Of de koppeling draait nog jaren nadat het proces erachter is gestopt.
Bij het bouwen van API-integraties en bredere koppelingen tussen systemen zijn dit voor ons standaardpunten: het minimale rechtenniveau per koppeling, sleutels die roteerbaar zijn, en logging op het niveau van individuele acties zodat je bij een incident binnen uren kunt zeggen wat er precies is geraakt. Dat laatste is niet alleen prettig, het is met een meldtermijn van 24 uur simpelweg noodzakelijk.
Wat je in de komende weken kunt regelen
Voor 15 augustus 2026 hoef je niet klaar te zijn met alles, maar een paar dingen wil je op orde hebben voordat de eerste vragenlijst binnenkomt:
- Maak een lijst van je klanten en bepaal welke onder de achttien sectoren van de wet vallen. Daar komt het vandaan
- Inventariseer welke systemen, koppelingen en toegangen jij bij die klanten hebt. Vaak is die lijst langer dan verwacht, met vergeten testaccounts en oude VPN-toegangen
- Leg je incidentproces vast op één pagina: wie meldt, aan wie, binnen hoeveel uur, en via welk kanaal. Spreek dat expliciet af met de klanten waar het om gaat
- Controleer je onderaannemers en clouddiensten met dezelfde vragen die jij zelf krijgt. De keten stopt niet bij jou
- Ruim ongebruikte toegang en verouderde koppelingen op. Dit is de goedkoopste risicoreductie die er bestaat
Val je zelf wel onder de wet, dan komt daar de registratie bij het NCSC bij, plus de bestuurlijke kant: goedkeuring van de maatregelen en de scholing waarvoor maximaal twee jaar staat.
Hoe wij hierin meewerken
Bij de systemen die wij bouwen en beheren nemen we deze onderwerpen mee in het ontwerp in plaats van in een bijlage achteraf. Dat betekent gescheiden omgevingen, rechten per koppeling in plaats van één alles-mogende technische gebruiker, en logging die fijnmazig genoeg is om een incident te reconstrueren. Voor klanten in gereguleerde sectoren leveren we de documentatie mee die ze nodig hebben om hun eigen leveranciersbeoordeling af te ronden.
Werk je met een bestaand landschap waarin niemand meer precies weet welke koppelingen actief zijn en met welke rechten, dan is een inventarisatie het logische startpunt. Dat is meestal een kwestie van dagen, niet maanden, en het levert vrijwel altijd een paar verrassingen op die je sowieso wilt opruimen. Meer over hoe we zulke trajecten inrichten lees je bij maatwerksoftware laten ontwikkelen en op onze aanpak-pagina.
Loop je nu al tegen leveranciersvragenlijsten aan of wil je weten wat de wet voor jouw situatie betekent, neem dan contact op. We kijken mee naar je koppelingen, je toegangsbeheer en je incidentproces en benoemen wat er echt moet en wat kan wachten.