Kantyra
Kantyra
Kantyra · 25-07-2026 · 11 min leestijd
Jarenlang was leveranciersmanagement in de informatiebeveiliging (IB) het register dat je invulde voor de auditor en daarna een jaar niet aanraakte. De cijfers laten zien hoe onverstandig dat is geworden. Toen het Europese agentschap voor cyberbeveiliging (ENISA) in 2021 vierentwintig ketenaanvallen ontleedde, bleek 62 procent van de aanvallen misbruik te maken van het vertrouwen dat de klant in zijn leverancier stelde. De aanvaller komt binnen via de partij die je juist had binnengelaten. Met de Cyberbeveiligingswet (Cbw) en met de Europese verordening digitale operationele weerbaarheid (DORA) is vrijblijvendheid bovendien juridisch voorbij, want beide stellen eisen aan de beheersing van je keten. Tijd dus om het onderwerp serieus in te richten. Maar dan begint de spraakverwarring, want "leveranciersmanagement" betekent in drie delen van de organisatie drie verschillende dingen, en daarbovenop zweeft nog een vierde term, third party risk management (TPRM). Dit artikel zet ze naast elkaar.
Neem een organisatie die haar salarisverwerking heeft uitbesteed. Met die ene leverancier lopen drie totaal verschillende gesprekken, en elk gesprek heeft een eigen eigenaar, een eigen ritme en een eigen register.
Het eerste gesprek voert inkoop. Daar gaat het over het contract, de prijs, de looptijd, de leveringsvoorwaarden en de vraag of de organisatie krijgt waarvoor ze betaalt. Dit vak heet contractmanagement of vendormanagement, het leeft in een contractenregister, en het kent zijn eigen momenten, namelijk de aanbesteding, de verlenging en de onderhandeling. De vraag die dit gesprek beantwoordt is of de afspraken kloppen en worden nagekomen.
Het tweede gesprek voert de IT-afdeling. In de Information Technology Infrastructure Library (ITIL) en ISO/IEC 20000 heet dit supplier management, en het gaat over de dagelijkse dienstverlening. Worden de afgesproken beschikbaarheidsniveaus gehaald, hoe snel worden incidenten opgepakt, hoe verlopen wijzigingen en wie escaleert wanneer het misgaat. Dit gesprek leeft in de servicemanagementomgeving, naast de configuratiedatabase (CMDB), en het ritme is dat van de operatie, dus wekelijks of maandelijks. De vraag is hier of de dienst doet wat de gebruikers nodig hebben.
Het derde gesprek is dat van de informatiebeveiliging, en dat stelt een wezenlijk andere vraag. Welk risico loopt onze informatie doordat deze leverancier erbij kan, hem verwerkt of hem host? Wat gebeurt er met de vertrouwelijkheid, integriteit en beschikbaarheid van onze gegevens als deze partij wordt gecompromitteerd, uitvalt of failliet gaat? ISO/IEC 27001 wijdt er vier beheersmaatregelen aan, 5.19 tot en met 5.22, van beleid en contractuele afspraken tot het bewaken van veranderingen bij de leverancier. Dit gesprek hoort thuis in je managementsysteem voor informatiebeveiliging (ISMS), met de chief information security officer (CISO) als procesbegeleider en een eigenaar per leverancier.
De drie gesprekken lijken op elkaar omdat ze over dezelfde partij gaan, maar ze verschillen in alles wat ertoe doet. Wie ze in één register propt, krijgt een lijst die voor iedereen net niet werkt. Wie ze helemaal los van elkaar laat bestaan, mist de verbanden, want een contractverlenging is hét moment om beveiligingseisen af te dwingen, en een reeks operationele incidenten is vaak het eerste signaal dat er bij de leverancier iets structureels mis is. De kunst is dus om drie registers hun eigen werk te laten doen en de momenten te verbinden.
Veel CISO's worstelen met de vraag of third party risk management een aparte discipline is die ze er nog eens bij moeten inrichten. Het korte antwoord is nee. TPRM is de Angelsaksische naam voor hetzelfde werkveld, met twee accentverschillen die het kennen waard zijn.
Het eerste verschil zit in het woord "third party". Dat is breder dan "leverancier", want er vallen ook partijen onder die geen factuur sturen, zoals ketenpartners, franchisenemers, intermediairs en gratis diensten waar je gegevens doorheen lopen. Voor je risicobeeld is dat onderscheid reëel: de gemeenschappelijke regeling waarmee je gegevens uitwisselt is geen leverancier, maar verdient dezelfde beoordeling.
Het tweede verschil zit in de breedte van het risicobegrip. TPRM-programma's bij grote organisaties kijken naast informatiebeveiliging ook naar continuïteit, naleving, financiële gezondheid en reputatie van de derde partij. IB-leveranciersmanagement is in die opvatting de informatiebeveiligingskern van TPRM, en die kern is wat ISO 27001 en de Cbw van je vragen. DORA zit er net anders in. De verordening beperkt zich tot ICT-dienstverleners, maar vraagt binnen die groep juist meer dan informatiebeveiliging alleen, want continuïteit, concentratierisico en een uitstapstrategie horen er nadrukkelijk bij. Alleen reputatie blijft ook onder DORA een vrijwillige toevoeging.
De praktische conclusie is dezelfde als bij de bedrijfsmiddelen uit een eerder artikel in deze reeks. Richt geen twee processen in. Houd één leveranciersregister aan op risiconiveau, geef elke partij een eigenaar en een kritikaliteit, en hang er per kader de kenmerken aan die dat kader vraagt. Of je het geheel dan TPRM noemt of leveranciersmanagement is een kwestie van huisstijl, niet van inhoud.
Leveranciersrisico is een van de gebieden waar de economie van de informatiebeveiliging meer verklaart dan de techniek. Kunreuther en Heal lieten in 2003 zien wat er gebeurt wanneer jouw veiligheid afhangt van de investeringen van anderen, een situatie die zij interdependent security noemden. Hun speltheoretische analyse kent evenwichten waarin niemand investeert, omdat de bescherming die je koopt weinig waard is zolang je buren niets doen. Anderson en Moore werkten in Science uit waarom informatiebeveiliging zo vaak economisch faalt in plaats van technisch, want wie beveiligt draagt de kosten, terwijl een deel van de schade bij anderen valt. Samen verklaren die twee inzichten waarom ketenbeveiliging decennialang een ondergeschoven kindje kon blijven, en waarom de wetgever met de Europese netwerk- en informatiebeveiligingsrichtlijn (NIS2) en DORA de prikkels verlegt: de zorgplicht maakt het risico van je leverancier tot jouw aantoonbare verantwoordelijkheid.
Het vakgebied zelf is jong. Boyson beschreef in 2014, op basis van een meerjarig onderzoeksprogramma voor het Amerikaanse National Institute of Standards and Technology (NIST), cyber supply chain risk management als een discipline in opbouw, waarin de meeste organisaties nog ad hoc opereerden. Ghadge en collega's kwamen in hun systematische literatuurstudie tot een vergelijkbare conclusie, want onderzoek naar cyberrisico tússen organisaties bleek schaars vergeleken met onderzoek binnen de eigen muren, terwijl juist de koppelvlakken het risico dragen.
Het meest praktijkgerichte onderzoek is recent. Slapničar, Vidmar en Tsen bouwden op basis van 33 interviews en een enquête onder 53 beveiligingsexperts een procestheorie van leveranciersbeoordeling. Twee bevindingen verdienen aandacht. Ten eerste werkt het proces, want een gestructureerde beoordeling onderscheidt risicovolle van minder risicovolle leveranciers. Ten tweede werkt het alleen als de diepgang meebeweegt met de kritikaliteit van de leverancier, omdat niemand de capaciteit heeft om elke partij even zwaar te beoordelen. Uitvragen zonder differentiatie levert stapels onbeantwoorde vragenlijsten op en geen risicobeeld.
Daar hoort een nuchtere noot over certificaten bij. Lins, Schneider en Sunyaev lieten zien dat een certificaat een momentopname is, want tussen twee audits kan de werkelijkheid bij een clouddienst flink verschuiven. Een ISO 27001-certificaat van je leverancier is dus een zinnige eis en een goed startpunt, maar het vervangt je eigen beoordeling niet, en bij je meest kritieke leveranciers wil je aanvullend bewijs zien, zoals recente pentestresultaten of een assurancerapport.
De Cyberbeveiligingswet noemt de beveiliging van de toeleveringsketen met zoveel woorden als verplicht onderdeel van de zorgplicht, inclusief de beveiligingsaspecten in de relatie met directe leveranciers en dienstverleners. De maatregelen moeten evenredig zijn aan het risico, en daarmee is de kritikaliteitsindeling van je leveranciers geen administratieve luxe maar de onderbouwing van je evenredigheid. Het bestuur keurt de maatregelen goed en is erop aanspreekbaar.
DORA gaat voor financiële entiteiten aanzienlijk verder, zij het uitsluitend voor derde partijen die ICT-diensten leveren; niet-ICT-uitbesteding valt onder de aparte richtsnoeren van de Europese toezichthouders. Hoofdstuk V regelt het beheer van ICT-risico van derde aanbieders tot op contractniveau, met voorgeschreven contractbepalingen, een eigen artikel voor concentratierisico, een exitstrategie die ook het omvallen of terugzakken van de dienstverlener dekt, en het informatieregister over alle contractuele afspraken met ICT-dienstverleners, dat op verzoek naar de toezichthouder gaat. Daarmee vraagt DORA binnen zijn scope uitdrukkelijk meer dan informatiebeveiliging alleen, want continuïteit en vervangbaarheid wegen even zwaar mee. De meest kritieke ICT-dienstverleners komen bovendien onder rechtstreeks Europees toezicht te staan. Wie onder DORA valt, kan leveranciersmanagement dus niet meer beperken tot een jaarlijkse review, want het register zelf wordt een toezichtproduct.
In Kantyra is IB-leveranciersmanagement een doorlopende cyclus van zes stappen, en de afbeelding vat hem samen.
De volgorde is bewust risicogestuurd, precies zoals het onderzoek van Slapničar en collega's adviseert: de kritikaliteit uit stap 1 en 2 bepaalt hoe zwaar stap 3 en 4 uitvallen, zodat je capaciteit landt bij de leveranciers die er werkelijk toe doen.
De zes stappen doorlopen daarmee alle vier de fasen van het model achter Kantyra. Registreren en koppelen zijn Signaleren, want daar leg je de feiten vast. Toetsen, uitvragen en beoordelen vormen samen de fase Beoordelen, waarin het oordeel over de leverancier ontstaat. De bewakingsstap hoort bij Oplossen én Aantonen: de automatische taken en signalen borgen dat afspraken worden nagekomen, en de vastgelegde surveys, beoordelingen en reviewhistorie zijn precies het bewijs dat een auditor of toezichthouder wil zien. Leveranciersmanagement is dus geen registeronderhoud in de signaleringsfase, maar een cyclus door het hele model heen.
Wie dit leest en nog geen werkend proces heeft, hoeft niet te beginnen met een compleet register van tweehonderd partijen. Begin met de tien leveranciers waarvan een compromittering of uitval je primaire proces direct raakt, en doorloop voor die tien de zes stappen. Daarna groeit het register vanzelf mee met elke inkoop en elke Data Privacy Impact Analyse (DPIA) die een nieuwe verwerker aan het licht brengt. Het verschil tussen een ondergeschoven kindje en een werkend proces zit niet in de omvang van de lijst, maar in de vraag of iemand met een naam zich verantwoordelijk voelt voor elke regel erop.
Normatieve bronnen, rechtstreeks na te slaan:
Wetenschappelijke literatuur:
In een demo van 30 minuten lopen we het model door aan de hand van jouw situatie.
Plan een demo