De beveiliging van leveranciers en ketenpartners is onder NIS2 geen randonderwerp meer. Supply chain security maakt expliciet onderdeel uit van de maatregelen waarmee organisaties cyberrisico’s moeten beheersen.
Het recente beveiligingsincident bij CEVA Logistics laat zien waarom.
CEVA is een internationale logistieke dienstverlener die onder andere werkzaamheden uitvoert voor organisaties zoals bol en de Bijenkorf. Nadat bij CEVA een beveiligingsincident was vastgesteld, moesten ook deze organisaties klanten informeren omdat persoonsgegevens die voor de logistieke dienstverlening bij CEVA aanwezig waren mogelijk toegankelijk waren geweest voor onbevoegden.
De systemen van bol zelf waren volgens bol niet getroffen.
Juist daarin zit de belangrijkste les voor bestuurders, leden van een Raad van Toezicht en commissarissen:
uw organisatie hoeft niet zelf te worden gehackt om toch door een cyberincident te worden geraakt.
Onder NIS2 moet daarom niet alleen worden gekeken naar de beveiliging van de eigen organisatie, maar ook naar de risico’s binnen de supply chain: leveranciers, IT-partners, cloudproviders, softwareleveranciers, logistieke dienstverleners en andere partijen waarvan de organisatie afhankelijk is.
Wat betekent NIS2 supply chain security?
NIS2 benadert cybersecurity nadrukkelijk als een ketenvraagstuk.
Organisaties zijn tegenwoordig sterk afhankelijk van leveranciers voor onder andere:
IT-beheer;
cloudplatforms;
software;
hosting;
salarisverwerking;
gegevensverwerking;
logistiek;
back-updiensten;
netwerkbeheer;
SaaS-platforms;
en andere kritieke processen.
Een beveiligingsincident bij één van deze partijen kan daardoor rechtstreeks gevolgen hebben voor de opdrachtgever.
Binnen NIS2 moeten organisaties daarom passende maatregelen nemen voor de beveiliging van hun toeleveringsketen. Daarbij gaat het niet alleen om technische beveiliging, maar ook om de kwaliteit, betrouwbaarheid en weerbaarheid van leveranciers en dienstverleners.
Voor bestuur en toezicht betekent dit onder andere dat inzicht nodig is in:
welke leveranciers bedrijfskritisch zijn;
welke leveranciers toegang hebben tot gevoelige gegevens of systemen;
welke afhankelijkheden bestaan;
welke beveiligingseisen contractueel zijn vastgelegd;
hoe incidenten worden gemeld;
hoe continuïteit en herstel zijn geregeld;
en hoe wordt vastgesteld dat leveranciers hun afspraken daadwerkelijk naleven.
Daarmee wordt leveranciersmanagement onder NIS2 niet uitsluitend een taak van inkoop of IT.
Het is onderdeel van de bestuurlijke beheersing van cyberrisico.
Cyberaanval op CEVA: hoe ketenrisico zichtbaar wordt
CEVA Logistics verzorgt logistieke dienstverlening voor andere organisaties. Daarvoor verwerkt CEVA gegevens die nodig zijn voor onder andere opslag, fulfilment, verzending en bezorging.
Denk bijvoorbeeld aan:
naam;
adres;
postcode;
telefoonnummer;
e-mailadres;
orderinformatie;
afleverinformatie;
retourinformatie.
Dat maakt een logistieke dienstverlener niet alleen onderdeel van de fysieke keten, maar ook van de digitale informatieketen.
Een consument doet zaken met een webwinkel, maar voor de uitvoering van de bestelling worden gegevens gedeeld met andere partijen.
Vereenvoudigd ziet die keten er zo uit:
Consument
↓
Webwinkel
↓
Logistieke dienstverlener
↓
Vervoerder
↓
Consument
De persoonsgegevens bewegen daarbij mee door de keten.
Wordt één partij in die keten getroffen, dan kan de impact zich verspreiden naar organisaties die technisch helemaal niet zijn binnengedrongen.
Dat is precies waarom NIS2 supply chain security relevant is.
Is het CEVA-incident een supply chain attack?
In de media wordt bij dit soort incidenten vaak gesproken over een supply chain attack.
Technisch is enige nuance verstandig.
Bij een klassieke supply chain attack wordt een leverancier bewust gecompromitteerd om vervolgens diens klanten aan te vallen.
Een bekend voorbeeld is:
Aanvaller
↓
Softwareleverancier
↓
Besmette software-update
↓
Klanten installeren update
↓
Klanten worden gecompromitteerd
Bij CEVA is voor zover publiek bekend niet aangetoond dat aanvallers via CEVA vervolgens de systemen van bol of de Bijenkorf zijn binnengedrongen.
Het gaat daarom waarschijnlijk zuiverder om een ketenincident of third-party compromise.
Maar vanuit bestuur en toezicht maakt dat verschil in terminologie nauwelijks uit.
De essentie blijft hetzelfde:
Een beveiligingsincident bij een leverancier kan rechtstreeks risico veroorzaken voor uw eigen organisatie.
Daarom hoort leveranciersrisico thuis in dezelfde bestuurlijke risicodiscussie als continuïteit, privacy, fraude, reputatie, compliance en financiële risico’s.
De belangrijkste bestuursvraag: van welke leveranciers zijn wij werkelijk afhankelijk?
Veel organisaties beschikken inmiddels over een leveranciersregister.
Dat is nuttig, maar een lijst met tientallen of honderden leveranciers zegt op zichzelf weinig over het werkelijke risico.
De veel belangrijkere vraag is:
Welke leveranciers kunnen onze organisatie het hardst raken wanneer zij morgen worden gehackt of volledig uitvallen?
Denk bijvoorbeeld aan een organisatie waarbij:
de volledige IT-omgeving door één IT-dienstverlener wordt beheerd;
het primaire bedrijfsproces afhankelijk is van één SaaS-platform;
alle cliëntgegevens bij één cloudleverancier staan;
de financiële administratie extern wordt uitgevoerd;
één logistieke dienstverlener verantwoordelijk is voor vrijwel alle distributie;
een softwareleverancier beheerrechten heeft op kritieke systemen.
Niet alle leveranciers verdienen dezelfde aandacht.
De bestuurlijke uitdaging is daarom vooral om leveranciers te classificeren en prioriteren.
Waarom leveranciersrisico onder NIS2 bestuurlijke aandacht vraagt
NIS2 maakt duidelijk dat een organisatie haar cybersecurityverantwoordelijkheid niet volledig kan uitbesteden.
Een IT-dienstverlener kan verantwoordelijk zijn voor technisch beheer.
Een cloudleverancier kan verantwoordelijk zijn voor een platform.
Een logistieke dienstverlener kan persoonsgegevens verwerken.
Maar de organisatie zelf blijft verantwoordelijk voor het beheersen van de risico’s die uit die afhankelijkheden voortkomen.
Voor bestuurders betekent dit dat leveranciersrisico onderdeel moet zijn van de reguliere risicobeheersing.
Voor een Raad van Toezicht of Raad van Commissarissen betekent het dat moet worden vastgesteld of het bestuur hier aantoonbaar grip op heeft.
Een toezichthouder hoeft daarvoor niet te vragen welke firewall een leverancier gebruikt.
Veel relevantere vragen zijn:
Welke leveranciers kunnen onze primaire dienstverlening stilleggen?
Welke leveranciers verwerken onze meest gevoelige informatie?
Welke leveranciers hebben toegang tot onze systemen?
Hoe beoordelen wij hun beveiligingsniveau?
Welke incidentmeldtermijnen hebben we afgesproken?
Wat doen we als een kritieke leverancier meerdere dagen uitvalt?
Welke risico’s accepteren we bewust?
Welke verbetermaatregelen staan nog open?
Dat zijn bij uitstek vragen voor de boardroom.
Wat kan er misgaan bij een leverancier?
Bij leveranciersrisico wordt vaak als eerste gedacht aan een datalek.
Maar de mogelijke impact is veel breder.
Vertrouwelijkheid
Gegevens kunnen toegankelijk worden voor onbevoegden.
Bijvoorbeeld:
persoonsgegevens;
cliëntinformatie;
financiële informatie;
contracten;
bedrijfsgeheimen;
personeelsinformatie.
Beschikbaarheid
Een leverancier kan uitvallen.
Dan ontstaan bijvoorbeeld vragen als:
kunnen medewerkers nog werken?
kunnen klanten nog bestellen?
kunnen goederen nog worden geleverd?
kunnen salarissen nog worden betaald?
kunnen cliënten nog worden geholpen?
kan de organisatie haar primaire dienstverlening voortzetten?
Integriteit
Een aanvaller kan informatie of processen beïnvloeden.
Denk aan:
betalingen;
orders;
administraties;
configuraties;
software;
klantgegevens;
financiële transacties.
Voor bestuur en toezicht zijn alle drie relevant.
Cybersecurity is daardoor niet alleen een privacyvraagstuk.
Het is ook een continuïteits-, governance- en ondernemingsrisico.
“Maar onze leverancier is ISO 27001-gecertificeerd”
Een ISO 27001-certificering is waardevol.
Maar een certificaat betekent niet dat een leverancier niet kan worden gehackt.
Ook gecertificeerde organisaties kunnen beveiligingsincidenten krijgen.
Een certificering kan aantonen dat binnen een bepaalde scope een informatiebeveiligingsmanagementsysteem is ingericht.
Dat is belangrijk, maar het ontslaat een opdrachtgever niet van de verantwoordelijkheid om kritisch te kijken naar de eigen afhankelijkheid.
Voor bestuur en toezicht is daarom een belangrijk onderscheid:
certificering geeft vertrouwen, maar vervangt geen risicobeoordeling.
Relevante vragen blijven bijvoorbeeld:
valt de gebruikte dienstverlening binnen de certificeringsscope?
welke onderaannemers gebruikt de leverancier?
hoe wordt continuïteit geregeld?
welke toegang heeft de leverancier tot onze systemen?
wanneer worden incidenten gemeld?
hoe wordt aangetoond dat back-ups daadwerkelijk herstelbaar zijn?
welke relevante auditbevindingen staan nog open?
hoe ziet een exit eruit?
Dat zijn geen technische details.
Het zijn beheersingsvragen.
Hoe weet een bestuurder of leveranciersrisico voldoende wordt beheerst?
Een bestuurder hoeft geen cybersecurityspecialist te worden.
Een commissaris of toezichthouder evenmin.
Maar bestuur en toezicht moeten wél kunnen beoordelen of de organisatie aantoonbaar grip heeft op een materieel risico.
Daarbij gaat het minder om technische details en meer om structuur en bewijs.
Een volwassen organisatie zou ten minste antwoord moeten kunnen geven op de volgende vragen.
Welke leveranciers zijn bedrijfskritisch?
Niet alleen een leverancierslijst, maar een duidelijke classificatie.
Bijvoorbeeld:
kritiek;
hoog;
regulier.
Een leverancier kan bijvoorbeeld als kritiek worden aangemerkt wanneer uitval binnen enkele uren directe gevolgen heeft voor de primaire dienstverlening.
Welke gegevens en systemen zijn bij leveranciers ondergebracht?
Het bestuur hoeft niet ieder technisch detail te kennen.
Maar wel globaal:
waar gevoelige persoonsgegevens worden verwerkt;
waar primaire applicaties draaien;
welke leveranciers bedrijfsgevoelige informatie bezitten;
welke derde partijen een belangrijke rol spelen in kritieke processen.
Welke toegang hebben leveranciers?
Een leverancier die alleen kantoorartikelen levert heeft een ander risicoprofiel dan een IT-partner met administratorrechten.
Relevante vragen zijn:
heeft de leverancier beheerrechten?
heeft de leverancier toegang tot productieomgevingen?
bestaan permanente accounts?
bestaan service-accounts?
worden toegangsrechten periodiek gecontroleerd?
wordt toegang ingetrokken wanneer deze niet meer nodig is?
Wat gebeurt er wanneer de leverancier uitvalt?
Dit is een continuïteitsvraag.
Bestuurders zouden bijvoorbeeld moeten weten:
wat gebeurt er na vier uur uitval?
wat gebeurt er na 24 uur?
wat gebeurt er na drie dagen?
bestaat een alternatief proces?
zijn herstelafspraken vastgelegd?
zijn deze scenario’s ooit getest?
Hoe weten we dat afspraken werkelijk worden nagekomen?
Een contract alleen is geen beheersmaatregel.
Daarom zijn bijvoorbeeld relevant:
audits;
assurance-rapportages;
certificeringen;
periodieke evaluaties;
incidentrapportages;
security-KPI’s;
verbeterplannen;
aantoonbare opvolging van bevindingen.
Incidentmelding: snelheid telt
Bij een cyberincident bij een leverancier ontstaat vrijwel onmiddellijk een tweede probleem:
de opdrachtgever heeft informatie nodig.
Wat is er gebeurd?
Welke gegevens zijn geraakt?
Wanneer begon het incident?
Zijn onze gegevens betrokken?
Is de aanvaller nog aanwezig?
Moeten wij onze klanten informeren?
Hebben wij zelf een meldplicht?
Kunnen onze processen doorgaan?
Als een leverancier pas laat met duidelijke informatie komt, heeft dat rechtstreeks gevolgen voor de opdrachtgever.
Daarom hoort incidentmelding niet alleen in een algemeen contractartikel te staan.
Bij kritieke leveranciers moet duidelijk zijn:
wanneer incidenten moeten worden gemeld;
aan wie;
welke informatie minimaal moet worden verstrekt;
hoe vaak updates volgen;
wie verantwoordelijk is voor communicatie;
en welke medewerking bij onderzoek wordt verwacht.
Wat betekent NIS2 supply chain voor de Raad van Toezicht en Raad van Commissarissen?
Toezicht op cybersecurity betekent niet dat een Raad van Toezicht zelf technische beveiligingsmaatregelen moet beoordelen.
De toezichthoudende rol ligt vooral bij het beoordelen van de kwaliteit van de bestuurlijke beheersing.
Een Raad van Toezicht of Raad van Commissarissen kan bijvoorbeeld vragen:
Hebben wij onze kritieke leveranciers geïdentificeerd?
Welke leverancier vormt op dit moment ons grootste cyber- of continuïteitsrisico?
Is voor kritieke leveranciers een actuele risicoanalyse uitgevoerd?
Welke leveranciers hebben toegang tot onze meest gevoelige gegevens?
Welke leveranciers kunnen onze primaire dienstverlening stilleggen?
Wanneer is voor het laatst getest wat er gebeurt wanneer zo’n leverancier uitvalt?
Hoe snel moeten kritieke leveranciers een cyberincident melden?
Hoe wordt gecontroleerd of beveiligingsafspraken daadwerkelijk worden nagekomen?
Welke relevante tekortkomingen staan nog open?
Wie accepteert het restrisico?
Dat zijn geen technische vragen.
Het zijn governancevragen.
En juist daarom horen ze thuis in de boardroom.
Welke informatie hoort periodiek op de bestuurstafel?
Een bestuur heeft weinig aan een technisch dashboard met honderden security-events.
Dat geeft veel informatie, maar weinig bestuurlijke sturing.
Veel relevanter zijn bijvoorbeeld:
aantal kritieke leveranciers;
leveranciers met verhoogd risico;
openstaande high-risk bevindingen;
incidenten bij leveranciers;
kritieke contracten zonder voldoende securityvoorwaarden;
status van continuïteitstesten;
leveranciers zonder actuele assurance;
leveranciers zonder realistisch exitplan;
achterstallige verbetermaatregelen;
geaccepteerde restrisico’s.
Daarmee kan bestuur daadwerkelijk sturen.
Wat moet toezicht vervolgens beoordelen?
Een Raad van Toezicht of Raad van Commissarissen hoeft niet iedere leverancier afzonderlijk te beoordelen.
De toezichthoudende vraag is vooral:
werkt het systeem van beheersing?
Daarvoor kan toezicht onder andere beoordelen:
bestaat een leveranciersbeleid?
worden kritieke leveranciers geïdentificeerd?
worden risico’s vooraf beoordeeld?
worden afspraken contractueel vastgelegd?
worden leveranciers periodiek geëvalueerd?
bestaat escalatie bij onvoldoende beheersing?
wordt over relevante risico’s gerapporteerd?
worden openstaande tekortkomingen aantoonbaar opgevolgd?
worden geaccepteerde risico’s expliciet gemaakt?
Wanneer het antwoord op meerdere van deze vragen “nee” of “onbekend” is, is dat op zichzelf al een relevante bestuurlijke bevinding.
ClickFix: technisch interessant, maar bestuurlijk is de oorzaak secundair
Bij het CEVA-incident is publiek niet bevestigd welke aanvalstechniek de aanvallers hebben gebruikt.
Er is daarom geen basis om te stellen dat CEVA via ClickFix is gecompromitteerd.
ClickFix is wel een actuele aanvalsmethode waarbij een gebruiker bijvoorbeeld via een nep-CAPTCHA wordt misleid om zelf een kwaadaardige opdracht op de computer uit te voeren.
Maar vanuit de boardroom is de precieze technische route uiteindelijk niet de belangrijkste vraag.
De bestuurlijke vraag is:
Is onze organisatie voorbereid op het scenario dat een medewerker, leverancier of ketenpartner wordt gecompromitteerd?
Of de eerste toegang nu ontstaat door:
phishing;
gestolen credentials;
een kwetsbaarheid;
ClickFix;
malware;
een verkeerd geconfigureerd systeem;
de bestuurlijke consequenties zijn vergelijkbaar.
De organisatie moet kunnen:
detecteren → reageren → communiceren → herstellen → leren.
Van cyberincident naar bestuurlijke impact
Een technisch incident kan zich snel ontwikkelen tot een bestuurlijk probleem.
Bijvoorbeeld:
Cyberincident bij leverancier
↓
Persoonsgegevens mogelijk geraakt
↓
Operationele verstoring
↓
Klanten informeren
↓
Mogelijke meldplicht
↓
Media-aandacht
↓
Reputatieschade
↓
Financiële gevolgen
↓
Vragen vanuit bestuur en toezicht
Cybersecurity is daarom geen afzonderlijk IT-risico.
Het raakt:
continuïteit;
compliance;
privacy;
reputatie;
financiën;
aansprakelijkheid;
governance.
Checklist NIS2 supply chain voor bestuur, RvT en RvC
Gebruik onderstaande checklist bijvoorbeeld periodiek bij de bespreking van informatiebeveiliging, continuïteit of risicomanagement.
Kritieke leveranciers
☐ Wij weten welke leveranciers bedrijfskritisch zijn.
☐ Kritieke leveranciers zijn aantoonbaar geclassificeerd.
☐ Wij weten welke primaire processen afhankelijk zijn van deze leveranciers.
☐ Wij kennen relevante afhankelijkheden van onderaannemers en subverwerkers.
Data en toegang
☐ Wij weten welke leveranciers gevoelige of bijzondere gegevens verwerken.
☐ Wij weten welke leveranciers toegang hebben tot kritieke systemen.
☐ Beheer- en administratorrechten van leveranciers zijn inzichtelijk.
☐ Toegangsrechten worden periodiek beoordeeld.
☐ Niet langer noodzakelijke toegang wordt tijdig ingetrokken.
Risicobeoordeling
☐ Voor kritieke leveranciers is een actuele risicoanalyse uitgevoerd.
☐ Cybersecurityrisico’s worden beoordeeld vóór contractering.
☐ Risico’s worden opnieuw beoordeeld bij grote wijzigingen of incidenten.
☐ Voor ieder relevant leveranciersrisico is een eigenaar aangewezen.
☐ Restrisico’s worden expliciet beoordeeld en geaccepteerd.
Contractuele afspraken
☐ Securityverplichtingen zijn concreet vastgelegd.
☐ Incidentmeldtermijnen zijn afgesproken.
☐ Privacy- en verwerkersafspraken zijn actueel.
☐ Audit- of informatierechten zijn vastgelegd.
☐ Afspraken over subleveranciers zijn aanwezig.
☐ Exit en overdraagbaarheid zijn contractueel geregeld.
Continuïteit
☐ Voor kritieke leveranciers is bepaald wat uitval betekent.
☐ RTO en RPO zijn waar relevant vastgesteld.
☐ Er bestaan alternatieve processen of noodscenario’s.
☐ Back-up en herstel worden aantoonbaar getest.
☐ Wij weten wat er gebeurt bij 4 uur, 24 uur en 72 uur uitval.
Assurance en toezicht
☐ Relevante certificeringen worden gecontroleerd op scope en geldigheid.
☐ Kritieke leveranciers leveren periodiek assurance of andere bewijslast.
☐ Belangrijke bevindingen worden aantoonbaar opgevolgd.
☐ Management rapporteert periodiek over leveranciersrisico.
☐ Ernstige tekortkomingen worden geëscaleerd naar bestuur.
Incidentmanagement
☐ Kritieke leveranciers weten wie zij bij ons moeten waarschuwen.
☐ Onze organisatie weet wie intern beslist bij een leveranciersincident.
☐ Meldplichten en communicatieroutes zijn vooraf bepaald.
☐ Leveranciersincidenten worden meegenomen in incidentoefeningen.
☐ Na een incident vindt evaluatie en verbetering plaats.
Bestuurlijke borging
☐ Supply chain-risico maakt onderdeel uit van de periodieke cyberrisicorapportage.
☐ Kritieke leveranciers en belangrijkste afhankelijkheden zijn bekend bij het bestuur.
☐ Materiële leveranciersrisico’s worden aan RvT of RvC gerapporteerd.
☐ Er is duidelijk vastgelegd wie risico-eigenaar is.
☐ Openstaande tekortkomingen bij kritieke leveranciers hebben een eigenaar en deadline.
☐ Restrisico’s worden aantoonbaar geaccepteerd op het juiste niveau.
Vijf vragen die iedere bestuurder morgen kan stellen
Wie het onderwerp direct op de agenda wil zetten, kan beginnen met vijf eenvoudige vragen:
1. Welke leveranciers vormen ons grootste cyber- of continuïteitsrisico?
2. Welke van deze leveranciers hebben toegang tot onze meest kritieke gegevens of systemen?
3. Wat gebeurt er met onze dienstverlening wanneer één van hen 24 uur uitvalt?
4. Hoe snel moeten zij ons informeren wanneer zij zelf een cyberincident hebben?
5. Hoe weten wij dat de afgesproken beveiligingsmaatregelen daadwerkelijk werken?
Als deze vragen niet eenvoudig kunnen worden beantwoord, is dat een goede aanleiding om leveranciersmanagement opnieuw te beoordelen.
Conclusie: NIS2 supply chain vraagt aantoonbare bestuurlijke beheersing
Het incident bij CEVA laat vooral zien dat informatiebeveiliging niet ophoudt bij de grenzen van de eigen organisatie.
Uw leveranciers zijn onderdeel van uw risicoprofiel.
Hun systemen verwerken uw gegevens.
Hun medewerkers kunnen toegang hebben tot uw omgeving.
Hun continuïteit kan bepalend zijn voor uw dienstverlening.
En hun beveiligingsincident kan uiteindelijk uw klanten, reputatie en bestuurlijke verantwoordelijkheid raken.
Voor bestuurders en toezichthouders is daarom niet de belangrijkste vraag hoe een aanvaller technisch exact bij CEVA is binnengekomen.
De belangrijkere vraag is:
Weten wij welke leveranciers ons kunnen raken — en hebben wij aantoonbaar geregeld wat we doen als dat gebeurt?
Dat is de kern van volwassen NIS2 supply chain security.
Niet iedere aanval kan worden voorkomen.
Maar afhankelijkheden kunnen wel zichtbaar worden gemaakt, verantwoordelijkheden kunnen worden vastgelegd, leveranciers kunnen worden beoordeeld en organisaties kunnen zich voorbereiden op het moment dat een belangrijke ketenpartner wordt getroffen.
En juist daar ligt de verantwoordelijkheid van bestuur en toezicht.