De Cyberbeveiligingswet legt ketenverantwoordelijkheid neer bij organisaties die die keten in de praktijk niet kunnen afdwingen. Dit artikel gaat over waarom dat zo is, wat het betekent voor de sectoren waar die spanning het scherpst voelbaar is, en wat er structureel anders moet.

Het NCSC is helder: een toezichthouder houdt geen toezicht op toeleveranciers. Geen audits, geen boetes, geen directe handhaving. De verantwoordelijkheid voor ketenbeveiliging ligt volledig bij de Cbw-organisatie.

Tegelijkertijd geldt: als die organisatie via een leverancier wordt getroffen, betaalt zij — in boetes tot €10 miljoen, in persoonlijke aansprakelijkheid van het bestuur, en in het risico op een tijdelijk verbod op het uitoefenen van bestuurlijke functies.

Dat is geen interpretatie van de wet. Het is de architectuur ervan. En het is precies de architectuur die niet werkt in de sectoren waar ketenrisico het grootst is.

Een wet die al achterloopt voordat ze in werking treedt

Nederland had de Europese omzettingsdeadline van 17 oktober 2024 niet gehaald. Het wetsvoorstel voor de Cyberbeveiligingswet werd pas op 4 juni 2025 ingediend bij de Tweede Kamer — ruim zeven maanden te laat. De inwerkingtreding wordt nu verwacht in het tweede kwartaal van 2026, afhankelijk van de parlementaire behandeling.

Die vertraging is op zichzelf een beleidsmatig signaal. Maar de urgentie van de onderliggende problematiek heeft niet gewacht op de wetgever. ENISA registreerde een viervoudige toename van supply chain-aanvallen in 2025. Verizon stelde vast dat 29% van datalekken een derde partij betreft. IBM schatte de gemiddelde kosten van een supply chain-inbreuk op 4,45 miljoen dollar. De dreiging die de Cyberbeveiligingswet beoogt te adresseren, manifesteert zich nu — in organisaties die nog steeds opereren onder de Wet beveiliging netwerk- en informatiesystemen (Wbni) en zonder de instrumenten die de nieuwe wet belooft.

Voor de circa 8.000 organisaties die naar verwachting onder de Cbw zullen vallen, is de boodschap van de overheid helder: wacht niet op inwerkingtreding. De risico’s zijn er immers nu ook al. Dat is een juist advies. Maar het negeert een fundamentele vraag: wat kunnen die organisaties realistisch afdwingen bij hun leveranciers, zolang die leveranciers zelf geen wettelijke plicht hebben?

Wat de wet vereist — en wat ze aanneemt

Artikel 21(2)(d) van NIS2, en daarmee de zorgplicht in de Cyberbeveiligingswet, verplicht essentiële en belangrijke entiteiten tot het adresseren van ketenbeveiliging, inclusief de beveiligingsaspecten die verband houden met de relaties met directe leveranciers en dienstverleners. Het Cyberbeveiligingsbesluit (Cbb) werkt dit nader uit. Artikel 20 legt de bestuurlijke verantwoordelijkheid vast: het bestuur moet de maatregelen goedkeuren, toezien op de uitvoering, en kan persoonlijk aansprakelijk worden gesteld bij grove nalatigheid.

Voor essentiële entiteiten kunnen boetes oplopen tot €10 miljoen of 2% van de wereldwijde jaaromzet, afhankelijk van wat hoger is. Voor belangrijke entiteiten geldt een maximum van €7 miljoen of 1,4% van de omzet. In ernstige gevallen kunnen bestuurders tijdelijk worden uitgesloten van hun functie.

De intentie is duidelijk: ketenbeveiliging is een governanceverplichting, geen technische bijzaak. Het mechanisme waarmee die intentie wordt gerealiseerd, is contractuele druk op leveranciers — via auditrechten, beveiligingseisen in overeenkomsten en aantoonbaarheid van genomen maatregelen.

