Supply Chain Security: Ketenveiligheid is geen inkoopdossier, maar een bestuurlijke opgave

De Cyberbeveiligingswet en het Cyberbeveiligingsbesluit is op 15 augustus 2026 in werking getreden, zonder overgangsrecht: lopende leverancierscontracten worden vanaf dag één aan de nieuwe zorgplicht gemeten. Organisaties besteden steeds meer uit en houden steeds minder zelf in de hand. Daarmee verschuift het aanvalsoppervlak naar buiten: naar softwarebibliotheken, beheerpartijen, cloudplatformen en logistieke partners. Wie ketenveiligheid nog behandelt als een jaarlijkse leveranciersvragenlijst, mist niet alleen het risico, maar vanaf deze week ook de wet.

Het dreigingsbeeld: de keten is de aanvalsroute

Het Europese agentschap voor cyberbeveiliging ENISA analyseerde in zijn Threat Landscape 2025 bijna 4.900 incidenten (4.875) uit de periode 1 juli 2024 tot 30 juni 2025[1]. Ketenrisico’s vormen daarin 10,6% van de dreigingscategorieën, met als kernconstatering dat aanvallers actief gebruikmaken van indirecte routes via derde partijen en afhankelijkheden[2]. Dat percentage oogt bescheiden, maar frequentie is hier een verkeerde maatstaf: dit is de categorie waarin één inbreuk tientallen organisaties tegelijk raakt.

De ontwikkeling wordt zichtbaar in de incidentcijfers. In het Data Breach Investigations Report 2025 stelt Verizon vast dat de betrokkenheid van een derde partij bij datalekken in één jaar verdubbelde, van 15% naar 30%[3]. In bijna één op de drie inbreuken zit dus een schakel die de getroffen organisatie zelf niet beheert, niet patcht en vaak niet monitort.

Hoe fundamenteel dat is, illustreerde de npm-worm Shai-Hulud. Volgens onderzoekers van Unit 42 compromitteerde de eerste golf in september 2025 honderden softwarepakketten; de tweede golf van begin november 2025 raakte tienduizenden GitHub-repositories, met ruim 25.000 kwaadaardige repositories verspreid over circa 350 accounts[4]. Het aanvalsmodel is verraderlijk eenvoudig: niet de doelorganisatie wordt aangevallen, maar de bouwstenen die zij automatisch vertrouwt. Beheerders van het ecosysteem hebben hun publicatie- en authenticatiebeveiliging daarna aangescherpt[5], maar het onderliggende risico, blind vertrouwen in de toeleveringsketen van software, verdwijnt daarmee niet.

Van goede bedoeling naar wettelijke plicht

Ketenveiligheid is de afgelopen jaren van een volwassenheidsthema naar een normatief kader verschoven. De NIS2-richtlijn verplicht entiteiten expliciet tot “beveiliging van de toeleveringsketen, met inbegrip van veiligheidsgerelateerde aspecten betreffende de relaties tussen elke entiteit en haar directe leveranciers of dienstverleners”[6]. Belangrijker nog is de invulling: bij het bepalen van passende maatregelen moeten organisaties rekening houden met de specifieke kwetsbaarheden van elke directe leverancier, met de algemene kwaliteit van hun producten en cyberbeveiligingspraktijken, inclusief hun veilige ontwikkelprocedures, en met de uitkomsten van gecoördineerde beveiligingsrisicobeoordelingen van kritieke bevoorradingsketens[7]. Dat is een risicogebaseerde opdracht, geen vinkje.

Voor Nederland is die opdracht acuut. De Cyberbeveiligingswet en het Cyberbeveiligingsbesluit gelden sinds 15 augustus 2026 onverkort, ook voor contracten die al lopen[8]. Het NCSC wijst erop dat de wet eisen stelt aan de digitale weerbaarheid van meer dan 8.000 organisaties en dat daarbij onder meer registratieplicht, een zorgplicht, meldplicht bij significante incidenten, aantoonbare cybersecuritykennis bij bestuurders en verplicht risicobeheer van leveranciers en de gehele toeleveringsketen horen[9]. De doorwerking gaat verder dan de wettelijke doelgroep: leveranciers die zelf niet onder de wet vallen, ondervinden indirecte impact zodra hun opdrachtgever eisen aan hun digitale veiligheid gaat stellen[10]. Voor de praktijk is vooral de meldketen bepalend: een vroegtijdige waarschuwing binnen 24 uur, een incidentmelding binnen 72 uur en een eindrapportage binnen een maand, via één meldpunt. Wie met zijn leverancier een meldtermijn van 72 uur afspreekt, kan zijn eigen 24-uurstermijn per definitie niet halen.

