Cyberbeveiligingswet treedt op 15 augustus 2026 in werking — wat verandert er?

De datum staat vast. Op 7 juli 2026 maakte de Rijksoverheid bekend dat de Cyberbeveiligingswet (Cbw) en de Wet weerbaarheid kritieke entiteiten (Wwke) op 15 augustus 2026 in werking treden. Vanaf dat moment gelden voor essentiële en belangrijke entiteiten vijf verplichtingen tegelijk: registratie bij het NCSC, een zorgplicht, een meldplicht voor significante incidenten, aantoonbare cyberkennis op bestuursniveau, en risicobeheer over de hele toeleveringsketen. Vier daarvan kunt u met tooling ondersteunen. Degene die het zwaarst weegt — aantonen dat uw architectuur de zorgplicht haalt — is precies wat een kwetsbaarhedenscan niet oplevert.

De Tweede Kamer nam het voorstel aan op 15 april 2026, de Eerste Kamer rondde de behandeling begin juli af, en met de aankondiging van 7 juli is de inwerkingtreding nu een vaste datum. Wat maandenlang “komt eraan” was, is nu een deadline.

Belangrijkste punten

• De Cyberbeveiligingswet treedt op 15 augustus 2026 in werking; de Wet weerbaarheid kritieke entiteiten op dezelfde dag. De Rijksoverheid bevestigde dit op 7 juli 2026.
• Vanaf inwerkingtreding gelden vijf verplichtingen tegelijk: NCSC-registratie, een zorgplicht, een meldplicht, aantoonbare bestuurderskennis en ketenrisicobeheer.
• De datum is nu bevestigd — de eerdere onzekerheid (verschuiving van 1 juli, lopend Kamerproces) is voorbij. Voorbereiden is geen “als het doorgaat” meer.
• De zorgplicht vraagt niet wat uw beleid zegt, maar of uw omgeving daar nu aan voldoet. Dat is een bewijsvraag, geen documentvraag.
• Een SAST/DAST/SBOM-stack toont welke kwetsbaarheden in code en containers zitten — noodzakelijk, en onderdeel van Artikel 21 — maar levert geen architectuurbewijs dat een bestuur of toezichthouder opvraagt.

Wat is er op 7 juli 2026 bevestigd?

De Rijksoverheid heeft bekendgemaakt dat de Cyberbeveiligingswet op 15 augustus 2026 in werking treedt, samen met de Wet weerbaarheid kritieke entiteiten. De Cbw is de Nederlandse omzetting van NIS2 en vervangt de Wet beveiliging netwerk- en informatiesystemen (Wbni); de Wwke implementeert de Europese CER-richtlijn en richt zich op de bredere weerbaarheid van formeel aangewezen kritieke entiteiten. Een organisatie kan onder beide vallen.

Het afgelopen jaar draaide het gesprek vooral om die datum: komt hij, schuift hij, geldt de wet al. De inwerkingtredingsdatum is inderdaad eerder opgeschoven — van 1 juli naar 15 augustus 2026. Die onzekerheid is nu weg. Voor de voorbereiding was ze sowieso een afleiding: het verschil tussen zes en tien weken verandert niets aan wat u moet kunnen aantonen.

Wat geldt er vanaf de inwerkingtreding?

Zodra de wet in werking treedt, gelden voor entiteiten die eronder vallen vijf verplichtingen. Ze gaan niet gefaseerd in — ze gelden vanaf dag één.

1. Registratie bij het NCSC. Entiteiten die onder de wet vallen, melden zich aan bij het Nationaal Cyber Security Centrum. De eerste stap is dus vaststellen of u een essentiële of belangrijke entiteit bent; die indeling bepaalt onder welke toezichthouder u valt.
2. Zorgplicht. U neemt passende en evenredige maatregelen om uw netwerk- en informatiesystemen te beveiligen — de kern van Artikel 21. Dit is geen checklist die u eenmalig afvinkt, maar een doorlopende verplichting die u moet kunnen aantonen.
3. Meldplicht. Een significant incident meldt u in fasen: een vroege waarschuwing binnen 24 uur, een melding binnen 72 uur en een eindrapport binnen een maand. Hoe u die termijnen in een Azure-omgeving haalbaar maakt, staat in NIS2-meldplicht voor Azure-omgevingen.
4. Aantoonbare bestuurderskennis. Bestuurders moeten gedocumenteerde kennis van cyberrisico’s kunnen tonen en zijn verantwoordelijk voor het goedkeuren en toezien op de maatregelen. “Ik begreep de techniek niet” houdt op een verdediging te zijn.
5. Ketenrisicobeheer. U beoordeelt en beheert de risico’s van uw leveranciers en de bredere toeleveringsketen — voor de meeste Nederlandse organisaties in de praktijk een afhankelijkheid van Microsoft en een handvol SaaS-leveranciers.

Verplichtingen 3 tot en met 5 leunen op techniek en processen die u kunt inrichten. Verplichting 2 — en het bewijs dat verplichting 4 van een bestuur verlangt — is waar de meeste Azure-omgevingen tekortschieten, en het is niet waar de scanners naar wijzen.

Waarom de tijd tot 15 augustus krap is, en waar die naartoe moet

De verleiding is om de zorgplicht te beantwoorden met een document. Een goed beleidsstuk, netjes opgemaakt, ondertekend door iemand met een titel, opgeslagen op een plek die iedereen kan vinden en niemand opent. In de weken die resten is dat te doen.