Dit mechanisme rust op één aanname: dat Cbw-organisaties voldoende marktmacht hebben om die eisen af te dwingen. In veel van de omgevingen waarop de wet zich het meest richt, is die aanname onjuist.

De aanname die niet opgaat

Neem een realistisch scenario: een regionale drinkwaterbeheerder die afhankelijk is van één leverancier van industriële besturingssystemen voor de aansturing van zijn zuiveringsinstallaties. Het systeem is al jaren in gebruik. Vervanging kost tien jaar en honderd miljoen euro, en brengt operationeel risico met zich mee tijdens de transitie. De leverancier weigert diepgaande beveiligingsaudits en verstrekt beperkte informatie over kwetsbaarheden.

Onder de Cyberbeveiligingswet is de drinkwaterbeheerder volledig verantwoordelijk voor het beheersen van dat risico. In de praktijk kan hij dat niet.

Dit is geen randgeval. Onderzoek toont consistent aan dat 85% van de organisaties hun OT-omgevingen niet regelmatig patcht, en dat 98% van IT-beveiligingsincidenten ook impact heeft op OT-systemen. De structurele voorwaarden die leveranciersafhankelijkheid intractabel maken — lange systeemlevenscycli, gespecialiseerde markten, hoge overstapkosten — zijn endemisch in de sectoren waar de Cbw het meest dringend van toepassing is: energie, drinkwater, transport, digitale infrastructuur.

Het NCSC erkent dit impliciet. Op de eigen website staat dat het beveiligen van de keten “vaak leidt tot een maatwerkpakket van eisen per toeleverancier” en dat een certificaat of keurmerk “geen garantie biedt dat het geïnventariseerde ketenrisico daadwerkelijk hiermee afgedekt is.” Met andere woorden: de wet verwacht maatwerk waar de markt standaardisatie nog niet biedt, en verwacht afdwingbaarheid waar het toezicht ophoudt.

Een ontwerpkeuze, geen omissie

Het ontbreken van directe verplichtingen voor leveranciers is geen implementatiefout. Het is een bewuste architectuurkeuze die teruggaat tot het oorspronkelijke Commissievoorstel van december 2020.

Het toenmalige artikel 18 van COM(2020) 823 legde de volledige last bij de essentiële en belangrijke entiteiten: zij moesten de kwetsbaarheden van hun leveranciers beoordelen, de kwaliteit van hun beveiligingspraktijken evalueren en maatregelen treffen. Leveranciers hadden geen enkele verplichting om informatie aan te leveren, audits te faciliteren of minimumnormen te handhaven. Die structuur is ongewijzigd overgenomen in de definitieve richtlijn van 2022.

Het enige mechanisme dat de richtlijn biedt om leveranciers te bewegen tot medewerking, is contractuele druk. De Uitvoeringsverordening van de Commissie (C(2024)7151), die per 17 oktober 2024 rechtstreeks van toepassing werd, geeft nadere invulling aan wat die contractuele bepalingen zouden moeten bevatten — auditrechten, beveiligingseisen, meldplichten. Maar de grondslag blijft onderhandelingsvrijheid, niet wettelijke verplichting.

De consequentie is dat de wet een commercieel probleem behandelt als een juridisch probleem. Praktijkcommentaar van DLA Piper formuleert het zo: organisaties worden geconfronteerd met de uitdaging contracten te wijzigen met grote ICT-leveranciers die een sterke marktpositie innemen — en als leveranciers weigeren mee te werken, moeten entiteiten risico’s via andere maatregelen afdekken of, waar mogelijk, gebruik maken van opzeggingsrechten. Dat is leveranciersmanagement als vangnet voor een handhavingstekort.

Een bijzonder scherp randgeval is open source software. NLnet Labs wees er tijdens de publieke consultatie over de Uitvoeringsverordening op dat de contractuele aanpak van ketenbeveiliging berust op de aanname dat aanbieders individueel onderhandelbare contracten hebben met al hun leveranciers — een aanname die niet opgaat bij open source-afhankelijkheden, waarbij de relatie tussen ontwikkelaar en NIS2-entiteit juridisch schlicht niet bestaat. Er is geen contract te sluiten, en dus ook geen verplichting af te dwingen.

