Ketenverantwoordelijkheid is de plicht van een organisatie om de risico’s te beheersen die via haar rechtstreekse leveranciers en dienstverleners haar eigen netwerk- en informatiesystemen kunnen raken.
Ketenverantwoordelijkheid heet ook wel ketenbeveiliging, toeleveringsketenbeveiliging, supply chain security of derdepartijrisicobeheer.
Het mechanisme is in elke norm hetzelfde: leveranciers in kaart brengen, het risico per leverancier wegen, passende maatregelen nemen en dat vastleggen. De organisatie geeft de eisen daarna contractueel door.
Het gevolg is dat de eis zich verspreidt tot ver buiten de groep die de norm zelf raakt, meestal als vragenlijst bij een aanbesteding of als beveiligingsbijlage bij contractverlenging.
De plicht ligt bij de organisatie die onder de norm valt. Als leverancier merk je het alleen wanneer jouw levering raakt aan hun netwerk- en informatiesystemen.
De reikwijdte is smaller dan de term suggereert: het gaat om rechtstreekse leveranciers en dienstverleners. Risico’s dieper in de keten mag je meewegen, maar de meeste normen maken daar geen zelfstandige verplichting van.
Om het toe te passen begin je bij de bewijslast: welke norm raakt jou, welk bewijs vraagt die over je leveranciers en kan je ICT-omgeving dat vandaag leveren.
Op deze pagina
- Feitenkader ketenverantwoordelijkheid in ICT-compliance
- Hoe ketenverantwoordelijkheid werkt in ICT-compliance
- In welke normen ketenverantwoordelijkheid in ICT-compliance staat
- Waarom ketenverantwoordelijkheid belangrijk is in ICT-compliance
- Voor wie ketenverantwoordelijkheid geldt in ICT-compliance
- Onderdelen van ketenverantwoordelijkheid in ICT-compliance
- Positie van ketenverantwoordelijkheid binnen ICT-compliance
- Ketenverantwoordelijkheid in ICT-compliance in de praktijk
- Zo helpt ClickOn
- Veelgestelde vragen over ketenverantwoordelijkheid in ICT-compliance
Feitenkader ketenverantwoordelijkheid in ICT-compliance {#feitenkader}
Deze kenmerken van ketenverantwoordelijkheid gelden normoverstijgend. Waar het begrip per norm precies staat, staat in de normtabel verderop.
| Kenmerk | Waarde |
|---|---|
| Type norm | Open norm: passende en evenredige maatregelen, geen voorgeschreven maatregelenlijst |
| Reikwijdte | Rechtstreekse leveranciers en dienstverleners; dieper in de keten optioneel |
| Ingangsdatum Cyberbeveiligingswet | 15 augustus 2026, zonder overgangstermijn (NCTV, 2026) |
| Organisaties onder de Cyberbeveiligingswet | Ruim 8.000 in Nederland (NCTV, 2026) |
| Toezicht op leveranciers | In de regel geen: toezicht en boete liggen bij de organisatie die onder de norm valt (NCSC, 2026). Uitzondering is DORA, waar als kritiek aangewezen ICT-dienstverleners onder rechtstreeks Europees toezicht komen (ESMA, 2025) |
| Verplicht certificaat | Nee, geen norm schrijft een keurmerk voor bij leveranciers (NCSC, 2026) |
| Herbeoordelingsfrequentie | Niet voorgeschreven; risicogestuurd |
| Boete NIS2 bij de vallende organisatie | Essentiële entiteit tot 10 miljoen euro of 2 procent wereldwijde jaaromzet; belangrijke entiteit tot 7 miljoen euro of 1,4 procent (NIS2-richtlijn artikel 34, 2022) |
Hoe ketenverantwoordelijkheid werkt in ICT-compliance {#werking}
Ketenverantwoordelijkheid werkt via de norm, niet via een aparte wet. Elke norm die de keten adresseert doet dat als onderdeel van de bredere risicoplicht en volgt daarbij dezelfde vier stappen: inventariseren welke leveranciers er zijn, wegen welk risico ze vormen, maatregelen nemen die bij dat risico passen en vastleggen dat je dat hebt gedaan.
De maatregelen zijn nergens voorgeschreven. De normen hanteren een open norm: passend en evenredig ten opzichte van het risico. Wat passend is bij een leverancier die alleen fysieke toegang heeft tot een serverruimte verschilt volledig van wat passend is bij een dienstverlener met een beheeraccount in je netwerk- en informatiesystemen.
De weging gebeurt per leverancier. Onder NIS2 telt de organisatie twee dingen mee: de specifieke kwetsbaarheden van elke rechtstreekse leverancier en de algemene kwaliteit van diens producten en cyberbeveiligingspraktijken inclusief veilige ontwikkelingsprocedures (NCSC, 2026). Andere normen formuleren dat anders, maar komen op dezelfde weging uit.
Het sluitstuk is aantoonbaarheid. Elke norm die de keten adresseert vraagt niet alleen dat je de maatregelen neemt, maar dat je kunt laten zien dat ze werken. Daarom eindigt ketenverantwoordelijkheid in de praktijk meestal bij een vragenlijst, een audit of een bewijsverzoek.
In welke normen ketenverantwoordelijkheid in ICT-compliance staat {#normen}
Ketenverantwoordelijkheid is geen zelfstandige wet maar een bepaling die in vrijwel elk kader voor informatiebeveiliging terugkomt, onder een eigen naam en met een eigen accent. Dit is waar het per norm landt.
| Norm | Waar het staat | Accent | Wat het van je ICT vraagt |
|---|---|---|---|
| NIS2 en Cyberbeveiligingswet | Cyberbeveiligingswet artikel 21 lid 3 onderdeel d; in de NIS2-richtlijn is dat artikel 21 lid 2 onder d, beveiliging van de toeleveringsketen | Doorlopende risicobeheersing bij rechtstreekse leveranciers, inclusief fysieke gevaren | Aparte accounts per leverancier met MFA, beperkte rechten, logging op leveranciersactiviteit en aantoonbaar intrekken bij vertrek |
| ISO 27001 | Annex A 5.19 tot en met 5.23, leveranciersrelaties | Beleid, contractuele afspraken en monitoring binnen een managementsysteem | Exporteerbare bewijsvoering van toegangsrechten en instellingen, zodat de auditor de maatregel op de koppeling kan toetsen |
| DORA | Hoofdstuk V, beheer van ICT-risico’s van derde aanbieders | Het meest uitgewerkt: register van uitbestedingen, exitstrategie, vaste contracteisen | Volledig zicht op welke ICT-diensten waar draaien, plus technisch uitvoerbare exit: data-export en overdraagbaarheid |
| NEN 7510 | Leveranciersrelaties, volgend op de ISO 27002-structuur | Ketenpartners en softwareleveranciers in de zorg | Herleidbare toegang tot patiëntgegevens per leverancier, met logging die tot de persoon te herleiden is |
| BIO | Leveranciersrelaties, volgend op de ISO 27002-structuur | Werkt via aanbestedingen door naar leveranciers van overheden | Aantoonbare basismaatregelen op de werkplek, meestal uitgevraagd als ingevulde vragenlijst met bewijs |
| AVG | Artikel 28, verwerkersovereenkomst | Alleen de verwerking van persoonsgegevens, met vastgelegde instructies | Technische en organisatorische maatregelen die de verwerking beperken: encryptie, toegangsbeperking en bewaartermijnen |
| NIST | SP 800-161, Cybersecurity Supply Chain Risk Management (NIST, 2022) | Het meest gedetailleerde raamwerk, tot diep in de keten | Zicht op de herkomst van software en componenten, inclusief patchstatus van wat je via leveranciers binnenhaalt |
| SOC 2 en ISAE 3402 | Beheersmaatregelen rond subservice-organisaties | Assurance: je auditor toetst hoe jij je leveranciers beheerst | Bewijs dat over een periode werkt, niet op een moment: doorlopende logging in plaats van een screenshot |
| ISO 9001 | Paragraaf 8.4, beheersing van extern geleverde processen | Leveranciersbeoordeling op kwaliteit, niet op beveiliging | Niets specifieks op beveiligingsvlak; de ICT-eisen komen bij deze norm niet uit de ketenbepaling |
De nummering van de ketenbepaling verschilt tussen de Europese richtlijn en de Nederlandse wet. In de NIS2-richtlijn staat de maatregelenlijst in artikel 21 lid 2, waarin de toeleveringsketen onderdeel d is. De Cyberbeveiligingswet heeft de zorgplicht anders ingedeeld: lid 1 is de algemene plicht om passende en evenredige maatregelen te nemen, lid 2 gaat over het beveiligingsniveau en lid 3 bevat de maatregelenlijst a tot en met h, waarin de toeleveringsketen opnieuw onderdeel d is (Staatsblad 2026, 187). Verwijs je naar de Nederlandse wet, dan is artikel 21 lid 3 onderdeel d de juiste vindplaats.
Het verschil zit in de diepte, niet in het principe. DORA en NIST gaan het verst en vragen om een formeel register en om zicht voorbij de eerste schil. NIS2, ISO 27001, NEN 7510 en BIO blijven bij de rechtstreekse leverancier. De AVG is het smalst en dekt alleen persoonsgegevens. ISO 9001 kijkt naar leveringskwaliteit en niet naar informatiebeveiliging, waardoor een ISO 9001-leveranciersbeoordeling het ketenrisico niet afdekt.
Val je onder meerdere normen, dan stapelen de eisen niet. De onderliggende maatregelen zijn grotendeels dezelfde en het bewijs is grotendeels herbruikbaar. Wat verschilt is de vastlegging en de diepgang die de strengste norm van je vraagt.
Waarom ketenverantwoordelijkheid belangrijk is in ICT-compliance {#waarom}
Wat er bij ketenverantwoordelijkheid op het spel staat verschilt per positie. Voor de organisatie die onder de norm valt is het een handhaafbare plicht met een boete of een afgekeurde audit als sluitstuk. Voor haar leveranciers is het commercieel: geen bewijs betekent afvallen bij een tender of een contractverlenging.
De aanleidingen zijn concreet en beperkt in aantal. Een aanbesteding met een beveiligingsparagraaf. Een contractverlenging met een nieuwe bijlage. Een onboarding waarin je klant bewijs vraagt van je herstelproces. En een incident bij een ketenpartner, waarna iedereen in de keten dezelfde vragenlijst krijgt.
Dat laatste is geen theorie. Het Cybersecuritybeeld Nederland stelt vast dat er met regelmaat cyberincidenten zijn bij toeleveranciers en dienstverleners die leiden tot datalekken bij hun afnemers (NCTV, 2025).
De voorbereiding loopt achter op de vraag. Uit het onderzoek State of Supply Chain Security beoordeelt 44 procent van de Nederlandse organisaties zijn leveranciers niet regelmatig en heeft 17 procent vertrouwen in het eigen vermogen om de beveiligingsmaatregelen van leveranciers te volgen, tegen 34 procent wereldwijd (NCC Group, 2025). Tegelijk zou het wegvallen van één toeleverancier voor 24 uur de dagelijkse operatie raken van 87 procent van de ondervraagde Nederlandse bedrijven (NCC Group, 2025). De afhankelijkheid is er al, het zicht erop niet.
Voor wie ketenverantwoordelijkheid geldt in ICT-compliance {#voor-wie}
Niet elk bedrijf heeft met ketenverantwoordelijkheid te maken. Er zijn twee posities en ze verschillen juridisch volledig.
Je valt zelf onder een norm met een ketenbepaling. Dan is ketenverantwoordelijkheid jouw plicht. Je brengt je rechtstreekse leveranciers in kaart, weegt hun risico voor je netwerk- en informatiesystemen en neemt wat passend is.
Je levert aan zo’n organisatie. Dan heb je geen wettelijke plicht, maar krijg je de eisen contractueel door. Volgens het NCSC is de kans groot dat je in hun risico-inventarisatie voorkomt als je levering aan één van drie dingen voldoet (NCSC, 2026):
- je levert diensten of producten die te maken hebben met hun netwerk- en informatiesystemen
- je levert een ICT-component van die systemen
- je hebt toegang tot die systemen
Voor wie geldt het niet? Een leverancier van koffiebonen vormt geen risico voor de netwerk- en informatiesystemen van zo’n organisatie en komt niet in de inventarisatie voor (NCSC, 2026). Hetzelfde geldt voor elke levering zonder raakvlak met ICT: schoonmaak, catering, drukwerk, kantoormeubilair.
En sta je er wel in, dan krijg je in de regel nog steeds geen toezichthouder over de vloer. Een toezichthouder houdt toezicht op de organisatie die onder de norm valt, niet op haar toeleveranciers en legt hun geen boete op voor een ontbrekend certificaat (NCSC, 2026). Je klant is je handhaver. De uitzondering is DORA: wie als kritieke ICT-dienstverlener voor de financiële sector wordt aangewezen, komt wel rechtstreeks onder toezicht te staan.
Onderdelen van ketenverantwoordelijkheid in ICT-compliance {#onderdelen}
Ketenverantwoordelijkheid is geen enkele maatregel maar een set die op elkaar staat. Per onderdeel staat hieronder wat het is en wat het concreet betekent in je ICT-omgeving.
| Onderdeel | Wat het is | Wat het betekent in je ICT-omgeving |
|---|---|---|
| Leveranciersinventarisatie | De lijst van partijen waarmee je een rechtstreekse leveringsrelatie hebt. Het enige onderdeel dat volledig moet zijn, want wat er niet op staat weeg je ook niet. | Uitlezen welke externe accounts, gastgebruikers en gekoppelde applicaties toegang hebben tot je omgeving. Die lijst wijkt in de praktijk af van de inkooplijst. |
| Leveranciersclassificatie | De scheiding tussen kritiek en niet-kritiek, op basis van wat uitval doet met de beschikbaarheid, integriteit en vertrouwelijkheid van je dienstverlening. | Vertaalt zich naar rechtenniveaus: wie krijgt beheerrechten, wie leesrechten en wie alleen toegang tot een afgebakende omgeving. |
| Risicoanalyse per leverancier | Waar het cyberrisico wordt gewogen. Onder NIS2 omvat dat uitdrukkelijk ook fysieke gevaren, zoals brand in een serverruimte (NCSC, 2026). Wordt het vaakst versmald tot een puur digitale scan. | Per leverancier nagaan welke data en systemen bereikbaar zijn vanaf zijn toegangspunt en wat er misgaat als dat account wordt overgenomen. |
| Contractuele vastlegging | Afspraken over onderhoud, beveiliging, meldtermijnen en verantwoordelijkheden, vaak in een Service Level Agreement of een Dossier Afspraken en Procedures (NCSC, 2026). | Het enige onderdeel waarvan het bewijs op papier staat in plaats van in een systeem. De ICT-kant is dat de afgesproken instellingen ook daadwerkelijk zo staan. |
| Technische maatregelen op de koppeling | De beveiliging op het punt waar de leverancier je omgeving raakt. Het enige onderdeel dat je zelf kunt afdwingen zonder medewerking van de leverancier. | Toegangsbeheer, multifactorauthenticatie, rechten beperkt tot het noodzakelijke en logging op leveranciersaccounts. |
| Doorlopende monitoring en herbeoordeling | Een jaarlijkse vragenlijst is een momentopname en dekt de norm niet, omdat de risicobenadering doorloopt. | Signalering op afwijkend gedrag van leveranciersaccounts: inloggen buiten kantooruren, vanaf onbekende locaties of met verhoogde rechten. |
| Offboarding en exit | Intrekken van accounts, teruggave van data en overdracht van systeemkennis. Onderscheidt zich doordat het meestal pas mist op het moment dat je het nodig hebt. | Een gecontroleerd proces om accounts en gedeelde mappen in te trekken en te kunnen laten zien wanneer dat is gebeurd. |
| Beveiliging bij inkoop en ontwikkeling | Formeel een eigen maatregel, in de praktijk het spiegelbeeld: dit gaat over beveiliging als eis bij het systeem, ketenverantwoordelijkheid over de relatie met de partij erachter. | Beveiligingseisen als voorwaarde bij aanschaf, plus patchmanagement op alles wat je via leveranciers binnenhaalt. |
Ketenverantwoordelijkheid in ICT-compliance bij een incident
Wordt een leverancier getroffen, dan blijft de organisatie die onder de norm valt zelf verantwoordelijk voor de gevolgen in haar eigen omgeving. Een cyberincident dat via een leverancier binnenkomt telt voor de meldplicht als een eigen incident en de meldtermijnen lopen vanaf het moment dat je er kennis van hebt. Wat je daarvoor vooraf regelt zijn de meldafspraken in het contract: binnen welke termijn je leverancier jou informeert en met welke informatie.
De uitwerking daarvan, inclusief de rolverdeling tussen leverancier, organisatie en toezichthouder, staat op de pagina over ketenincidenten en meldplicht.
Positie van ketenverantwoordelijkheid binnen ICT-compliance {#positie}
Waar ketenverantwoordelijkheid onder valt
Ketenverantwoordelijkheid valt onder risicomanagement: het is de toepassing van risicobeheersing op partijen buiten je eigen organisatie. In normen met een zorgplicht valt het onder die zorgplicht, als één van de verplichte maatregelcategorieën.
Waar ketenverantwoordelijkheid verwant aan is
Ketenverantwoordelijkheid is verwant aan risicobeheersmaatregelen: die vormen de bredere set waarvan de ketenmaatregelen een deelverzameling zijn.
Ketenverantwoordelijkheid hangt samen met beveiliging bij inkoop en ontwikkeling, omdat beide op hetzelfde inkoopmoment landen: het ene richt zich op het systeem, het andere op de partij die het levert.
Ketenverantwoordelijkheid raakt aan bedrijfscontinuïteit, omdat uitval van een kritieke leverancier hetzelfde effect heeft als uitval van een eigen systeem.
Ketenverantwoordelijkheid is gerelateerd aan de meldplicht: een incident dat via een leverancier binnenkomt is voor de meldplicht een eigen incident.
Welke instanties per norm bij ketenverantwoordelijkheid betrokken zijn
- NIS2 en Cyberbeveiligingswet: NCSC, dat de uitleg van de zorgplicht en de handreikingen voor leveranciersinventarisatie publiceert. De bevoegde autoriteit houdt toezicht op de organisatie, niet op haar leveranciers (NCSC, 2026).
- DORA: de Europese toezichthouders, die ICT-dienstverleners als kritiek kunnen aanwijzen en dan zelf toezicht op die leverancier houden (ESMA, 2025).
- ISO 27001, NEN 7510 en ISO 9001: geaccrediteerde certificerende instellingen, die toetsen of je leveranciersbeheer werkt.
- AVG: de Autoriteit Persoonsgegevens, die zowel de verwerkingsverantwoordelijke als de verwerker kan aanspreken.
- BIO: de overheidsopdrachtgever zelf, die de eisen via aanbestedingen oplegt en toetst.
- SOC 2 en ISAE 3402: een accountant of IT-auditor, die de verklaring afgeeft.
- Overkoepelend: ENISA voor de Europese implementatierichtlijnen. Het versterkte NCSC, waarin het Digital Trust Center is opgegaan, levert de praktische checklists voor afspraken met een IT-leverancier, ook aan bedrijven die zelf niet onder de wet vallen (NCSC, 2026).
Een keurmerk is nergens verplicht. NIS2 Supply Chain, voorheen NIS2 Quality Mark, kent drie niveaus (SC10, SC20 en SC30) waarmee leveranciers hun maatregelen aantoonbaar maken, maar het is geen wettelijke certificering (NCSC, 2026).
Ketenverantwoordelijkheid in ICT-compliance in de praktijk {#praktijk}
Ketenverantwoordelijkheid in ICT-compliance begint in de praktijk bij één toegangsaccount. Een installatiebedrijf met veertig werkplekken levert aan een netbeheerder. Het bedrijf valt zelf onder geen enkele norm met een ketenbepaling: te klein, verkeerde sector. Maar de monteurs loggen met een account in op het planningssysteem van de netbeheerder.
Daarmee voldoet het aan het derde criterium: toegang tot de netwerk- en informatiesystemen van een organisatie die wel onder de norm valt (NCSC, 2026). Het staat dus in de risico-inventarisatie van de netbeheerder.
Bij contractverlenging komt de vragenlijst. Staat multifactorauthenticatie aan op alle accounts? Hoe snel is een vertrokken monteur uit het systeem? Wie kan er meekijken? Kun je dat laten zien?
De eerste drie vragen gaan over de inrichting van de Microsoft 365-omgeving. De vierde gaat over aantoonbaarheid en daar valt het gesprek meestal stil. Niet omdat de maatregelen ontbreken, maar omdat niemand ze kan exporteren.
Zo helpt ClickOn {#clickon}
Ketenverantwoordelijkheid komt bij jou binnen als een vragenlijst over je ICT. Toegangsbeheer, multifactorauthenticatie, back-up en herstel, patchmanagement, logging en bij elk antwoord de vraag of je het kunt laten zien. ClickOn richt die laag in op je Microsoft 365-werkplekken en levert het bewijs via een live dashboard, zodat je de vragenlijst beantwoordt met een export in plaats van een belofte.
Wat wij oppakken: de technische ICT-inrichting van de werkplek en het aantoonbare bewijs daarvan.
Wat buiten onze scope valt: je leveranciersclassificatie, je contractclausules, je ketenrisicobeleid en de organisatorische kant van de zorgplicht. Het ISMS en organisatorische beleid regel je zelf of met een adviseur waarmee wij samenwerken.
Krijg je een leveranciersvragenlijst op je bord? In dertig dagen technisch klaar voor je audit met de Compliance Sprint, tegen een vaste prijs per werkplek. Werk je liever met doorlopend beheer dat standaard compliant is ingericht, dan is ClickOn Compliant MKB de route.
Vraag de Compliance Sprint aan
Veelgestelde vragen over ketenverantwoordelijkheid in ICT-compliance {#faq}
Heeft elk bedrijf met ketenverantwoordelijkheid in ICT-compliance te maken?
Niet elk bedrijf heeft met ketenverantwoordelijkheid in ICT-compliance te maken. Het geldt voor organisaties die onder een norm met een ketenbepaling vallen en het werkt contractueel door naar hun leveranciers. Lever je niets dat raakt aan hun netwerk- en informatiesystemen, dan blijf je buiten beeld.
Is ketenverantwoordelijkheid in ICT-compliance verplicht voor leveranciers?
Ketenverantwoordelijkheid in ICT-compliance is niet rechtstreeks verplicht voor leveranciers. De plicht ligt bij de organisatie die onder de norm valt; die geeft de eisen contractueel door. Voor de leverancier is het daarmee een contractuele eis en geen wettelijke, met verlies van de opdracht als sanctie in plaats van een boete.
Waar staat ketenverantwoordelijkheid in de Cyberbeveiligingswet?
Ketenverantwoordelijkheid staat in artikel 21 lid 3 onderdeel d van de Cyberbeveiligingswet, als onderdeel van de maatregelenlijst bij de zorgplicht (Staatsblad 2026, 187). In de Europese NIS2-richtlijn staat dezelfde bepaling in artikel 21 lid 2 onder d. Die twee nummeringen worden vaak door elkaar gehaald.
Wie is verantwoordelijk voor ketenverantwoordelijkheid in ICT-compliance binnen een organisatie?
Verantwoordelijk voor ketenverantwoordelijkheid in ICT-compliance is het bestuur van de organisatie die onder de norm valt. De uitvoering wordt verdeeld over inkoop, ICT en risicobeheer, maar de verantwoordelijkheid is niet delegeerbaar naar een leverancier.
Is een certificaat verplicht voor ketenverantwoordelijkheid in ICT-compliance?
Een certificaat is niet verplicht voor ketenverantwoordelijkheid in ICT-compliance. Geen enkele norm schrijft een specifiek keurmerk voor bij je leveranciers. Een certificaat maakt het gesprek makkelijker omdat je snel laat zien welke standaarden je hanteert, maar het biedt geen garantie dat het ketenrisico dat je klant heeft geïnventariseerd daarmee is afgedekt (NCSC, 2026).
Geldt ketenverantwoordelijkheid in ICT-compliance ook voor onderaannemers?
Ketenverantwoordelijkheid in ICT-compliance richt zich op je rechtstreekse leveranciers en dienstverleners. Risico’s bij partijen dieper in de keten mag je meewegen, maar de meeste normen maken daar geen zelfstandige verplichting van (NIS2-richtlijn, overweging 85, 2022). Werkt jouw onderaannemer op de systemen van je klant, dan komt hij via jouw contract alsnog in beeld.
Hoe vaak moet je leveranciers herbeoordelen voor ketenverantwoordelijkheid in ICT-compliance?
Geen enkele norm noemt een vaste frequentie voor het herbeoordelen van leveranciers. Wat de normen wel vragen is dat de maatregelen passend blijven, dus dat je herbeoordeelt wanneer het risico verandert: bij een nieuw contract, bij uitbreiding van toegang of na een incident bij die leverancier.