Daarnaast schuift de verantwoordelijkheid naar de producent. De Cyber Resilience Act (Verordening (EU) 2024/2847) trad op 10 december 2024 in werking; de meldverplichtingen gelden vanaf 11 september 2026 en de hoofdverplichtingen vanaf 11 december 2027[11]. De verordening definieert de software bill of materials (SBOM) als een formeel overzicht van de componenten en ketenrelaties in de softwareonderdelen van een product, met als doel kwetsbaarheden traceerbaar te maken[12]. Voor de inkooppraktijk is de precieze strekking cruciaal: de CRA verplicht fabrikanten die SBOM op te stellen, ten minste voor de directe afhankelijkheden, en op verzoek aan markttoezichthouders te verstrekken. Een recht op inzage voor de afnemer volgt er niet uit, en publicatie is uitdrukkelijk niet verplicht. Wie een SBOM wil ontvangen, moet dat dus zelf contractueel afdwingen.

In de financiële sector loopt de lijn via DORA, dat sinds 17 januari 2025 van toepassing is[13] en ICT-risico bij derde aanbieders expliciet als integraal onderdeel van het ICT-risicobeheerkader positioneert[14].

Wie het thema breder trekt dan cyber, stuit op dezelfde logica in de fysieke keten. De Critical Raw Materials Act bepaalt dat de EU in 2030 voor geen enkele strategische grondstof meer dan 65% van haar aanbod uit één derde land mag halen[15], naast benchmarks voor eigen winning, verwerking en recycling[16]. Concentratierisico is daarmee ook op Europees niveau een expliciete beleidsgrens geworden.

Pensioenuitvoering als ketenafhankelijk bedrijfsmodel

Voor pensioenfondsen en pensioenuitvoerders krijgt ketenveiligheid een extra dimensie doordat de uitvoering van pensioenregelingen in hoge mate afhankelijk is van externe partijen. Administratieplatformen, vermogensbeheerders, uitkeringsverwerkers, cloudleveranciers, dataproviders en digitale communicatiekanalen vormen samen een complex ecosysteem waarin één verstoring directe gevolgen kan hebben voor deelnemers. De overgang naar het nieuwe pensioenstelsel versterkt die afhankelijkheid verder. Datakwaliteit, individuele pensioenvermogens, digitale deelnemersportalen en geautomatiseerde berekeningen zijn sterk verweven met leveranciersketens. Een incident bij een cruciale dienstverlener raakt daardoor niet alleen de operationele continuïteit, maar kan ook leiden tot fouten in pensioenadministraties, uitgestelde uitkeringen of verlies van vertrouwen onder deelnemers.

Daar komt bij dat veel pensioenorganisaties onder het toezichtskader van DORA vallen of indirect worden geraakt door de eisen die uitvoeringsorganisaties en financiële instellingen aan hun leveranciers stellen. Toezichthouders kijken daarbij niet uitsluitend naar de beveiliging van individuele systemen, maar ook naar de beheersing van afhankelijkheden van derde partijen en concentratierisico’s. De sector kent relatief veel gedeelde dienstverleners die voor meerdere pensioenfondsen tegelijk werken. Dat maakt de impact van een incident potentieel sectorbreed. Voor bestuurders van pensioenfondsen verschuift de vraag daardoor van “is onze leverancier veilig?” naar “wat gebeurt er met onze deelnemers als deze leverancier morgen uitvalt?”. Juist in een sector waarin continuïteit, betrouwbaarheid en maatschappelijk vertrouwen centraal staan, is ketenveiligheid daarom niet alleen een ICT- of uitbestedingsvraagstuk, maar nadrukkelijk een onderdeel van het integraal risicobeheer en de fiduciaire verantwoordelijkheid van het bestuur.

Waarom klassiek leveranciersbeheer tekortschiet

In de praktijk struikelt ketenveiligheid zelden op onwil, maar op een verkeerd ingericht proces. Vijf terugkerende tekortkomingen:

