Cyberbeveiligingswet: wat je klanten van jou als softwareleverancier mogen vragen

· Yunus Yildiz

Het korte antwoord

De Cyberbeveiligingswet (Cbw) is op 15 augustus 2026 in werking getreden, zonder overgangsperiode. Ruim 8.000 Nederlandse organisaties in 18 sectoren vallen eronder.

Als je software levert aan zo'n organisatie, geldt voor jou het volgende:

  • De wet legt jou geen directe verplichtingen op. Het NCSC is er expliciet over: "een toezichthouder zal geen toezicht houden op toeleveranciers".
  • Je klant heeft wel een zorgplicht, en die omvat de toeleveringsketen. "Maak je toeleveringsketen veilig" is een van de tien zorgplichtmaatregelen.
  • Dus bereikt de verplichting jou langs de contractuele weg. Niet als wet, maar als eis in een overeenkomst en als vragenlijst.

Dat verschil is belangrijk. Je hoeft je niet te registreren of te melden omdat je toeleverancier bent. Maar je moet wel kunnen antwoorden.

Wat je klant mag eisen

Het NCSC beschrijft wanneer een Cbw-organisatie eisen aan jou mag stellen: als je diensten of producten levert die verband houden met haar netwerk- en informatiesystemen, als je ICT-componenten voor die systemen levert, of als je toegang hebt tot die systemen. Voor de meeste softwareleveranciers geldt minstens één daarvan.

De eisen zelf worden omschreven als "passende en evenredige technische, operationele en organisatorische maatregelen". Dat is dezelfde formulering die de wet voor de organisatie zelf gebruikt, doorgegeven aan de keten.

Twee dingen volgen daaruit, en ze zijn allebei lastiger dan ze klinken.

Het is risicogebaseerd, dus per klant anders. Er is geen vaste lijst. Wat "passend" is hangt af van wat jij levert en hoe afhankelijk die klant ervan is. Een logtool en een component in het primaire proces krijgen niet dezelfde vragen.

Er is geen certificaat dat de discussie beëindigt. Het NCSC noemt ISO 27001, NIS2 Supply Chain en CYRA als mogelijke kaders, maar stelt er direct bij dat ze niet verplicht zijn en geen garantie geven. Een certificaat helpt, maar je klant moet nog steeds beoordelen of jouw maatregelen passend zijn voor haar risico.

Achter de Nederlandse wet ligt de NIS2-richtlijn. Artikel 21(2)(d) noemt de beveiliging van de toeleveringsketen, inclusief de relaties met directe leveranciers en dienstverleners. Artikel 21(3) gaat nog een stap verder: bij de beoordeling van wat passend is, moet de entiteit rekening houden met de kwetsbaarheden die specifiek zijn voor elke directe leverancier, en met de algehele kwaliteit van de producten en de cyberbeveiligingspraktijken van die leverancier, inclusief de veilige-ontwikkelingsprocedures.

Die laatste zinsnede is de reden dat de vragen technisch worden. Je klant moet iets kunnen vinden over hoe jij bouwt, niet alleen over wat je belooft.

Wat er in de praktijk gevraagd wordt

De vragen verschillen per klant, maar ze komen neer op vier dingen die je over een specifieke release moet kunnen aantonen:

  1. Wat zit erin. Welke componenten van derden bevat deze versie? Dit is de SBOM-vraag, ook als het woord SBOM er niet in staat.
  2. Wat weet je over de zwakke plekken. Is deze versie gescand, wat kwam eruit, en wat doe je met wat er niet is opgelost?
  3. Hoe weet ik dat dit jouw artefact is. Ondertekening en herkomst: kan de klant verifiëren dat het binaire bestand dat zij draait van jou komt en onderweg niet is gewijzigd?
  4. Wat gebeurt er als het misgaat. Binnen welke termijn meld je een kwetsbaarheid of incident aan je klant, en via welk kanaal? Het NCSC adviseert dit soort afspraken vast te leggen in de SLA.

Het NCSC adviseert toeleveranciers verder om een zelfevaluatie van de eigen weerbaarheid te doen en vroeg met hun Cbw-klanten in gesprek te gaan over ketenrisico's, in plaats van te wachten tot de eerste vragenlijst binnenkomt.

