Ketenbeveiliging onder de Cyberbeveiligingswet (Cbw) verplicht essentiële en belangrijke entiteiten om niet alleen hun eigen systemen te beveiligen, maar ook actief te sturen op de cybersecuritypraktijken van directe toeleveranciers. Daarmee raakt de Cbw onvermijdelijk aan een vraagstuk dat compliance officers en IT-beslissers steeds vaker tegenkomen: wat als een toeleverancier zijn SaaS-dienst draait op infrastructuur van een Amerikaanse hyperscaler, en welke jurisdictierisico’s brengt dat mee?
Wat de Cbw concreet vraagt van essentiële en belangrijke entiteiten
De Cbw implementeert de NIS-2-richtlijn in Nederlands recht en verplicht aangewezen organisaties via artikel 21 van NIS-2 om beveiliging van de toeleveringsketen op te nemen in hun risicobeheersmaatregelen. Dat is geen inspanningsverplichting in de marge, maar een kernvereiste die toezichthouders actief beoordelen.
Concreet betekent dit dat u als Cbw-entiteit moet kunnen aantonen dat u de beveiligingspraktijken van uw leveranciers kent, beoordeelt en periodiek herbeoordeelt. Daarbij gaat het niet alleen om de directe leverancier, maar ook om de infrastructuur waarop die leverancier draait. Een softwarebedrijf dat zijn product levert via een SaaS-model op AWS of Microsoft Azure, brengt de jurisdictierisico’s van die cloudprovider mee uw keten in.
Uit het ENISA NIS Investments rapport 2023 blijkt dat 58% van de NIS-2-organisaties de beveiliging van de toeleveringsketen als een van de grootste uitdagingen benoemt. Tegelijkertijd heeft meer dan de helft van de onderzochte entiteiten geen formeel proces voor het beoordelen van ICT-derde-partijrisico’s. Dit gat tussen bewustzijn en praktijk is precies waar handhaving zich op richt.
Jurisdictierisico als risicocategorie in de ketenanalyse
Jurisdictierisico is het risico dat buitenlandse wetgeving toegang geeft tot gegevens die uw organisatie heeft toevertrouwd aan een leverancier. Voor organisaties in de overheid, juridische sector en andere gereguleerde sectoren is dit geen theoretisch risico.
De Amerikaanse CLOUD Act (Clarifying Lawful Overseas Use of Data Act, 2018) stelt Amerikaanse autoriteiten in staat om gegevens te vorderen bij Amerikaanse bedrijven, ook als die gegevens op Europese servers staan. De Foreign Intelligence Surveillance Act (FISA), met name sectie 702, biedt aanvullende grondslag voor het opvragen van gegevens bij Amerikaanse communicatiedienstverleners, inclusief grote cloudproviders. Het arrest Schrems II van het Hof van Justitie (2020) heeft bevestigd dat dit een reëel conflict oplevert met de Europese privacyregelgeving.
In een NIS-2-ketenrisicoanalyse vertaalt u dit als volgt naar een afzonderlijke risicocategorie:
| Risicofactor | Relevante wetgeving | Impact voor Cbw-entiteit |
|---|---|---|
| Leverancier is Amerikaans bedrijf of dochter van Amerikaans bedrijf | CLOUD Act, FISA sectie 702 | Gegevens kunnen worden gevorderd zonder kennisgeving aan de verwerkingsverantwoordelijke |
| Leverancier draait op infrastructuur van Amerikaanse hyperscaler | CLOUD Act (via moedermaatschappij) | Indirecte blootstelling, ook als de leverancier zelf Europees is |
| Leverancier heeft personeel of back-ups in de VS | FISA, NSA-programma’s | Toegang tot versleutelde data via sleutelbeheer in de VS |
| Leverancier gebruikt Europese cloudprovider zonder Amerikaanse binding | Geen directe Amerikaanse juridische grondslag | Laag jurisdictierisico; verificatie vereist |
Het ENISA Threat Landscape 2023 stelt dat bij circa 40% van de significante incidenten een derde partij of leverancier betrokken was. Dat maakt de keten niet alleen een juridisch, maar ook een operationeel risico.
Minimumafspraken in leverancierscontracten
Cbw-entiteiten zijn verplicht om in contracten met toeleveranciers concrete beveiligingsafspraken te maken. Generieke verwerkersovereenkomsten zijn onvoldoende als zij niet ingaan op de specifieke risico’s die de cloudinfrastructuur van de leverancier meebrengt.
De volgende elementen gelden als minimum voor een contract met een leverancier die SaaS-diensten afneemt van een Amerikaanse hyperscaler:
- Een expliciete bepaling over welke cloudproviders de leverancier mag inzetten en onder welke jurisdictie die vallen.
- Een meldplicht bij vorderingen van buitenlandse overheden, voor zover wettelijk toegestaan, en een inspanningsverplichting om dergelijke vorderingen aan te vechten.
- Afspraken over sleutelbeheer: wie beheert de versleutelingssleutels en zijn die technisch buiten bereik van de cloudprovider?
- Het recht op audit of een gelijkwaardige derdenbeoordeling (zoals een ISO 27001-certificaat met scope die de jurisdictiekwestie dekt, of een SOC 2 Type II-rapport).
- Een incidentmeldtermijn die aansluit op de 24-uursmeldplicht van de Cbw aan de bevoegde autoriteit.
De NCSC keteninventarisatietool en de soevereiniteitsdimensie
Het NCSC biedt een keteninventarisatie-template waarmee organisaties systematisch in kaart brengen welke leveranciers welke diensten leveren en welke afhankelijkheden en risico’s zij meebrengen. Dit template is primair opgezet vanuit beschikbaarheid en cyberweerbaarheid, maar biedt een geschikte structuur om ook de soevereiniteitsdimensie in te integreren.
In de praktijk voegen CISO’s daarvoor twee kolommen toe aan het template: de juridische vestigingsplaats van de leverancier (en eventuele moedermaatschappij) en de jurisdictie van de gebruikte cloudinfrastructuur. Zo wordt direct zichtbaar welke leveranciers een CLOUD Act- of FISA-blootstelling meebrengen, zonder dat u voor elke leverancier een aparte juridische analyse hoeft te starten.
Het NCTV organiseert via zijn Cbw-webinarserie over de toeleveringsketen praktijksessies waarin dit soort werkwijzen worden gedeeld tussen aangewezen entiteiten. Deelname aan deze sessies is een nuttige aanvulling op de formele documentatieverplichting, omdat u daarin sector-specifieke good practices tegenkomt die niet in generieke handleidingen staan.
Periodiek auditen op jurisdictierisico: good practices van CISO’s
Een eenmalige inventarisatie is niet voldoende. De Cbw veronderstelt een cyclisch risicobeheersproces, wat betekent dat u leveranciers periodiek herbeoordeelt. Voor jurisdictierisico en cloudsoevereiniteit zijn de volgende praktijken effectief gebleken:
Ten eerste: koppel de herbeoordelingsfrequentie aan de classificatie van de leverancier. Leveranciers die kritieke systemen bedienen of toegang hebben tot gevoelige gegevens, verdienen een jaarlijkse beoordeling; overige leveranciers kunnen op een tweejaarlijkse cyclus. Bij elke contractverlenging volgt automatisch een update van het jurisdictieprofiel.
Ten tweede: gebruik concrete toetsvragen in plaats van open vragenlijsten. Voorbeelden zijn: heeft de leverancier zijn cloudprovider gewijzigd sinds de vorige beoordeling, is de moedermaatschappij van de leverancier overgenomen door een niet-Europese partij, en zijn de versleutelingssleutels aantoonbaar buiten bereik van de cloudprovider?
Ten derde: documenteer de uitkomst in een leveranciersregister dat koppelt aan uw risicoregister. De RDI kan bij een inspectie vragen naar de onderbouwing van uw risicoclassificaties; een goed bijgehouden register versnelt dat proces aanzienlijk.
Cbw-ketenbeveiliging en DORA: twee regimes, één leveranciersbestand
Financiële instellingen die zowel onder de Cbw als onder de Digital Operational Resilience Act (DORA) vallen, staan voor een dubbele verplichting. DORA artikelen 28 tot en met 30 stellen gedetailleerde eisen aan ICT-derde-partijcontracten, concentratierisicobeheer en het register van kritieke ICT-derde-partijdienstverleners.
Het verschil is dat DORA verder gaat op het contractuele vlak: zo verplicht artikel 30 DORA tot specifieke bepalingen over exitstrategieën, prestatie-indicatoren en het recht op inspectie door de bevoegde autoriteit zelf. De Cbw stelt deze eisen impliciet via de algemene risicobeheersplicht, maar niet zo expliciet als DORA.
Voor organisaties die onder beide regimes vallen, is de meest efficiënte aanpak het opzetten van één geïntegreerd leveranciersbeoordelingsproces dat aan beide voldoet. De DORA-vereisten vormen daarbij het strengere kader; wie aan DORA voldoet, voldoet voor het contractuele deel in de meeste gevallen ook aan de Cbw-ketenbeveiliging. Jurisdictierisico is echter een aandachtsgebied waar DORA minder expliciet is dan de combinatie van NIS-2 en de AVG-handhavingspraktijk na Schrems II.
De NCTV benadrukt in zijn Cbw-webinarserie dat organisaties die onder meerdere sectorale regimes vallen, niet twee aparte compliance-processen moeten bouwen, maar één geïntegreerde aanpak moeten hanteren waarbij de strengste norm leidend is per deelgebied.
FAQ: Ketenbeveiliging, cloudsoevereiniteit en de Cbw
Welk artikel van de Cyberbeveiligingswet gaat over ketenbeveiliging?
De Cbw implementeert artikel 21 van de NIS-2-richtlijn, dat essentiële en belangrijke entiteiten verplicht om beveiliging van de toeleveringsketen expliciet op te nemen in hun risicobeheersmaatregelen. Dat omvat het beoordelen van kwetsbaarheden die leveranciers meebrengen, inclusief de cloudinfrastructuur waarop zij draaien.
Is een CLOUD Act-blootstelling van een SaaS-leverancier een Cbw-risico?
Ja. Als een SaaS-leverancier gegevens opslaat op infrastructuur van een Amerikaans bedrijf, kunnen die gegevens op grond van de CLOUD Act worden gevorderd door Amerikaanse autoriteiten, ook als de servers in Europa staan. Dit is een juridisch risico dat u als essentiële entiteit in uw ketenrisicoanalyse moet opnemen en contractueel moet adresseren.
Welke contractuele minimumvereisten gelden voor een toeleverancier onder de Cbw?
U moet ten minste vastleggen: welke beveiligingsmaatregelen de leverancier treft, hoe en wanneer incidenten worden gemeld, of en hoe de leverancier zelf subverwerkers of cloudproviders inzet, het recht op audit of derdenbeoordeling, en hoe de leverancier omgaat met vorderingen van buitenlandse overheden ten aanzien van uw gegevens.
Wat is het verschil tussen Cbw-ketenbeveiliging en DORA artikel 28 tot 30?
De Cbw-ketenbeveiliging geldt breed voor alle essentiële en belangrijke entiteiten in aangewezen sectoren en richt zich op cyberveiligheid van de keten als geheel. DORA artikelen 28 tot en met 30 richten zich specifiek op financiële instellingen en stellen aanvullende, gedetailleerdere eisen aan ICT-derde-partijcontracten, concentratierisico en toezicht op kritieke derde aanbieders. Organisaties die onder beide regimes vallen, moeten aan beide voldoen; DORA is daarbij vaak strenger op het contractuele vlak.
Hoe helpt de NCSC keteninventarisatietool bij cloudsoevereiniteit?
Het NCSC biedt een keteninventarisatie-template waarmee organisaties systematisch in kaart brengen welke leveranciers welke diensten leveren en welke risico’s zij meebrengen. Door in dit template een soevereiniteitskolom toe te voegen, namelijk de jurisdictie van de cloudprovider en het toepasselijke recht, krijgt u direct inzicht in waar CLOUD Act- of FISA-blootstelling speelt zonder voor elke leverancier een aparte juridische analyse te hoeven starten.
