Cyberbeveiligingswet: eisen die uw opdrachtgever doorschuift

Introductie

Op 7 juli 2026 stemde de Eerste Kamer in met de Cyberbeveiligingswet, de Nederlandse uitwerking van de Europese NIS2-richtlijn. De wet treedt op 15 augustus 2026 in werking en raakt naar schatting ruim achtduizend Nederlandse organisaties direct: van energiebedrijven en ziekenhuizen tot transporteurs, datacenters en grotere maakbedrijven. Zij krijgen een zorgplicht, een registratieplicht en een meldplicht voor ernstige incidenten.

Over wat dat betekent voor softwarebedrijven die zelf onder de wet vallen schreven wij eerder in ons artikel over NIS2 en softwareleveranciers. Dit artikel gaat over de andere kant, en die raakt veel meer bedrijven: uw opdrachtgever valt onder de wet en schuift de eisen via contracten, vragenlijsten en audits door naar u. Ook als uw bedrijf zelf nergens in een bijlage van de wet voorkomt, wordt beveiliging vanaf deze zomer een leveringsvoorwaarde. Wij zien dat nu al gebeuren bij onze eigen klanten in Haarlem en omstreken, en dit is wat u kunt verwachten.

Wat er op 15 augustus verandert, in het kort

De Cyberbeveiligingswet legt organisaties in achttien sectoren drie kernverplichtingen op. De zorgplicht: passende technische en organisatorische maatregelen nemen om netwerk- en informatiesystemen te beveiligen, inclusief de beveiliging van de toeleveringsketen. De registratieplicht: zich registreren in het entiteitenregister bij het NCSC. En de meldplicht: ernstige incidenten binnen 24 uur na ontdekking melden bij het CSIRT, met een vervolgmelding en eindrapportage daarna.

Voor bestuurders is de wet persoonlijk: zij moeten de maatregelen goedkeuren, toezien op de uitvoering en zijn verplicht een opleiding over cyberrisico's te volgen. Dat verklaart waarom het onderwerp ineens op directietafels ligt en niet meer alleen bij de IT-afdeling. Een bestuurder die persoonlijk aanspreekbaar is op de keten, gaat die keten controleren.

Het woord dat voor leveranciers alles verandert is "keten". De zorgplicht omvat expliciet de risico's die via leveranciers en dienstverleners binnenkomen. Een ziekenhuis, vervoerder of energiebedrijf kan zijn eigen systemen nog zo goed op orde hebben; als het maatwerkportaal van een externe bouwer een lek heeft, is dat onder de wet hún probleem. Dus maken zij het contractueel úw probleem.

Zo komt de wet bij u binnen: vragenlijst, contract, audit

De doorwerking naar leveranciers volgt vrijwel altijd hetzelfde patroon. Eerst komt de leveranciersvragenlijst: een spreadsheet of portaalformulier met dertig tot honderdvijftig vragen over uw beveiligingsmaatregelen, vaak gebaseerd op ISO 27001 of de NIS2-maatregelencatalogus. Daarna volgt een contractbijlage of addendum bij de bestaande overeenkomst, met beveiligingseisen, meldtermijnen en auditrechten. En bij grotere of langlopende relaties volgt uiteindelijk de audit zelf: een verzoek om bewijs, een gesprek met uw ontwikkelaars of een externe toets.

Bij een van onze klanten, een toeleverancier van een logistiek bedrijf dat onder de wet valt, kwam dit voorjaar precies deze volgorde voorbij. Eerst een vragenlijst met 92 vragen, waarvan er zeker twintig over het klantportaal gingen dat wij voor hen hadden gebouwd: hoe is de toegang beveiligd, wie kan bij welke data, hoe lang worden logs bewaard, hoe snel worden kwetsbaarheden gepatcht. Omdat we die antwoorden uit de bestaande documentatie en logging konden halen, was de lijst in twee middagen ingevuld. Het alternatief, achteraf reconstrueren hoe een systeem in elkaar zit, kost weken.