• Momentopname in plaats van monitoring. Een jaarlijkse vragenlijst zegt niets over het beveiligingsniveau van een leverancier op de dag van het incident.
• Alleen contractpartijen in beeld. Het risico zit vaak bij de onderaannemer, de opensourcecomponent of het beheeraccount met verhoogde rechten.
• Geen componentinzicht. Zonder actueel overzicht van softwarecomponenten kan niemand binnen een dag zeggen welke systemen een kwetsbare bibliotheek bevatten.
• Geen exit- en herstelscenario. Beheersmaatregelen richten zich op preventie, terwijl de bestuurlijke pijn zit in uitval, herstel en communicatie.
• Assurance zonder controle op de reikwijdte. Een Assurancerapport of ISO 27001-certificaat zegt niets als de afgenomen dienst buiten de scope of buiten de verklaring van toepasselijkheid valt. In de praktijk is dit de hardnekkigste blinde vlek: het Assurancerapport of certificaat wordt gelezen als geruststelling, niet als document met een reikwijdte.

Dan is de vraag hoe je tot een werkbare omgeving zou kunnen komen?

Een werkbare aanpak in zeven stappen

1. Bepaal de kritieke keten, niet de hele keten. Werk vanuit kritieke bedrijfsprocessen terug naar de leveranciers en componenten die die processen kunnen stilleggen. Volwassen ketenbeheer begint bij een korte lijst, niet bij een compleet register. Relevantie boven volledigheid in de eerste stap.
2. Formuleer een ketenrisicobereidheid. Leg vast welke verstoringsduur, gegevensimpact en concentratiegraad acceptabel is en op welk niveau een uitzondering wordt goedgekeurd. Zonder expliciete grenzen blijft elk leveranciersrisico onderhandelbaar.
3. Differentieer de eisen. Segmenteer leveranciers naar impact en koppel daaraan de zwaarte van due diligence, meldtermijnen, auditrechten en exitafspraken. NIS2 vraagt uitdrukkelijk om afweging per leverancier, niet om uniforme eisen.
4. Maak componenten en afhankelijkheden zichtbaar. Vraag SBOM’s uit bij aanschaf, borg dat ze actueel blijven en test of u er daadwerkelijk op kunt zoeken. De CRA maakt dit vanaf 2027 tot de norm in de markt, maar geeft u als afnemer geen recht op inzage: leg levering, actualiteit, formaat en diepgang daarom nu al vast in uw inkoopvoorwaarden.
5. Oefen het scenario dat u niet zelf kunt oplossen. Neem een ketenuitval en een gecompromitteerde beheerpartij op in crisisoefeningen, met contractuele meldketens, alternatieve dienstverlening en communicatielijnen. Reactietijd is een beheersmaatregel.
6. Rapporteer in stuurinformatie, niet in bijlagen. Vier indicatoren volstaan om richting te geven: dekkingsgraad van beoordeelde kritieke leveranciers, aantal onbeheerste concentratiepunten, gemiddelde meld- en hersteltijd bij ketenincidenten, en het aantal openstaande hoge kwetsbaarheden in geleverde componenten.
7. Beleg het eigenaarschap bestuurlijk. Wijs één bestuurder aan als portefeuillehouder ketenrisico, agendeer de ketenrisicobereidheid jaarlijks in de planning-en-controlcyclus en laat uitzonderingen op dat niveau tekenen. Zolang niemand in de bestuurskamer eigenaar is, blijft ketenveiligheid vanzelf een IT-dossier.

Voor de inrichting hoeft niemand het wiel opnieuw uit te vinden. ISO 28000:2022 biedt een managementsysteem voor security inclusief ketenaspecten[17], ISO/IEC 27036-3:2023 geeft richtlijnen voor de beveiliging van de keten van hardware, software en diensten [18] en NIST SP 800-161 Rev. 1 beschrijft praktijken voor cybersecurity supply chain risk management op systeem- en organisatieniveau[19]. De winst zit niet in de keuze van het raamwerk, maar in de consistentie waarmee het wordt toegepast.

Resume: uitbesteden kan, verantwoordelijkheid weggeven niet

Ketenveiligheid dwingt organisaties tot een oncomfortabele conclusie: het beveiligingsniveau van de zwakste relevante schakel bepaalt mede de continuïteit van de eigen dienstverlening. Regelgeving legt die verantwoordelijkheid nu ondubbelzinnig bij de organisatie zelf en, in het verlengde daarvan, bij haar bestuurders tot en met de plicht om de maatregelen zelf goed te keuren, toe te zien op de uitvoering en de eigen kennis van cyberrisico’s op peil te houden. De opgave is dan ook niet primair technisch. Zij vraagt van bestuur en toezicht dat zij afhankelijkheden kennen, grenzen stellen, gedrag in de keten belonen en zich voorbereiden op incidenten die elders beginnen. Dat is minder spectaculair dan een technologisch programma, maar wel het verschil tussen een organisatie die een ketenincident overleeft en een organisatie die erdoor wordt verrast.