Wat opvalt is niet alleen wat er wél over dit onderwerp geschreven is, maar wat er niet in staat. Het bestaande commentaar — van juridische praktijk tot toezichthouders — accepteert het contractuele model doorgaans als gegeven en richt zich op de vraag hoe het beter kan worden ingericht. De vraag of de architectuur van de verplichting zelf correct is ontworpen, wordt nauwelijks gesteld.

Dat is de vraag die hier wél gesteld wordt.

Het probleem loopt in twee richtingen

Het governance-hiaat wordt doorgaans vanuit één perspectief geframed: Cbw-organisaties die worstelen met hun ketenverantwoordelijkheid. Dat beeld is juist, maar onvolledig.

Naarmate essentiële en belangrijke entiteiten worden aangespoord hun ketenrisico te beheersen, vertalen zij die verwachtingen door naar hun leveranciers — via contracten, inkoopeisen en beveiligingsvragenlijsten. IT-dienstverleners, ingenieursbureaus, advocatenkantoren, softwareleveranciers en andere organisaties die aan gereguleerde entiteiten leveren, worden in toenemende mate gevraagd hun beveiliging aan te tonen. Niet omdat zij zelf onder de Cbw vallen, maar omdat hun opdrachtgevers dat doen.

Voor veel van deze leveranciers ziet de praktijk er zo uit: verschillende opdrachtgevers stellen verschillende vragen in verschillende formats, herhaalde vragenlijsten zonder coherente standaard, onduidelijkheid over wat nu precies vereist is, en tijd die weglekt van de kernactiviteit naar het beantwoorden van verzoeken die los van elkaar staan.

Dit creëert een disfunctioneel patroon door het hele systeem. Cbw-organisaties investeren aanzienlijke inspanning in het beheersen van ketenrisico, maar winnen beperkt vertrouwen in het resultaat. Leveranciers investeren aanzienlijke inspanning in het beantwoorden van klantvragen, zonder consistente manier om hun beveiliging inzichtelijk te maken. Beide kanten werken harder. Geen van beide boekt resultaat in verhouding tot de inspanning.

Het gevolg is precies wat de Cyberbeveiligingswet beoogt te voorkomen, maar onbedoeld versterkt: vertrouwen dat berust op aanname in plaats van bewijs.

Wat je niet kunt zien, kun je niet beheersen

Op operationeel niveau reduceert het probleem voor Cbw-organisaties tot een zichtbaarheidstekort dat compliance-documentatie alleen niet kan dichten.

Effectief ketenbeheer vereist drie dingen tegelijk. Ten eerste een volledig beeld van het leverancierslandschap — niet alleen de directe leveranciers, maar de geneste afhankelijkheden die verborgen blootstelling creëren. Het cascaderisico zit zelden in de directe relatie; het zit in de gedeelde infrastructuur en diensten die meerdere leveranciers tegelijk ondersteunen. Een enkele gecompromitteerde authenticatieprovider, onzichtbaar voor de Cbw-organisatie, kan haar bereiken via elke leverancier die daarvan afhankelijk is.

Ten tweede een gestructureerde risicoanalyse die niet uitsluitend leunt op auditrechten. Vragenlijsten, dreigingsinformatie en openbaar beschikbare kwetsbaarheidsdata kunnen samen een verdedigbaar risicobeeld opleveren — maar alleen als de onderliggende afhankelijkheidskaart nauwkeurig genoeg is om te weten waar te zoeken.

Ten derde doorlopend toezicht in plaats van periodieke complianceoefeningen. Leveranciersovernames, bekendgemaakte kwetsbaarheden, financiële signalen en geopolitieke ontwikkelingen beïnvloeden het risicoprofiel van leveranciersrelaties sneller dan jaarlijkse reviewcycli kunnen bijhouden.

