De zwakke schakel: een CISO-draaiboek voor het opzetten van een NIS2-conform risicoprogramma voor de toeleveringsketen

De waarschuwing leek onschuldig: een kleine afwijking uit een monitoringdienst van een externe partij. Voor Anya, CISO van een middelgrote logistieke onderneming, was het de derde melding in een maand van dezelfde leverancier: “Afwijking bij aanmelding gedetecteerd.” De leverancier, een kleine maar kritieke aanbieder van wagenparkbeheersoftware, verzekerde haar dat er niets aan de hand was. Een false positive. Maar Anya wist beter. Dit waren geen gewone technische haperingen; het waren trillingen die wezen op diepere instabiliteit in een kritiek onderdeel van haar toeleveringsketen. Nu haar organisatie onder de NIS2-richtlijn als “belangrijke entiteit” was aangemerkt, voelden deze trillingen als de voorbode van een aardbeving.
De oude manier van leveranciers beheren, met een handdruk en een ruim geformuleerd contract, is definitief voorbij. NIS2 maakt pijnlijk duidelijk dat de cybersecuritypositie van een organisatie slechts zo sterk is als de zwakste schakel. Die zwakke schakel bevindt zich niet langer “daarbuiten”; hij zit in uw toeleveringsketen. Onder NIS2 is falend beheer van leveranciersrisico geen louter technische tekortkoming. Het is een regelgevingsrisico op bestuursniveau, met operationele, reputatie- en financiële gevolgen. Anya’s probleem was niet alleen één wankele leverancier. Het was een systemische kwetsbaarheid die verweven was met haar bedrijfsvoering, en auditors zouden ernaar zoeken. Ze had meer nodig dan een snelle reparatie; ze had een draaiboek nodig.
Deze gids biedt dat draaiboek. We doorlopen een gestructureerde aanpak waarmee CISO’s, compliancemanagers en auditors een verdedigbaar risicoprogramma voor de toeleveringsketen kunnen opzetten dat over meerdere regelgevingskaders heen werkt. Door gebruik te maken van een robuust raamwerk zoals ISO/IEC 27001:2022 en de deskundige toolkits van Clarysec kunt u urgente risico’s in de toeleveringsketen koppelen aan uitvoerbare methoden om te voldoen aan NIS2, DORA, GDPR en andere vereisten.
Het risicomandaat: hoe NIS2 beveiliging van de toeleveringsketen herdefinieert
De NIS2-richtlijn verandert beveiliging van de toeleveringsketen van een loutere best practice in een juridisch bindende verplichting. De richtlijn vereist een risicogebaseerde, doorlopende aanpak voor het beveiligen van ICT- en OT-toeleveringsketens, breidt het toepassingsgebied uit naar tal van sectoren en houdt het management rechtstreeks verantwoordelijk voor tekortkomingen in de naleving. Dit betekent:
- Uitgebreid toepassingsgebied: elke leverancier, subverwerker, cloudprovider en uitbestedingspartij die uw ICT-omgeving raakt, valt binnen scope.
- Voortdurende verbetering: NIS2 vereist een levend proces van risicobeoordeling, monitoring en aanpassing, geen eenmalige beoordeling. Dit proces moet worden aangestuurd door zowel interne gebeurtenissen (incidenten, inbreuken) als externe wijzigingen (nieuwe wetgeving, updates van leveranciersdiensten).
- Verplichte beheersmaatregelen: incidentrespons, afhandeling van kwetsbaarheden, periodieke beveiligingstesten en robuuste encryptie zijn nu vereist in de gehele toeleveringsketen, niet alleen binnen uw eigen perimeter.
Hierdoor vervagen de grenzen tussen interne beveiliging en risico’s van derde partijen. Een cyberfalen bij uw leverancier wordt uw regelgevingscrisis. Een gestructureerd raamwerk zoals ISO/IEC 27001:2022 wordt onmisbaar, omdat het de beheersmaatregelen en processen biedt die nodig zijn om een weerbaar en auditeerbaar programma te bouwen dat voldoet aan de eisen van NIS2. De reis begint niet met technologie, maar met een strategie rond drie kernbeheersmaatregelen:
- 5.19 - Informatiebeveiliging in leveranciersrelaties: het vaststellen van het strategische kader voor het beheer van leveranciersrisico.
- 5.20 - Informatiebeveiliging opnemen in leveranciersovereenkomsten: het vastleggen van beveiligingsverwachtingen in juridisch bindende contracten.
- 5.22 - Monitoring, beoordeling en wijzigingsbeheer van leveranciersdiensten: het waarborgen van doorlopend toezicht en aanpassing gedurende de volledige leverancierslevenscyclus.
Het beheersen van deze drie gebieden verandert uw toeleveringsketen van een bron van zorg in een goed beheerd, compliant en weerbaar bedrijfsmiddel.
Stap 1: de governancebasis opzetten met beheersmaatregel 5.19
Anya’s eerste inzicht was dat zij niet alle leveranciers gelijk kon behandelen. De leverancier van kantoorartikelen was niet vergelijkbaar met de leverancier van haar kritieke wagenparkbeheersoftware. De eerste stap bij het opzetten van een NIS2-conform programma is het begrijpen en classificeren van uw leverancierslandschap op basis van risico.
Beheersmaatregel 5.19, Informatiebeveiliging in leveranciersrelaties, is de strategische hoeksteen. Deze maatregel dwingt u verder te gaan dan een eenvoudige leverancierslijst en een gelaagd governancestelsel op te zetten. Dit proces moet worden gestuurd door helder beleid dat door het bestuur wordt gedragen. Clarysec’s Beleid voor derde partijen en leveranciersbeveiliging koppelt deze activiteit rechtstreeks aan het bredere risicobeheerkader van de organisatie:
“P6 – Beleid voor risicobeheer. Stuurt de identificatie, beoordeling en beperking van risico’s die samenhangen met relaties met derde partijen, inclusief overgeërfde of systemische risico’s uit leverancierslandschappen.” Uit de sectie ‘Gerelateerde beleidslijnen en samenhang’, beleidsclausule 10.2.
Deze integratie zorgt ervoor dat risico’s uit downstream-afhankelijkheden, oftewel blootstellingen via “vierde partijen”, worden beheerd als onderdeel van uw eigen ISMS. Het classificatieproces zelf moet methodisch zijn. In stap 23 van de fase ‘Audit en verbetering’ begeleidt de Zenith Blueprint: 30-stappenroutekaart voor auditors organisaties bij het classificeren van leveranciers aan de hand van kritieke vragen:
- Behandelt of verwerkt de leverancier uw gevoelige of gereguleerde informatie?
- Levert de leverancier infrastructuur of platforms waarvan uw kritieke bedrijfsvoering afhankelijk is?
- Beheert of onderhoudt de leverancier systemen namens u?
- Kan compromittering van de leverancier rechtstreeks gevolgen hebben voor uw doelstellingen voor vertrouwelijkheid, integriteit of beschikbaarheid?
Anya gebruikte deze logica om haar leverancier van wagenparkbeheersoftware opnieuw te beoordelen. De leverancier verwerkte realtime locatiegegevens (gevoelig), het platform was essentieel voor de dagelijkse operatie (kritieke infrastructuur) en een compromittering kon leveringen stilleggen (hoge impact op beschikbaarheid). De leverancier werd onmiddellijk opnieuw geclassificeerd: van “standaardleverancier” naar “kritieke leverancier met hoog risico”.
Deze risicogebaseerde indeling bepaalt het vereiste niveau van due diligence, contractuele diepgang en doorlopende monitoring. Zoals onze Zenith Controls: gids voor naleving over meerdere kaders verduidelijkt, sluit deze aanpak rechtstreeks aan op de verwachtingen van belangrijke regelgeving.
| Regelgeving | Vereiste | Hoe beheersmaatregel 5.19 dit adresseert |
|---|---|---|
| NIS2 | Article 21(2)(d) verplicht risicobeheer voor toeleveringsketens. | Biedt het kader voor het identificeren en indelen van leveranciersrisico. |
| DORA | Articles 28-30 verplichten classificatie van kritieke IT- en financiële dienstverleners. | Stelt het proces vast voor het classificeren van ICT-aanbieders naar kritiek belang. |
| GDPR | Article 28 vereist dat verwerkingsverantwoordelijken alleen verwerkers gebruiken die garanties bieden. | Vormt de basis voor de due diligence die nodig is om garanties te beoordelen. |
Deze fundamentele stap is niet slechts een interne exercitie; het is het fundament waarop uw volledige verdedigbare programma voor beveiliging van de toeleveringsketen wordt gebouwd.
Stap 2: waterdichte overeenkomsten sluiten met beheersmaatregel 5.20
Toen haar leverancier met hoog risico was geïdentificeerd, haalde Anya het contract erbij. Het was een standaard inkoopsjabloon, met een vage vertrouwelijkheidsclausule en verder nauwelijks iets over cybersecurity. Het bevatte geen specifieke beveiligingsmaatregelen, geen meldtermijn voor inbreuken en geen auditrecht. In de ogen van een NIS2-auditor was het waardeloos.
Hier wordt beheersmaatregel 5.20, Informatiebeveiliging opnemen in leveranciersovereenkomsten, cruciaal. Dit is het mechanisme om de in 5.19 geïdentificeerde risico’s te vertalen naar afdwingbare, juridisch bindende verplichtingen. Een contract is niet alleen een commercieel document; het is een primaire beveiligingsmaatregel.
Uw beleid moet deze transformatie sturen. Het Beleid voor derde partijen en leveranciersbeveiliging stelt dit vast als kerndoelstelling:
“Stem beveiligingsmaatregelen voor derde partijen af op toepasselijke regelgevende en contractuele verplichtingen, waaronder GDPR, NIS2, DORA en ISO/IEC 27001-normen.” Uit de sectie ‘Doelstellingen’, beleidsclausule 3.6.
Deze clausule verandert het beleid van een richtsnoer in een rechtstreeks mandaat voor inkoop- en juridische teams. Voor Anya betekende dit dat zij terug moest naar de leverancier om opnieuw te onderhandelen. Het nieuwe contractaddendum bevatte specifieke, niet-onderhandelbare clausules:
- Melding van inbreuken: de leverancier moet elk vermoed beveiligingsincident dat gegevens of diensten van haar organisatie raakt binnen 24 uur melden, niet “binnen een redelijke termijn”.
- Auditrecht: de organisatie behoudt zich het recht voor om jaarlijks beveiligingsbeoordelingen uit te voeren of auditrapporten van derde partijen op te vragen, zoals een SOC 2 Type II.
- Beveiligingsstandaarden: de leverancier moet specifieke beveiligingsmaatregelen naleven, zoals multifactorauthenticatie voor alle beheerderstoegang en periodieke kwetsbaarheidsscans van het platform.
- Beheer van subverwerkers: de leverancier moet eigen onderaannemers die gegevens van de organisatie zullen verwerken vooraf bekendmaken en schriftelijke goedkeuring verkrijgen.
- Exitstrategie: het contract moet procedures definiëren voor veilige teruggave of vernietiging van gegevens bij beëindiging, zodat een gecontroleerde offboarding plaatsvindt.
Zoals Zenith Controls benadrukt, staat deze praktijk centraal in meerdere raamwerken. GDPR’s Article 28(3) verplicht gedetailleerde verwerkersovereenkomsten. DORA’s Article 30 schrijft een uitgebreide lijst met contractuele bepalingen voor kritieke ICT-aanbieders voor. Door een robuuste beheersmaatregel 5.20 te implementeren, voldeed Anya niet alleen aan ISO/IEC 27001:2022; zij bouwde tegelijk een verdedigbare positie op voor audits op NIS2, DORA en GDPR.
Stap 3: de uitkijktoren - continue monitoring met beheersmaatregel 5.22
Anya’s oorspronkelijke probleem, de terugkerende beveiligingswaarschuwingen, kwam voort uit een klassiek falen: “tekenen en vergeten”. Een sterk contract is waardeloos als het wordt opgeborgen en nooit meer wordt gebruikt. Het laatste puzzelstuk is beheersmaatregel 5.22, Monitoring, beoordeling en wijzigingsbeheer van leveranciersdiensten. Dit is de operationele beheersmaatregel die waarborgt dat de toezeggingen uit het contract worden nagekomen.
Deze beheersmaatregel verandert leveranciersbeheer van een statische onboardingactiviteit in een dynamisch, doorlopend proces. Volgens Zenith Controls omvat dit meerdere onderling samenhangende activiteiten:
- Prestatiebeoordelingen: periodiek geplande overleggen, bijvoorbeeld elk kwartaal voor leveranciers met hoog risico, om prestaties ten opzichte van beveiligings-SLA’s te bespreken, incidentrapporten te beoordelen en aankomende wijzigingen te plannen.
- Beoordeling van auditbewijsmateriaal: proactief opvragen en analyseren van auditrapporten, certificeringen en penetratietestresultaten van leveranciers. Een auditor zal controleren of u deze rapporten niet alleen verzamelt, maar ook actief uitzonderingen daarin opvolgt en beheert.
- Wijzigingsbeheer: wanneer een leverancier zijn dienst wijzigt, bijvoorbeeld door te migreren naar een nieuwe cloudprovider of een nieuwe API te introduceren, moet dit aan uw kant een beveiligingsbeoordeling activeren. Zo voorkomt u dat leveranciers onbedoeld nieuwe risico’s in uw omgeving introduceren.
- Continue monitoring: gebruikmaken van tools en intelligencefeeds om geïnformeerd te blijven over de externe informatiebeveiligingspositie van een leverancier. Een plotselinge daling van een beveiligingsscore of nieuws over een inbreuk moet een onmiddellijke respons activeren.
Deze continue cyclus van monitoren, beoordelen en aanpassen vormt de kern van het “doorlopende risicobeheerproces” dat NIS2 vereist. De cyclus zorgt ervoor dat vertrouwen nooit wordt aangenomen, maar voortdurend wordt geverifieerd.
Een uitvoerbaar voorbeeld: de checklist voor leveranciersbeoordeling
Om dit praktisch te maken, stelde Anya’s team een checklist op voor de nieuwe kwartaalbeoordelingen met de leverancier van wagenparkbeheersoftware, gebaseerd op de auditmethodologieën uit Zenith Controls.
| Beoordelingsgebied | Te verzamelen en te bespreken bewijsmateriaal | Gewenste uitkomst |
|---|---|---|
| SLA en prestaties | Uptime-rapportages, incidentlogboeken, oplostijden van supporttickets. | Verifiëren dat wordt voldaan aan contractuele verplichtingen voor beschikbaarheid en ondersteuning. |
| Beveiligingsincidenten | Gedetailleerd rapport over alle beveiligingswaarschuwingen, inclusief false positives, oorzaakanalyse en herstelmaatregelen. | Bevestigen dat transparant wordt gerapporteerd en incidenten effectief worden afgehandeld. |
| Naleving en audits | Laatste SOC 2-rapport of samenvatting van penetratietests. | Bevindingen beoordelen en het remediatieplan van de leverancier volgen voor geïdentificeerde kwetsbaarheden. |
| Kwetsbaarhedenbeheer | Rapportages over patchfrequentie voor kritieke systemen. | Waarborgen dat de leverancier voldoet aan de verplichting om kritieke kwetsbaarheden tijdig te patchen. |
| Aankomende wijzigingen | Bespreking van de productroadmap, infrastructuurwijzigingen of nieuwe subverwerkers van de leverancier. | De beveiligingsimplicaties van toekomstige wijzigingen proactief beoordelen voordat deze worden geïmplementeerd. |
Deze eenvoudige tool veranderde het gesprek van een algemene bijpraatsessie in een gericht, op bewijsmateriaal gebaseerd overleg over beveiligingsgovernance, met een auditeerbare registratie van doorlopend toezicht als resultaat.
Uw grens bepalen: risicoacceptatie in een NIS2-wereld
Het eerste incident met de leverancier dwong Anya een fundamentele vraag te beantwoorden: welk risiconiveau is aanvaardbaar? Zelfs met de beste contracten en monitoring blijft er altijd enig restrisico bestaan. Daarom is een duidelijke, door het management goedgekeurde definitie van acceptatiecriteria niet onderhandelbaar.
In stap 10 van de fase ‘Risico en implementatie’ biedt de Zenith Blueprint cruciale guidance op dit punt. Het is niet genoeg om te zeggen: “we accepteren lage risico’s”. U moet definiëren wat dit betekent in de context van uw wettelijke en regelgevende verplichtingen.
“Neem ook wettelijke/regelgevende vereisten mee in uw acceptatiecriteria. Sommige risico’s kunnen ongeacht de waarschijnlijkheid onaanvaardbaar zijn vanwege wetgeving… Evenzo leggen NIS2 en DORA bepaalde baseline-beveiligingsvereisten op; het niet voldoen daaraan, zelfs als de kans op een incident laag is, kan een onaanvaardbaar nalevingsrisico opleveren. Neem deze perspectieven op, bijvoorbeeld: “Elk risico dat kan leiden tot niet-naleving van toepasselijke wetgeving (GDPR, enz.) is niet aanvaardbaar en moet worden gemitigeerd.””
Dit was voor Anya een kantelpunt. Samen met haar juridische en inkoopteams werkte zij het risicobeheerbeleid bij. De nieuwe criteria bepaalden expliciet dat elke kritieke leverancier die niet voldoet aan de baseline-beveiligingsvereisten van NIS2 een onaanvaardbaar risico vormt en onmiddellijk een risicobehandelingsplan activeert. Dit haalde de ambiguïteit uit de besluitvorming en creëerde een duidelijke governancetrigger. Zoals vastgelegd in het Beleid voor derde partijen en leveranciersbeveiliging:
“Uitzonderingen met hoog risico, bijvoorbeeld leveranciers die gereguleerde gegevens verwerken of kritieke systemen ondersteunen, moeten worden goedgekeurd door de CISO, Juridische Zaken en de inkoopleiding, en worden geregistreerd in het ISMS-uitzonderingenregister.” Uit de sectie ‘Risicobehandeling en uitzonderingen’, beleidsclausule 7.3.
De auditor staat voor de deur: omgaan met toetsing vanuit meerdere invalshoeken
Zes maanden later, toen de interne auditors arriveerden om een NIS2-gereedheidsbeoordeling uit te voeren, was Anya voorbereid. Zij wist dat zij haar programma voor de toeleveringsketen vanuit meerdere invalshoeken zouden beoordelen.
De ISO/IEC 27001:2022-auditor: deze auditor richtte zich op proces en bewijsmateriaal. Hij vroeg om de leveranciersinventaris, verifieerde de risicocategorisering, nam steekproeven uit contracten op specifieke beveiligingsclausules en beoordeelde de notulen van kwartaalbeoordelingen. Haar gestructureerde aanpak, gebouwd op beheersmaatregelen 5.19, 5.20 en 5.22, leverde een duidelijke, auditeerbare audittrail op.
De COBIT 2019-auditor: vanuit een governanceperspectief wilde deze auditor de koppeling met bedrijfsdoelstellingen zien. Hij vroeg hoe leveranciersrisico werd gerapporteerd aan het uitvoerend risicocomité. Anya presenteerde haar risicoregister, waarin zichtbaar was hoe de risicoscore van de leverancier was bepaald en hoe deze aansloot op de algemene risicobereidheid van de organisatie.
De NIS2-beoordelaar: deze persoon had een scherpe focus op systemisch risico voor essentiële diensten. Het ging hem niet alleen om het contract; hij wilde weten wat er zou gebeuren als de leverancier volledig offline ging. Anya nam hem mee door haar bedrijfscontinuïteitsplan, dat inmiddels een sectie bevatte over falen van kritieke leveranciers, ontwikkeld in lijn met de principes van ISO/IEC 22301:2019.
De GDPR-auditor: omdat de leverancier locatiegegevens verwerkte, richtte deze auditor zich direct op gegevensbescherming. Hij vroeg om de verwerkersovereenkomst (DPA) en bewijsmateriaal van haar due diligence om zeker te stellen dat de leverancier “voldoende garanties” bood zoals vereist door Article 28. Omdat haar proces privacy vanaf het begin had geïntegreerd, was de DPA robuust.
Dit auditperspectief vanuit meerdere invalshoeken laat zien dat een goed geïmplementeerd ISMS op basis van ISO/IEC 27001:2022 niet slechts aan één norm voldoet. Het creëert een weerbare, verdedigbare positie binnen het volledige regelgevingslandschap. De onderstaande tabel vat samen hoe deze stappen auditeerbaar bewijsmateriaal opleveren voor elke inspectie.
| Stap | Beleids-/beheersmaatregelreferentie | NIS2-mapping | GDPR-mapping | DORA-mapping | Actiebewijsmateriaal |
|---|---|---|---|---|---|
| Leveranciers indelen | 5.19, Blueprint S10/S23 | Article 21 | Article 28 | Art. 28-30 | Risicogebaseerd ingedeelde leveranciersinventaris in het ISMS. |
| Beveiligingsclausules in contracten | 5.20, ISO/IEC 27036-2 | Article 22 | Article 28(3) | Art. 30 | Voorbeeldcontracten met beveiligingsaddenda, SLA’s. |
| Doorlopende beoordeling | 5.22, ISO/IEC 22301 | Article 21 | Article 32 | Art. 31 | Notulen, prestatiedashboards, auditlogboeken. |
| Bepalingen inzake gegevensbescherming | 5.20, ISO/IEC 27701 | Recital 54 | Arts. 28, 32 | Art. 30 | Ondertekende verwerkersovereenkomsten (DPA’s). |
| Incidentmelding | 5.22, ISO/IEC 27036-2 | Article 23 | Arts. 33, 34 | Art. 31 | Incidentlogboeken van leveranciers, communicatieregistraties. |
| Exit/beëindiging | 5.20, ISO/IEC 27001:2022 A.5.11 | Relevant voor weerbaarheid | Article 28(3) | Art. 30 | Certificaten voor gegevensvernietiging, offboardingchecklists. |
Uw actiedraaiboek
Anya’s verhaal is niet uniek. CISO’s en compliancemanagers in de hele EU staan voor dezelfde uitdaging. De dreiging van boetes door toezichthouders en de persoonlijke aansprakelijkheid die NIS2 oplegt, maken risico’s in de toeleveringsketen tot een zakelijke topprioriteit. Het goede nieuws is dat de weg vooruit duidelijk is. Door gebruik te maken van de gestructureerde, risicogebaseerde aanpak van ISO/IEC 27001:2022 kunt u een programma bouwen dat zowel compliant als daadwerkelijk weerbaar is.
Wacht niet tot een incident u dwingt tot actie. Begin vandaag met het opzetten van uw NIS2-conforme raamwerk voor de toeleveringsketen:
- Richt governance in: gebruik Clarysec’s Beleid voor derde partijen en leveranciersbeveiliging - mkb of enterprisesjablonen om uw operationele spelregels te definiëren.
- Ken uw ecosysteem: pas de classificatiecriteria uit de Zenith Blueprint toe om uw kritieke leveranciers met hoog risico te identificeren en in te delen.
- Versterk uw contracten: audit uw bestaande leveranciersovereenkomsten aan de hand van de vereisten van ISO/IEC 27001:2022 beheersmaatregel 5.20 en gebruik de guidance voor naleving over meerdere kaders in Zenith Controls om te voldoen aan de verwachtingen van NIS2, DORA en GDPR.
- Implementeer continue monitoring: plan uw eerste kwartaalbeoordeling van beveiliging met uw meest kritieke leverancier en gebruik onze checklist als leidraad. Documenteer alle bevindingen in uw ISMS.
- Bereid auditbewijsmateriaal voor: verzamel voorbeeldcontracten, beoordelingsnotulen, incidentlogboeken en risicobeoordelingen die per kritieke leverancier aan de kernbeheersmaatregelen zijn gekoppeld.
Uw toeleveringsketen hoeft niet uw zwakste schakel te zijn. Met het juiste raamwerk, de juiste processen en de juiste tools kunt u deze omvormen tot een bron van kracht en een hoeksteen van uw cybersecuritystrategie.
Klaar om een toeleveringsketen te bouwen die toezichthouders én het bestuur overtuigt? Download vandaag nog de Clarysec Zenith Blueprint en versnel uw traject naar naleving en weerbaarheid.
Frequently Asked Questions
About the Author

Igor Petreski
Compliance Systems Architect, Clarysec LLC
Igor Petreski is a cybersecurity leader with over 30 years of experience in information technology and a dedicated decade specializing in global Governance, Risk, and Compliance (GRC).Core Credentials & Qualifications:• MSc in Cyber Security from Royal Holloway, University of London• PECB-Certified ISO/IEC 27001 Lead Auditor & Trainer• Certified Information Systems Auditor (CISA) from ISACA• Certified Information Security Manager (CISM) from ISACA • Certified Ethical Hacker from EC-Council