[1]ENISA, ENISA Threat Landscape 2025, 1 oktober 2025 (v1.2, 9 januari 2026). https://www.enisa.europa.eu/publications/enisa-threat-landscape-2025

[2]ENISA, ENISA Threat Landscape 2025 (pdf), paragraaf over verdeling van dreigingscategorieen. https://www.enisa.europa.eu/sites/default/files/2026-01/ENISA%20Threat%20Landscape%202025_v1.2.pdf

[3]Verizon Business, 2025 Data Breach Investigations Report, persbericht 23 april 2025. https://www.verizon.com/about/news/2025-data-breach-investigations-report

[4]Palo Alto Networks Unit 42, “Shai-Hulud” Worm Compromises npm Ecosystem in Supply Chain Attack, 2025. https://unit42.paloaltonetworks.com/npm-supply-chain-attack/

[5]GitHub, Our plan for a more secure npm supply chain, 22 september 2025. https://github.blog/security/supply-chain-security/our-plan-for-a-more-secure-npm-supply-chain/

[6]Richtlijn (EU) 2022/2555 (NIS2), artikel 21, lid 2, onder d, EUR-Lex. https://eur-lex.europa.eu/legal-content/NL/TXT/?uri=CELEX%3A32022L2555

[7]Richtlijn (EU) 2022/2555 (NIS2), artikel 21, lid 3, en artikel 22, lid 1, EUR-Lex. https://eur-lex.europa.eu/legal-content/NL/TXT/?uri=CELEX%3A32022L2555

[8]Staatsblad 2026, 189: Besluit van 8 juli 2026 (Cyberbeveiligingsbesluit), artikel 35 (inwerkingtreding 15 augustus 2026). https://zoek.officielebekendmakingen.nl/stb-2026-189.html

[9]NCSC, De Cyberbeveiligingswet in laatste fase van vaststelling, 1 juli 2026. https://www.ncsc.nl/nieuws/de-cyberbeveiligingswet-in-laatste-fase-van-vaststelling

[10]NCSC, De Cyberbeveiligingswet en toeleveranciers. https://www.ncsc.nl/cyberbeveiligingswet-nis2/de-cyberbeveiligingswet-en-toeleveranciers

[11]Europese Commissie, Cyber Resilience Act, beleidspagina met inwerkingtredings- en toepassingsdata. https://digital-strategy.ec.europa.eu/en/policies/cyber-resilience-act

[12]Verordening (EU) 2024/2847 (Cyber Resilience Act), artikel 3, punt 39 en overweging 77, EUR-Lex. https://eur-lex.europa.eu/eli/reg/2024/2847/oj/eng

[13]EIOPA, Digital Operational Resilience Act (DORA): van toepassing sinds 17 januari 2025. https://www.eiopa.europa.eu/digital-operational-resilience-act-dora_en

[14]AFM, Management of ICT risk for ICT third-party service providers (DORA). https://www.afm.nl/en/sector/themas/belangrijke-europese-wet–en-regelgeving/dora/derde-aanbieders

[15]Europees Parlement (EPRS), Implementing the EU’s Critical Raw Materials Act, briefing 2024, over de 65%-afhankelijkheidsgrens. 
https://www.europarl.europa.eu/thinktank/en/document/EPRS_BRI(2024)766253

[16]Europese Commissie, Critical Raw Materials Act: benchmarks 2030 (10% winning, 40% verwerking, 25% recycling). https://single-market-economy.ec.europa.eu/sectors/raw-materials/areas-specific-interest/critical-raw-materials/critical-raw-materials-act_en

[17]ISO 28000:2022, Security and resilience – Security management systems – Requirements (editie 2, ISO/TC 292). https://www.iso.org/standard/79612.html

[18]ISO/IEC 27036-3:2013, Information security for supplier relationships – Guidelines for ICT supply chain security. https://www.iso.org/standard/59688.html

[19]NIST, SP 800-161 Rev. 1, Cybersecurity Supply Chain Risk Management Practices for Systems and Organizations, mei 2022. https://csrc.nist.gov/pubs/sp/800/161/r1/final