Het is alleen niet wat de zorgplicht vraagt. Een document is een claim over hoe iets hoort te zijn. De zorgplicht gaat over hoe uw Azure- en Microsoft 365-omgeving er nú bij staat — inclusief het opslagaccount dat iemand “even voor een test” opende in oktober en dat sindsdien infrastructuur is geworden. Het onderscheid dat telt is dat tussen intentie en bewijs. Een toezichthouder is de eerste stilzwijgend gestopt met accepteren als bewijs voor de tweede.

Dat is precies waar een kwetsbaarhedenscan ophoudt. Een SAST-, DAST- en SBOM-stack vertelt u welke fouten in code en containers zitten. Die heeft u nodig; het hoort bij Artikel 21. Maar het is geen architectuurbewijs. Het zegt een bestuur niets over de vraag of het ontwerp — de segmentatie, het weerbaarheidsmodel, de concentratie van derde-partijrisico, de hersteldoelstellingen — een zorgplichtniveau haalt. En het produceert niet wat een auditor of een nieuw aansprakelijke bestuurder werkelijk opvraagt: gestructureerd, actueel bewijs dat architectuurrisico is beoordeeld en beheerst.

In de resterende weken kunt u geen documentatie terugschrijven die waar is. Wat u wél kunt, is controleren of uw omgeving al aan een zorgplichtnorm voldoet, en het gat vastleggen waar dat niet zo is. Dat is het verschil tussen op 15 augustus een claim hebben en bewijs hebben.

Wat u nu doet

• Stel uw indeling vast. Bent u een essentiële of belangrijke entiteit, en onder welke sectortoezichthouder valt u? Daar hangt de registratie én de meldbestemming aan vast.
• Meet uw architectuur tegen NIS2, niet tegen een vragenlijst. Beoordeel segmentatie, identiteit, logging, weerbaarheid en derde-partijconcentratie tegen de zorgplicht — en leg de uitkomst vast als bewijs, niet als voornemen. De Azure-architectuur governance-checklist is een bruikbaar startpunt.
• Controleer of uw meldketen de 24-uursklok haalt voordat een incident dat voor u doet. Zie NIS2-meldplicht voor Azure.
• Geef het bestuur iets aantoonbaars in handen. De kennisverplichting is persoonlijk en niet-delegeerbaar; een scanrapport dekt die niet, een architectuurbeoordeling gemapt op NIS2 wel.

Hoe PAA hierbij past

Dit is waar bewijs schoon produceren ophoudt een tooling-oefening te zijn en een assessment-oefening wordt. Platform Architecture Authority (PAA) leest uw Microsoft Azure- en Microsoft 365-configuratie, zet de gaten af tegen de NIS2-verplichtingen — inclusief de vraag of uw ontwerp een zorgplichtniveau haalt — en genereert vervolgens de herstelcode die u toepast. Het vervangt niet de architect die beslist welke bevindingen er voor deze organisatie toe doen; het zorgt dat het bewijs al bestaat voordat een toezichthouder erom vraagt. PAA is alleen-lezen.

De eerlijke vraag voor de bestuurders die dit lezen: als u dit kwartaal moest aantonen dat uw Azure-architectuur een zorgplichtniveau haalt — kon u dat bewijs op tafel leggen? Geen scan. De architectuur.

Veelgestelde vragen

Wanneer treedt de Cyberbeveiligingswet in werking?

Op 15 augustus 2026. De Rijksoverheid bevestigde deze datum op 7 juli 2026, samen met de inwerkingtreding van de Wet weerbaarheid kritieke entiteiten op dezelfde dag. De datum is eerder verschoven van 1 juli, maar is nu vast.

Wat is het verschil tussen de Cyberbeveiligingswet en de Wwke?

De Cyberbeveiligingswet implementeert de NIS2-richtlijn en richt zich op digitale weerbaarheid: risicobeheer, meldplicht en zorgplicht voor netwerk- en informatiesystemen. De Wet weerbaarheid kritieke entiteiten implementeert de CER-richtlijn en richt zich op de bredere, ook fysieke weerbaarheid van formeel aangewezen kritieke entiteiten. Een organisatie kan onder beide vallen.

Welke verplichtingen gelden er vanaf de inwerkingtreding?

Vijf, en ze gaan tegelijk in: registratie bij het NCSC, een zorgplicht, een meldplicht voor significante incidenten, aantoonbare cyberkennis op bestuursniveau, en risicobeheer van leveranciers en de toeleveringsketen.

Waarom is een kwetsbaarhedenscan niet genoeg voor de zorgplicht?

Een SAST/DAST/SBOM-stack toont welke fouten in code en containers zitten — noodzakelijk en onderdeel van Artikel 21 — maar geen architectuurbewijs. Het toont niet of het ontwerp (segmentatie, weerbaarheid, derde-partijconcentratie, hersteldoelstellingen) een zorgplichtniveau haalt, en dat is wat een bestuur of auditor opvraagt.

Wat kan een organisatie in de resterende weken realistisch doen?

Geen sluitende documentatie terugschrijven, wél controleren of de omgeving al aan een zorgplichtnorm voldoet en het gat vastleggen. Stel uw entiteitsindeling vast, beoordeel de architectuur tegen NIS2 in plaats van tegen een vragenlijst, en geef het bestuur aantoonbaar bewijs in handen in plaats van een voornemen.