Kort antwoord
Vraag niet iedere leverancier standaard om ISO 27001, een pentest en twintig beleidsdocumenten. Begin met de afhankelijkheid van jouw organisatie van de leverancier en het cyberrisico dat daaruit volgt. Heb je meerdere leveranciers, classificeer ze dan eerst op procesimpact, toegang, data, continuïteit en substitueerbaarheid. Bepaal daarna welk bewijs redelijk is om dat risico te beoordelen.
Voor een leverancier zonder toegang tot systemen of gevoelige informatie kan een beperkte zelfverklaring met enkele bewijsstukken voldoende zijn. Voor een kritieke SaaS-, cloud- of beheerleverancier kan zwaarder bewijs nodig zijn, zoals een geldig certificaat binnen passende scope, een onafhankelijk assurance-rapport, technische testrapportage of aanvullende contractuele en operationele onderbouwing.
De kern is:
afhankelijkheid → risico → verwachting → maatregel → bewijs → werking → periodieke herbeoordeling
Dat sluit aan op de actuele lijn van NCSC en RDI rond de Cyberbeveiligingswet: organisaties moeten ketenrisico's risicogebaseerd beheersen en maatregelen passend en evenredig kiezen.
Laatst gecontroleerd: 4 augustus 2026. De Cyberbeveiligingswet treedt op 15 augustus 2026 in werking. Dit artikel is praktische duiding en geen juridisch advies, audit of assuranceverklaring.
Waarom één standaardvragenlijst voor alle leveranciers vaak niet werkt
Een cateraar, salarisverwerker, Microsoft 365-beheerder en bedrijfskritische SaaS-leverancier leveren allemaal iets anders. Hun mogelijke impact op jouw organisatie verschilt daarom sterk.
Toch begint leveranciersbeoordeling in de praktijk vaak andersom: procurement stuurt iedereen dezelfde vragenlijst en vraagt dezelfde certificaten. Dat is administratief makkelijk, maar inhoudelijk zwak.
Een betere eerste vraag is:
Wat kan er bij ónze organisatie misgaan als deze leverancier uitvalt, wordt gehackt, verkeerd handelt of toegang misbruikt?
Daarna kijk je onder meer naar:
- welke bedrijfsprocessen afhankelijk zijn van de leverancier;
- welke data de leverancier verwerkt of kan benaderen;
- welke toegang de leverancier heeft tot accounts, systemen of netwerken;
- of de leverancier software, updates of beheerfunctionaliteit levert;
- hoe snel een verstoring merkbaar wordt;
- of er een alternatief of exitroute bestaat;
- welke onderaannemers of cloudpartijen achter de dienst zitten;
- welke schade ontstaat bij verlies van vertrouwelijkheid, integriteit of beschikbaarheid.
De RDI adviseert organisaties die onder de Cbw vallen expliciet om via een risicoanalyse vast te stellen welke processen en data van leveranciers afhankelijk zijn en zo kritieke leveranciers te identificeren.
Begin bij afhankelijkheid, niet bij het keurmerk
Gebruik voor iedere relevante leverancier eerst een compacte afhankelijkheidsanalyse.
| Vraag | Waarom dit telt | Voorbeeld van verhoogd risico |
|---|---|---|
| Heeft de leverancier toegang tot onze systemen? | Misbruik van toegang kan direct effect hebben | MSP met globale beheerrechten |
| Verwerkt de leverancier gevoelige data? | Datalek of ongeoorloofde wijziging kan grote impact hebben | Payroll- of zorg-SaaS |
| Is de dienst nodig voor een kritisch proces? | Uitval kan dienstverlening stilleggen | Identity provider of planningssysteem |
| Levert de partij software of updates? | Compromittering kan via de supply chain binnenkomen | Softwareleverancier met auto-update |
| Hebben we een praktisch alternatief? | Vendor lock-in vergroot continuïteitsrisico | Uniek platformsysteem zonder exportmogelijkheid |
| Gebruikt de leverancier kritieke subleveranciers? | Het risico kan verder in de keten liggen | SaaS op één cloudregio of externe supportpartij |
Op basis hiervan bepaal je niet of een leverancier 'veilig' is, maar hoeveel zekerheid je nodig hebt om het resterende risico verantwoord te beoordelen.
Een praktische bewijs-ladder
Niet elk bewijsstuk geeft dezelfde mate van vertrouwen. Zie de onderstaande ladder niet als officiële Cbw-classificatie, maar als praktische manier om bewijssterkte te onderscheiden.
| Niveau | Voorbeeld | Wat het vooral laat zien | Belangrijkste beperking |
|---|---|---|---|
| 1. Verklaring | Ja/nee-vragenlijst of leveranciersverklaring | Wat de leverancier zelf zegt | Geen onafhankelijke controle |
| 2. Onderbouwd bewijs | Beleid, screenshots, exports, testverslagen | Dat specifieke maatregelen aantoonbaar bestaan | Vaak momentopname en beperkte scope |
| 3. Gestructureerd kader | CYRA-zelfverklaring of vergelijkbare beoordeling | Dat maatregelen systematisch tegen een kader zijn bekeken | Zelfbeoordeling blijft zelfbeoordeling |
| 4. Certificering | ISO/IEC 27001-certificaat binnen relevante scope | Dat een managementsysteem onafhankelijk is gecertificeerd | Geen productgarantie; scope blijft cruciaal |
| 5. Assurance / gerichte onafhankelijke toetsing | SOC 2 Type II, passend assurance-rapport, audit of specifieke technische test | Meer onafhankelijke informatie over controls en soms werking over tijd | Reikwijdte en criteria verschillen sterk |
Hoe kritieker de leverancier, hoe minder logisch het is om uitsluitend op een onbevestigde zelfverklaring te vertrouwen.
Andersom is het ook onlogisch om een leverancier met nauwelijks digitale impact standaard een zwaar assurance-rapport te laten produceren.
Welk bewijs past bij laag, middel, hoog of kritisch risico?
Er bestaat geen universele Cbw-tabel die elke leverancier in vier vaste vakjes zet. Onderstaande indeling is daarom een praktisch beslismodel, geen wettelijke classificatie.
Lager risico
Kenmerken kunnen zijn:
- geen toegang tot interne systemen;
- geen of zeer beperkte persoonsgegevens;
- geen rol in kritieke bedrijfsprocessen;
- eenvoudig vervangbaar.
Mogelijk passend bewijs:
- korte securityvragenlijst;
- contact- en incidentafspraken;
- bevestiging van basismaatregelen waar relevant;
- contractuele geheimhouding en dataverwijdering.
Middel risico
Bijvoorbeeld een leverancier die bedrijfsdata verwerkt, maar geen brede beheerrechten heeft en redelijk vervangbaar is.
Mogelijk passend bewijs:
- onderbouwde vragenlijst;
- informatiebeveiligingsbeleid op hoofdlijnen;
- bewijs van MFA en toegangsbeheer;
- back-up- en herstelonderbouwing;
- incidentprocedure;
- subleveranciersoverzicht;
- relevante certificaten of self-assessmentresultaten.
Hoog risico
Denk aan SaaS met gevoelige informatie, een MSP met beheerrechten of een leverancier die essentieel is voor continuïteit.
Mogelijk passend bewijs:
- dezelfde onderdelen als hierboven, maar met meer diepgang;
- geldig ISO/IEC 27001-certificaat als dit passend is;
- controle van de certificaatscope;
- technische test- of pentestsamenvatting waar relevant;
- bewijs van hersteltests;
- logging- en incidentafspraken;
- contractuele securityverplichtingen;
- periodieke review en wijzigingsmelding.
Kritiek risico
Bij een zeer hoge afhankelijkheid is alleen een logo of verklaring meestal onvoldoende als basis voor risicobeheersing.
Afhankelijk van de context kan aanvullende zekerheid logisch zijn, zoals:
- diepere onafhankelijke assurance;
- een SOC 2 Type II of ander passend rapport;
- gerichte technische beoordeling;
- recht op audit of aanvullende informatie;
- aantoonbare continuïteits- en exitplannen;
- strengere incident- en wijzigingsafspraken;
- frequenter herbeoordelen.
Welke vorm werkelijk passend is, hangt af van de dienst en het risico. Een ISAE 3402-rapport is bijvoorbeeld niet automatisch een algemeen cybersecurityrapport; de doelstelling en scope van het rapport moeten bij jouw vraag passen.
Lees daarom ook: ISO 27001, SOC 2, ISAE 3402 of CYRA: wat bewijst het eigenlijk?.
Wat vraag je concreet per beveiligingsthema?
Een sterke leveranciersbeoordeling vraagt niet alleen: 'Hebben jullie beleid?'. Je koppelt de vraag aan het risico en aan concreet bewijs.
| Thema | Praktische vraag | Mogelijk bewijs |
|---|---|---|
| Identiteit | Hoe beschermen jullie beheerders- en gebruikersaccounts? | MFA-overzicht, policy-samenvatting, access-reviewproces |
| Toegang | Wie kan bij onze data of omgeving? | Rollenmodel, JML-procedure, reviewdatum |
| Back-up | Kunnen onze gegevens of diensten worden hersteld? | Back-upscope, hersteltest, RPO/RTO als vastgesteld |
| Incidenten | Hoe en wanneer worden wij geïnformeerd? | Incidentprocedure, escalatiepad, contractafspraken |
| Logging | Welke relevante gebeurtenissen worden gedetecteerd en opgevolgd? | Logging- en monitoringbeschrijving, reviewproces |
| Kwetsbaarheden | Hoe worden kwetsbaarheden gevonden en opgelost? | Vulnerabilityproces, patchproces, relevante testsamenvatting |
| Softwareontwikkeling | Hoe wordt security in ontwikkeling meegenomen? | Secure-developmentproces, code-review, testproces |
| Subleveranciers | Wie ondersteunt de dienst nog meer? | Subverwerkers- of leverancierslijst, beoordelingsproces |
| Continuïteit | Wat gebeurt er bij langdurige uitval? | BCP/DR-samenvatting, testresultaat, exitplan |
| Beleid & governance | Wie is verantwoordelijk en hoe wordt bijgestuurd? | Beleid, rollen, managementreview, verbeterregister |
Vraag alleen bewijs dat je daadwerkelijk nodig hebt. Een volledig pentestrapport, lijst met kwetsbaarheden, herstelcodes, gebruikerslijsten of technische architectuurdetails kunnen juist nieuwe beveiligingsrisico's creëren.
Hoe beoordeel je of bewijs bruikbaar is?
Een document hebben is niet hetzelfde als een risico beheersen. Controleer daarom minstens deze zeven kenmerken.
1. Scope
Gaat het bewijs over de juridische entiteit, dienst, locatie, omgeving of data die jij werkelijk afneemt?
Een certificaat voor 'corporate IT services' hoeft niet automatisch de specifieke SaaS-dienst te dekken.
2. Actualiteit
Wanneer is het bewijs gemaakt, getest of beoordeeld? Een restore-test uit 2022 zegt weinig over een omgeving die daarna volledig is gemigreerd.
3. Herkomst
Is het een eigen verklaring, een export uit een beheersysteem, een test van een specialist, een certificaat of een formeel assurance-rapport?
4. Werking
Laat het bewijs alleen zien dat een maatregel bestaat, of ook dat hij daadwerkelijk is toegepast en getest?
Een back-uppolicy is bijvoorbeeld iets anders dan een recente geslaagde hersteltest.
Lees verder: Securitymaatregel aantonen: bestaan is niet hetzelfde als werking.
5. Uitzonderingen
Welke accounts, locaties, systemen of onderdelen vallen erbuiten? Een bewijsstuk zonder zicht op uitzonderingen kan een te positief beeld geven.
6. Eigenaarschap
Wie bewaakt de maatregel en wie volgt afwijkingen op? Zonder eigenaar kan een maatregel snel verouderen.
7. Reviewmoment
Wanneer wordt opnieuw vastgesteld of de maatregel en het bewijs nog passen bij het risico?
Een ISO 27001-logo is niet genoeg
Een veelgemaakte fout is het afvinken van 'ISO 27001: ja' zonder het certificaat te bekijken.
Controleer minimaal:
- de exacte juridische organisatie;
- de normversie;
- geldigheidsduur;
- certificerende instelling;
- relevante accreditatie;
- vooral: de scope van het gecertificeerde managementsysteem.
De Raad voor Accreditatie legt expliciet uit dat managementsysteemcertificering verklaart dat het managementsysteem aan eisen voldoet. Het is geen verklaring dat elk afzonderlijk product of elke dienst aan specifieke security-eisen voldoet.
Gebruik hiervoor: ISO 27001-certificaat van een leverancier controleren: waarom scope telt.
Wat zegt de Cyberbeveiligingswet over leveranciers?
De Cbw treedt op 15 augustus 2026 in werking. Organisaties die onder de wet vallen moeten passende en evenredige technische, operationele en organisatorische maatregelen nemen om cyberrisico's te beheersen.
De beveiliging van de toeleveringsketen is daar onderdeel van.
Het NCSC beschrijft dat Cbw-organisaties cybersecuritymaatregelen kunnen opleggen aan rechtstreekse leveranciers en dienstverleners. De RDI adviseert om leveranciers via risicoanalyse te beoordelen, afspraken vast te leggen en naleving en actualiteit vervolgens te monitoren.
Dat betekent niet dat iedere leverancier hetzelfde certificaat nodig heeft. De gevraagde zekerheid hoort aan te sluiten op het risico van de concrete leveranciersrelatie.
Lever je juist zélf aan een Cbw-organisatie? Lees dan NIS2-vragen van klanten: wat betekent dit voor leveranciers?.
Praktijkvoorbeeld 1: marketingbureau
Een marketingbureau beheert campagnes, maar heeft geen toegang tot kritieke productieomgevingen. Het verwerkt beperkte contactgegevens.
Een proportionele beoordeling kan bestaan uit:
- toegangsbeheer en MFA;
- incidentcontact;
- bescherming van klantdata;
- subverwerkers;
- verwijdering na contracteinde.
Een SOC 2 Type II-rapport eisen kan hier buitenproportioneel zijn als het concrete risico dat niet rechtvaardigt.
Praktijkvoorbeeld 2: Microsoft 365-MSP
Een MSP heeft permanente beheerdersrechten en kan wijzigingen uitvoeren in identity, mail en securityconfiguratie.
Hier is het risico fundamenteel anders.
Naast beleid en certificaten wil je bijvoorbeeld weten:
- hoe privileged access is ingericht;
- of beheerders MFA gebruiken;
- hoe noodaccounts worden beschermd;
- welke handelingen worden gelogd;
- hoe personeel wordt geautoriseerd en uit dienst gemeld;
- hoe incidenten bij klanten worden gemeld;
- hoe de MSP eigen kritieke leveranciers beoordeelt.
Praktijkvoorbeeld 3: bedrijfskritische SaaS
Je primaire planning, klantdata of productieproces hangt af van één SaaS-platform.
Dan kijk je niet alleen naar vertrouwelijkheid, maar ook naar beschikbaarheid en herstel:
- waar staat data;
- wat is de back-up- en herstelstrategie;
- hoe is uitwijk geregeld;
- welke uptime- en incidentafspraken gelden;
- hoe exporteer je data bij vertrek;
- welke afhankelijkheden heeft de leverancier zelf;
- welk onafhankelijk bewijs ondersteunt de securityclaims?
Checklist: bewijsverzoek vóór verzending
Controleer voordat je een vragenlijst of bewijsverzoek naar een leverancier stuurt:
- Is duidelijk welk bedrijfsproces van deze leverancier afhankelijk is?
- Is duidelijk welke systemen en data geraakt kunnen worden?
- Is de leverancier op risico geclassificeerd?
- Vraagt elke securityvraag om een concreet benoemd risico?
- Is duidelijk welk bewijs acceptabel is?
- Is zware assurance alleen gevraagd als het risico dat rechtvaardigt?
- Worden gevoelige technische details niet onnodig opgevraagd?
- Is de scope van certificaten en rapporten onderdeel van de review?
- Zijn open punten en uitzonderingen toegestaan om eerlijk te worden toegelicht?
- Is een volgende reviewdatum of wijzigingstrigger vastgelegd?
Van eenmalige beoordeling naar leveranciersbeheer
Onder de Cbw is een leveranciersbeoordeling geen logisch eindpunt zodra een Excel-vragenlijst op groen staat.
Risico verandert wanneer bijvoorbeeld:
- de leverancier nieuwe toegang krijgt;
- een dienst bedrijfskritisch wordt;
- data naar een andere cloudomgeving verhuist;
- een subleverancier verandert;
- een certificaat afloopt;
- een ernstig incident plaatsvindt;
- een nieuwe functionaliteit of integratie wordt toegevoegd.
Leg daarom vast wanneer opnieuw moet worden beoordeeld. Voor sommige leveranciers is jaarlijks voldoende; voor kritieke relaties kunnen tussentijdse signalen of wijzigingen een eerdere review noodzakelijk maken.
Bronnen en actuele informatie
- NCSC — De Cyberbeveiligingswet en toeleveranciers: https://www.ncsc.nl/cyberbeveiligingswet-nis2/de-cyberbeveiligingswet-en-toeleveranciers
- NCSC — Toeleveranciers van Cbw-organisaties: https://www.ncsc.nl/cyberbeveiligingswet-nis2/toeleveranciers-van-cbw-organisaties
- NCSC — Zorgplicht: https://www.ncsc.nl/cyberbeveiligingswet-nis2/zorgplicht
- RDI — Toeleveringsketen en cyberbeveiliging: https://www.rdi.nl/onderwerpen/digitale-weerbaarheid/cyberbeveiligingswet/toeleveringsketen
- RDI — Veelgestelde vragen Cyberbeveiligingswet: https://www.rdi.nl/onderwerpen/digitale-weerbaarheid/cyberbeveiligingswet/veelgestelde-vragen
- Staatsblad 2026, 189 — inwerkingtreding Cbw en Cyberbeveiligingsbesluit: https://zoek.officielebekendmakingen.nl/stb-2026-189.html
Hulp bij een leveranciersbeoordeling
Wil je niet starten met een willekeurige lijst certificaten, maar eerst bepalen welke leveranciers echt kritisch zijn en welk bewijs daarbij past? Stuur de leverancier, dienst, afhankelijkheid en bestaande eisen mee via contact. InstantSecure kan helpen de risico- en bewijsstructuur praktisch op te zetten. Formele audit, juridische beoordeling en onafhankelijke assurance blijven bij de daarvoor bevoegde partijen.