Belangrijk om te beseffen: u kunt deze vragenlijsten niet straffeloos negeren of te rooskleurig invullen. De antwoorden worden onderdeel van het contractdossier van uw opdrachtgever. Blijkt bij een incident dat uw werkelijke situatie afwijkt van wat u heeft opgegeven, dan heeft u een contractueel probleem bovenop het technische. Eerlijk antwoorden, inclusief "dat hebben wij nog niet geregeld, dit is ons plan", is vrijwel altijd de betere strategie.

De zes technische eisen die in elke vragenlijst terugkomen

Meerfactorauthenticatie staat bovenaan. Opdrachtgevers verwachten MFA op alle beheertoegangen en steeds vaker ook voor eindgebruikers van portalen die bedrijfsdata ontsluiten. Direct daarna komt autorisatie: kan uw software rollen en rechten fijnmazig toekennen, oftewel rolgebaseerde toegang (RBAC)? Een portaal waarin elke ingelogde gebruiker alles ziet, komt door geen enkele beoordeling meer.

Logging en monitoring vormen het derde blok. Wie heeft wanneer ingelogd, wat is er gewijzigd, welke data is geëxporteerd? Opdrachtgevers vragen om centrale, onweerlegbare logging met een bewaartermijn, meestal minimaal twaalf maanden, juist omdat zij die logs nodig hebben voor hun eigen meldplicht. Het vierde blok is versleuteling: data onderweg via TLS is inmiddels vanzelfsprekend, maar ook versleuteling van data in rust, van back-ups en van gevoelige velden in de database wordt standaard uitgevraagd.

Blok vijf is patchbeleid. Hoe snel verwerkt u beveiligingsupdates in afhankelijkheden en frameworks, en kunt u dat aantonen? Na incidenten zoals het wp2shell-lek in WordPress vragen opdrachtgevers expliciet naar de onderhoudsstatus van alles wat aan hun data raakt. En blok zes is incidentrespons: heeft u een beschreven proces, een aanspreekpunt en een hersteltijd? Wie deze zes onderwerpen op orde heeft, haalt het overgrote deel van elke leveranciersbeoordeling.

Incidentmelding en SLA's: de nieuwe contractstandaard

De meldplicht van uw opdrachtgever tikt in uren: een vroege waarschuwing aan het CSIRT binnen 24 uur na ontdekking van een ernstig incident. Dat halen zij alleen als hun leveranciers minstens zo snel doorgeven wat er speelt. Verwacht daarom contractclausules met een doorgeefplicht van 24 uur of korter voor incidenten die de dienstverlening van de opdrachtgever raken, inclusief de plicht om mee te werken aan het onderzoek en aan de vervolgrapportages.

Teken zo'n clausule niet blind. Let op drie dingen. Ten eerste de definitie van "incident": die moet gaan over daadwerkelijke of waarschijnlijke impact op de dienstverlening van de opdrachtgever, niet over elke mislukte inlogpoging in uw logboek. Ten tweede het startmoment: de termijn hoort te lopen vanaf het moment dat ú het incident ontdekt, niet vanaf het moment dat het plaatsvond. Ten derde de aansprakelijkheid: een meldtermijn toezeggen is redelijk, ongelimiteerde aansprakelijkheid voor alle ketenschade is dat niet.

Onze ervaring is dat opdrachtgevers hier goed mee om te praten zijn, omdat hun juristen dezelfde clausules bij tientallen leveranciers moeten wegzetten en gebaat zijn bij werkbare afspraken. Wat niet onderhandelbaar is: dat u een werkend incidentproces hebt. Een contactpersoon, een escalatiepad, en de technische mogelijkheid om binnen een dag te zien wat er is gebeurd. Dat laatste brengt ons bij de rol van de software zelf.

Hoe maatwerksoftware compliance aantoonbaar maakt

"De vragenlijst van je grootste klant is vanaf nu net zo bepalend voor je software-architectuur als je eigen wensenlijst. Wie logging, rollen en patchbeleid pas regelt als de audit komt, is te laat."

— Sidney de Geus, co-founder MG Software