Het probleem is niet het antwoord, maar de herhaling

Eén klant die om je SBOM en je patchbeleid vraagt, is een middag werk. Vijftien klanten die er elk in hun eigen format naar vragen, elk kwartaal, is werk dat niet meer bij iemand past.

Daar zit de echte verandering. Niet in de vraag of je kunt voldoen, maar of je het bewijs twee keer kunt produceren zonder het opnieuw te verzamelen. Teams die hier goed doorheen komen, hebben het bewijs aan de release gekoppeld in plaats van aan de vragenlijst: per versie een SBOM, een scanresultaat, een handtekening en een spoor van wie wat wanneer heeft vrijgegeven. De vragenlijst wordt dan een export, geen project.

Val je zelf onder de Cbw?

Dit wordt vaak te snel afgedaan. De Cbw kijkt naar sector en omvang, niet naar of je jezelf als "kritieke infrastructuur" ziet. Aanbieders van bijvoorbeeld clouddiensten, datacenterdiensten of managed services kunnen zelf onder de wet vallen, ook als ze zichzelf vooral als softwarebedrijf zien.

Het NCSC heeft een pagina om dit te bepalen: valt mijn organisatie onder de Cyberbeveiligingswet?. Val je eronder, dan geldt er wél een registratieplicht: essentiële en belangrijke entiteiten registreren zich in het nationaal entiteitenregister bij het NCSC, via mijn.ncsc.nl met eHerkenning of Single Sign On Rijk. Die plicht geldt sinds de inwerkingtreding op 15 augustus 2026.

Het is dus de moeite waard om dit expliciet te controleren en het antwoord vast te leggen, ook als het "nee" is. Dat is een vraag die in vragenlijsten terugkomt.

Waar dit de CRA raakt

Als je software op de EU-markt brengt, heb je naast de contractuele eisen van je klanten een eigen verplichting: de Cyber Resilience Act. Die is geen contract maar wetgeving die rechtstreeks voor jou als fabrikant geldt.

Sinds 11 september 2026 is artikel 14 van kracht: actief misbruikte kwetsbaarheden en ernstige incidenten moeten binnen 24 uur als vroegtijdige waarschuwing gemeld worden, met een vervolgmelding binnen 72 uur. Wat "op de hoogte zijn" precies betekent, en welke kwetsbaarheden wél en niet gemeld moeten worden, hebben we apart uitgewerkt.

Daarnaast vraagt artikel 13(5) om due diligence op de componenten van derden die je integreert, en vraagt bijlage I om het afhandelen van kwetsbaarheden, inclusief een SBOM.

Dat is geen tweede stapel werk. Het is grotendeels hetzelfde bewijs: wat zit erin, is het gescand, is het ondertekend, wie heeft het vrijgegeven. De CRA vraagt het omdat de wet het eist; je Nederlandse klanten vragen het omdat hun zorgplicht het eist. Wie het één keer goed vastlegt per release, bedient beide.

Precies daarvoor bestaat Eurtifact: elke versie die je binnenhaalt wordt gescand, voorzien van een SBOM, ondertekend en vastgelegd in een controleerbaar logboek, zodat het antwoord op "wat zat er in release 2.4.1" een zoekopdracht is en geen onderzoek. Er draait een demo-omgeving op echte images.

Wat je deze maand kunt doen

  • Controleer of je zelf onder de Cbw valt, en leg het antwoord vast.
  • Inventariseer welke van je klanten Cbw-entiteiten zijn. Zij gaan vragen stellen; de wet geldt al.
  • Kies per release één plek waar SBOM, scanresultaat, handtekening en vrijgave samenkomen.
  • Leg meldingstermijnen richting klanten vast in de SLA, voordat de eerste klant zijn eigen termijn voorstelt.
  • Beantwoord de eerstvolgende vragenlijst zó dat het antwoord herbruikbaar is.

Bronnen

Dit artikel geeft de lezing van het Eurtifact-team weer, gecontroleerd tegen de hierboven genoemde bronnen op 18 september 2026. Het is geen juridisch advies. Laat je eigen positie onder de Cbw en de CRA beoordelen door een jurist.