De meeste organisaties missen momenteel de capaciteit om ook maar één van deze drie dingen op het vereiste detailniveau te doen. Ze kennen hun directe leveranciers. Ze hebben beperkt zicht op wat die leveranciers zelf afhankelijk van zijn. Ze voeren eenmalige beoordelingen uit die verouderd zijn voordat ze worden herzien. En ze hebben geen systematisch mechanisme om te signaleren wanneer een leveranciersrelatie die vorig kwartaal acceptabel was, dit kwartaal een materieel risico is geworden.

Dit is het zichtbaarheidstekort onder het handhavingstekort — en de reden waarom compliance op papier en onbehandeld risico in de praktijk zo frequent naast elkaar bestaan.

Wat de grote incidenten bevestigen

De meest ingrijpende supply chain-aanvallen van het afgelopen decennium delen één kenmerk: de slachtoffers waren niet nalatig. Ze vertrouwden hun leveranciers, en hun leveranciers waren de aanvalsvector.

De SolarWinds-aanval in 2020 trof naar schatting 18.000 organisaties — waaronder overheidsdiensten en kritieke infrastructuurbeheerders — via een gemanipuleerd software-updatekanaal. Aanvallers hielden maandenlang persistente toegang voordat de inbreuk werd ontdekt. Mandiant stelde vervolgens vast dat supply chain-compromittering in 2021 de op één na meest voorkomende initiële infectievector was: 17% van alle inbreuken, vergeleken met minder dan 1% het jaar daarvoor. Geen contractueel auditrecht had dit voorkomen.

NotPetya in 2017, verspreid via gecompromitteerde Oekraïense boekhoudsoftware, bereikte organisaties die geen enkel middel hadden om hun leverancier te dwingen bekende kwetsbaarheden te verhelpen. Stuxnet werd geïntroduceerd via door de leverancier geleverde apparatuur en verspreidde zich naar systemen waar de operators geen enkel zicht op hadden.

Dit zijn geen mislukkingen van organisatorische zorgvuldigheid. Het zijn mislukkingen van een governancemodel dat alle handhavingshefboom plaatst bij de operatoren, terwijl het daadwerkelijke aanvalsoppervlak zich stroomopwaarts bevindt — en grotendeels onzichtbaar is voor de organisaties die er wettelijk verantwoordelijk voor worden gehouden.

Wat er beter moet

De Cyberbeveiligingswet biedt instrumenten die beter gebruikt kunnen worden. Artikel 2(2) van NIS2, en de Nederlandse discretionaire bevoegdheden die daaruit voortvloeien, stellen de overheid in staat de werkingssfeer uit te breiden naar entiteiten buiten de standaardreikwijdte — waaronder de enige aanbieder van een essentiële dienst in Nederland, of entiteiten waarvan de verstoring een systemisch risico zou veroorzaken. Deze bevoegdheden bestaan precies voor geconcentreerde marktomstandigheden. Ze worden nog nauwelijks gebruikt.

Drie aanvullende stappen zijn nodig.

Ten eerste moet het toezicht op de keten verder reiken dan de Cbw-organisatie zelf. Het huidige model — waarbij de toezichthouder beoordeelt of de Cbw-organisatie haar zorgplicht heeft ingevuld, maar de leverancier zelf buiten schot blijft — creëert een handhavingsvacuüm precies waar de grootste risico’s zich bevinden. Minimumvereisten voor leveranciers die essentiële diensten ondersteunen, als voorwaarde voor markttoegang of overheidsaanbesteding, zijn een logische uitbreiding die binnen het bestaande beleidsinstrumentarium past.

Ten tweede moet de Cyber Resilience Act als aanvullend handhavingsinstrument worden ingezet, niet als parallelle compliancetrack. Cbw-organisaties die hun zorgplicht serieus nemen, kunnen CRA-naleving als inkoopeis stellen — en zo regulatoire verplichting aan hun kant omzetten in commerciële druk op leveranciers aan de andere kant. Dit vereist dat beide kaders bewust worden gecoördineerd, niet afzonderlijk worden behandeld.