Er is een wezenlijk verschil tussen veilig zíjn en veilig kunnen aantónen. Voor de vragenlijsten en audits van uw opdrachtgevers telt vooral het tweede, en daar heeft goed gebouwde maatwerksoftware een structureel voordeel. In een maatwerkportaal of dashboard bepaalt u zelf welke gebeurtenissen worden gelogd, hoe rollen zijn opgebouwd en welke rapportages er bestaan. Aantoonbaarheid is dan een exportknop, geen archeologisch project.

Concreet bouwen wij bij MG Software in beveiligingsgevoelige projecten standaard vier dingen in die audits vrijwel geruisloos maken: een audittrail van alle wijzigingen en toegangen, een rechtenoverzicht dat per rol laat zien wie wat kan, geautomatiseerde afhankelijkheidsupdates via de CI-pijplijn met een logboek van doorgevoerde patches, en MFA plus sessiebeheer op alle toegangen. Voor een opdrachtgever die onder de Cyberbeveiligingswet valt, is zo'n systeem geen risicopost in de keten maar juist een bewijsstuk.

Het spiegelbeeld geldt ook. Verouderde maatwerksystemen, gebouwd in een tijd dat niemand om logging of MFA vroeg, worden onder de wet een blok aan het been. Wij zien opdrachtgevers inmiddels expliciet vragen naar de levenscyclus van software: welk framework, welke versie, wordt die nog onderhouden? Draait er bij u een kritisch systeem op een framework dat einde levensduur is, dan is herontwikkeling van die software geen luxe meer maar de voorwaarde om bepaalde klanten te mogen blijven bedienen.

Een praktisch stappenplan voor de komende maanden

Begin bij uw klantenlijst, niet bij uw techniek. Welke opdrachtgevers vallen vermoedelijk onder de wet? De sectoren staan op de site van het NCSC, dat ook een zelfevaluatietool aanbiedt. Elke klant in energie, zorg, transport, digitale infrastructuur, industrie of overheid is een kandidaat om u dit najaar een vragenlijst te sturen. Voor die klanten inventariseert u welke systemen en diensten u levert en welke data u daarbij verwerkt.

Leg vervolgens uw eigen basis vast, voordat de eerste vragenlijst binnenkomt. Documenteer per systeem hoe authenticatie en autorisatie werken, wat er wordt gelogd, hoe back-ups en versleuteling zijn geregeld en hoe het patchproces loopt. Schrijf uw incidentproces uit op één A4: wie ontdekt, wie beslist, wie meldt aan de klant, binnen welke termijn. Dit document is de helft van elk vragenlijstantwoord dat u de komende jaren gaat geven.

Sluit af met de gaten. Meestal zijn dat er drie: ontbrekende MFA op oudere systemen, logging die wel bestaat maar niet centraal doorzoekbaar is, en een verouderd systeem waarvan iedereen weet dat het eigenlijk vervangen moet worden. Voor dat laatste hoeft niet alles in één keer: een herbouw in fasen, te beginnen met de toegangslaag en de logging, maakt u vaak al binnen enkele maanden auditwaardig. Hoe u zo'n traject vastlegt voordat u gaat bouwen, leest u in onze functioneel ontwerp template.

Conclusie

De Cyberbeveiligingswet is vanaf 15 augustus 2026 een feit, en de invloed ervan stopt niet bij de ruim achtduizend organisaties die zich bij het NCSC moeten registreren. Via zorgplicht en ketenverantwoordelijkheid wordt de wet de facto de beveiligingsstandaard voor iedereen die aan die organisaties levert. De leveranciers die daar het minst last van krijgen, zijn degenen die MFA, rollen, logging, versleuteling, patchbeleid en een incidentproces nu al kunnen aantonen.

Levert u aan bedrijven die onder de wet vallen en wilt u weten waar uw software staat? Neem contact op voor een nuchtere doorlichting. En is de conclusie dat een kritisch systeem aan vervanging toe is, dan rekent onze calculator binnen twee minuten een eerste bandbreedte voor u door.