Ten derde moet het NCSC zijn rol als kenniscentrum voor ketenrisico verder uitbouwen. De huidige NCSC-richtlijnen voor leveranciersrelaties zijn nuttig maar beperkt. Wat ontbreekt is sectorspecifieke ondersteuning bij het in kaart brengen van afhankelijkheden — met name in OT-omgevingen waar de marktconcentratie het hoogst is en de overstapkosten het grootst. Een actievere rol van het NCSC bij het faciliteren van sectorale informatiedeling over leveranciersrisico’s, vergelijkbaar met de bestaande ISAC-structuren, zou de informatieasymmetrie substantieel verminderen.

Conclusie: het gat ís het risico

De Cyberbeveiligingswet treedt naar verwachting in werking in het tweede kwartaal van 2026. Tegen die tijd zal de wet al twee jaar achter de Europese deadline aan hebben gelopen. De dreiging heeft niet gewacht.

Wat er in de tussentijd — en daarna — daadwerkelijk verandert, hangt niet primair af van de kwaliteit van de wetgeving. Het hangt af van of organisaties in staat zijn te zien wat ze werkelijk van afhankelijk zijn. Niet wie hun directe leveranciers zijn, maar hoe die leveranciers onderling verbonden zijn, waar risico zich concentreert, en welke relaties zijn veranderd sinds de laatste keer dat iemand heeft gekeken.

Dat is geen compliancevraag. Het is een zichtbaarheidsvraag. En zolang de wet die zichtbaarheid niet afdwingt bij de leveranciers zelf, is het de organisaties die die zichtbaarheid zelf opbouwen die het verschil maken — niet tussen compliant en niet-compliant, maar tussen een incident dat beheerst wordt en een incident dat escaleert.

Het mechanisme is onvolledig. Het gat is het risico. En de organisaties en beleidsmakers die dat nu erkennen, zijn degenen die straks niet hoeven uit te leggen waarom ze hebben gewacht.

Bronnen

Regelgeving en officiële documenten

  • NIS2-richtlijn (Richtlijn (EU) 2022/2555), Artikel 20, 21(2)(d), 22 en Overweging 90
  • Oorspronkelijk Commissievoorstel NIS2, COM(2020) 823, Artikel 18
  • Uitvoeringsverordening van de Commissie C(2024)7151 — rechtstreeks van toepassing per 17 oktober 2024
  • Wetsvoorstel Cyberbeveiligingswet (Cbw), ingediend bij de Tweede Kamer op 4 juni 2025
  • Cyberbeveiligingsbesluit (Cbb), concept-AMvB onder de Cyberbeveiligingswet

Nederlandse overheid en toezicht

  • NCSC, De Cyberbeveiligingswet en toeleveranciers — ncsc.nl
  • NCSC, De Cyberbeveiligingswet kan ook gevolgen hebben voor toeleveranciers — ncsc.nl
  • Rijksoverheid, Implementatie NIS2 en CER in Nederland vertraagd — rijksoverheid.nl (oktober 2024)
  • Digitale Overheid, Cyberbeveiligingswet (NIS2-richtlijn) — digitaleoverheid.nl
  • NCTV, Cyberbeveiligingswet — nctv.nl

Praktijkcommentaar

  • DLA Piper, NIS2 supply chain series — over contractuele druk en marktmacht van leveranciers
  • Turing Law, over de contractuele vaagheid van de zorgplicht voor ketenbeveiliging
  • NLnet Labs, publieke consultatiereactie op de Uitvoeringsverordening — over open source-afhankelijkheden en het falen van het contractuele model
  • Holm Security, over de indirecte werking van NIS2 op niet-gereguleerde leveranciers

Dreigingsdata

  • ENISA Threat Landscape 2024 en 2025
  • Verizon Data Breach Investigations Report 2025
  • IBM Cost of a Data Breach Report 2025
  • Mandiant M-Trends 2022 — supply chain compromittering als infectievector