Leveranciers classificeren op cyberrisico onder de Cyberbeveiligingswet

Kort antwoord

Classificeer leveranciers onder de Cyberbeveiligingswet niet op omzet, bekendheid of het aantal ingevulde securityvragen. Classificeer ze op de impact die hun uitval, compromittering of misbruik op jouw netwerk- en informatiesystemen en bedrijfsprocessen kan hebben.

Een bruikbaar model kijkt minstens naar:

1. procesafhankelijkheid;
2. toegang tot systemen en accounts;
3. gevoeligheid en omvang van data;
4. impact op beschikbaarheid en herstel;
5. mogelijkheid om de leverancier te vervangen;
6. software- en updateprivileges;
7. afhankelijkheid van subleveranciers;
8. mogelijke keten- en concentratierisico's.

Gebruik daarna risicoklassen om te bepalen hoeveel onderzoek, contractuele beheersing, bewijs en monitoring passend is.

Laatst gecontroleerd: 4 augustus 2026. De Cyberbeveiligingswet treedt op 15 augustus 2026 in werking. De classificatie hieronder is een praktisch model van InstantSecure en geen officiële wettelijke risicoscore of toezichthoudersmodel.

Waarom leveranciersclassificatie nu belangrijker wordt

Onder de Cbw is beveiliging van de toeleveringsketen onderdeel van de zorgplicht voor organisaties die onder de wet vallen.

De RDI adviseert organisaties expliciet om via risicoanalyse te bepalen:

• voor welke processen en data zij afhankelijk zijn van leveranciers;
• welke risico's en afhankelijkheden daarmee samenhangen;
• welke leveranciers daardoor kritisch zijn.

Het NCSC benadrukt eveneens dat de beoordeling moet aansluiten op de concrete invloed van een leverancier op netwerk- en informatiesystemen.

Dat betekent dat een leveranciersregister met alleen naam, contracteigenaar en einddatum niet voldoende is als basis voor cyberrisicobeheersing.

Je wilt ook weten:

Wat kan deze leverancier bij ons raken, hoe ernstig is dat en hoe snel kunnen we herstellen of overstappen?

De fout: classificeren op type leverancier

Het is verleidelijk om vaste regels te gebruiken zoals:

• SaaS = hoog risico;
• schoonmaak = laag risico;
• MSP = kritisch;
• accountant = middel.

Dat is te grof.

Een kleine fysieke onderhoudspartij kan bijvoorbeeld toegang hebben tot een technisch kritieke locatie. Een SaaS-tool voor interne enquêtes kan weinig impact hebben. Een payrollprovider kan juist zeer gevoelige persoonsgegevens en een belangrijk proces beheren.

Classificeer daarom de leveranciersrelatie, niet alleen het bedrijfslabel.

Stap 1: koppel de leverancier aan bedrijfsprocessen

Begin niet bij securityvragen. Begin bij processen.

Leg per leverancier vast:

• welke dienst wordt geleverd;
• welk bedrijfsproces daarvan afhankelijk is;
• wie proceseigenaar is;
• wat er gebeurt als de dienst één uur, één dag of één week uitvalt;
• of een handmatige fallback bestaat;
• welke klanten, burgers, patiënten of ketenpartners geraakt worden.

Voorbeeld:

Het gaat niet om perfecte kwantificering. Het gaat om het zichtbaar maken van afhankelijkheid.

Stap 2: bepaal toegang en technische invloed

Toegang is een belangrijke risicoversneller.

Vraag:

• Heeft de leverancier gebruikersaccounts in onze omgeving?
• Heeft hij beheer- of privileged access?
• Kan hij configuraties wijzigen?
• Kan hij software of updates distribueren?
• Heeft hij remote access?
• Heeft hij toegang tot backups, identity of logging?
• Kan hij nieuwe accounts of tokens aanmaken?

Een leverancier die alleen data ontvangt via een maandelijkse export heeft een andere risicopositie dan een MSP met Global Administrator-rechten.

Stap 3: beoordeel data-impact

Breng niet alleen 'persoonsgegevens ja/nee' in kaart.

Kijk naar:

• vertrouwelijkheid;
• integriteit;
• beschikbaarheid;
• gevoeligheid;
• volume;
• wettelijke of contractuele gevoeligheid;
• mogelijkheid tot reconstructie;
• gevolgen van ongeautoriseerde wijziging.

Voorbeelden van hoge impact kunnen zijn:

• medische gegevens;
• authenticatiegegevens;
• financiële transactiedata;
• bedrijfsgeheimen;
• broncode;
• operationele configuraties;
• gegevens die nodig zijn om een kritieke dienst te leveren.

Stap 4: beoordeel continuïteit en herstel

Cyberrisico gaat niet alleen over datalekken.

Vraag ook:

• Hoe snel kunnen we zonder deze dienst?
• Is data exporteerbaar?
• Bestaat een uitwijkmogelijkheid?
• Hebben we een tweede leverancier?
• Kunnen we intern tijdelijk doorgaan?
• Hoe lang duurt technische migratie?
• Wie bezit domeinen, sleutels, configuraties en documentatie?

Een leverancier kan technisch goed beveiligd zijn en tóch een hoog bedrijfsrisico vormen omdat uitval nauwelijks op te vangen is.

Stap 5: beoordeel substitueerbaarheid en lock-in

Twee leveranciers met dezelfde technische dienst kunnen verschillende risico's hebben.

Voorbeeld:

Leverancier A levert standaard back-upsoftware. Configuratie en data kunnen binnen twee dagen naar een andere partner.

Leverancier B levert een maatwerkplatform waarop twintig processen draaien, gebruikt een eigen dataformaat en heeft zes maanden migratietijd.

Bij gelijke securityvolwassenheid is de afhankelijkheid van leverancier B veel groter.

Leg daarom vast:

• switching time;
• datamigratiecomplexiteit;
• contractuele exitondersteuning;
• beschikbaarheid van alternatieven;
• eigendom van configuraties en data;
• noodzakelijke kennis bij overstap.

Stap 6: kijk naar subleveranciers en concentratierisico

Een leverancier staat zelden alleen.

Een SaaS-platform kan afhankelijk zijn van:

• één hyperscaler;
• een identityprovider;
• een externe supportpartij;
• e-mail- of smsproviders;
• payment providers;
• softwarebibliotheken;
• managed SOC-diensten.

Vraag bij hogere risico's daarom:

• welke subleveranciers essentieel zijn;
• of dezelfde partij op meerdere kritieke plekken in jouw organisatie terugkomt;
• of meerdere leveranciers uiteindelijk dezelfde cloud- of infrastructuurafhankelijkheid hebben.

Dat laatste is concentratierisico.

Tien leveranciers kunnen op papier divers lijken, terwijl negen ervan uiteindelijk op dezelfde cloudprovider, identityprovider of telecomverbinding steunen.

Een praktisch classificatiemodel met vier klassen

Onderstaande vier klassen zijn geen wettelijke categorieën. Gebruik ze om intern consequent te werken.

Klasse 1 — beperkt

Typische kenmerken:

• geen systeemtoegang;
• geen kritieke data;
• nauwelijks procesafhankelijkheid;
• snel vervangbaar;
• beperkte impact bij uitval.

Mogelijke aanpak:

• basiscontractafspraken;
• beperkte securityvragen;
• review bij grote wijziging of contractverlenging.

Klasse 2 — relevant

Typische kenmerken:

• verwerking van bedrijfs- of persoonsgegevens;
• enige procesafhankelijkheid;
• beperkte technische toegang;
• vervanging mogelijk, maar niet direct.

Mogelijke aanpak:

• securityvragenlijst;
• bewijs van relevante maatregelen;
• incident- en exitafspraken;
• periodieke beoordeling.

Klasse 3 — hoog

Typische kenmerken:

• gevoelige data;
• beheer- of systeemtoegang;
• belangrijke operationele afhankelijkheid;
• hoge herstelimpact;
• beperkte substitueerbaarheid.

Mogelijke aanpak:

• verdiept assessment;
• sterker bewijs of relevante certificering;
• expliciete contractuele controls;
• incident- en wijzigingsmelding;
• continuïteits- en herstelbewijs;
• minimaal jaarlijkse herbeoordeling, of eerder bij relevante wijzigingen.

Klasse 4 — kritisch

Typische kenmerken:

• uitval raakt essentiële dienstverlening;
• zeer brede privileged access;
• kritieke identity-, infrastructuur- of softwareketenrol;
• hoge concentratie of vendor lock-in;
• nauwelijks bruikbare fallback.

Mogelijke aanpak:

• diepgaand leveranciersrisico-onderzoek;
• onafhankelijke assurance waar passend;
• specifieke technische bewijsvoering;
• contractuele security-, audit-, incident- en exitvoorwaarden;
• expliciete fallback/continuïteitsstrategie;
• actieve monitoring van relevante wijzigingen.

Gebruik geen totaalscore zonder uitleg

Je kunt factoren een score geven, bijvoorbeeld 1 tot 4, maar pas op met schijnnauwkeurigheid.

Een totaalscore van 23 zegt weinig als niemand weet waarom.

Een betere classificatie legt uit:

• welke factor de klasse bepaalt;
• welke risico's dominant zijn;
• welke mitigerende maatregelen al bestaan;
• welk restrisico overblijft;
• wie de classificatie heeft goedgekeurd.

Sommige factoren kunnen bovendien een override zijn.

Voorbeeld:

Een leverancier scoort gemiddeld middel, maar heeft permanente domain-adminrechten. Dat ene kenmerk kan genoeg reden zijn om de beoordeling naar hoog of kritisch te tillen.

Voorbeeld van een leveranciersrisicomatrix

Gebruik deze matrix als gesprekshulp, niet als juridische norm.

Wat doe je ná de classificatie?

Classificatie heeft alleen waarde als er consequenties aan hangen.

Koppel per klasse vooraf vast:

• welk intakeonderzoek nodig is;
• wie akkoord geeft;
• welke contractclausules gelden;
• welk securitybewijs gevraagd wordt;
• hoe uitzonderingen worden behandeld;
• hoe vaak review plaatsvindt;
• welke gebeurtenissen tussentijdse review triggeren.

Anders wordt de classificatie alleen een extra kolom in Excel.

Van risicoklasse naar securitybewijs

Een veelgemaakte fout is dat een organisatie eerst een leverancier 'kritiek' noemt en daarna alsnog dezelfde standaardvragenlijst stuurt als naar iedereen.

De classificatie moet juist bepalen hoeveel zekerheid je verlangt.

Voorbeeld:

Lees verder: welk bewijsniveau je per risicoklasse vraagt. Moet je bepalen of een certificaat, rapport of andere onafhankelijke beoordeling passend is, vergelijk dan ISO 27001, SOC 2, ISAE 3402 en CYRA. Beoordeel bij maatregelbewijs bovendien niet alleen of iets is ingericht, maar ook welk bewijs iets zegt over daadwerkelijke werking, review en bijsturing.

Wat verandert door de Cbw?

De Cbw treedt op 15 augustus 2026 in werking. De officiële informatie van NCSC en RDI maakt duidelijk dat toeleveringsketenbeveiliging onderdeel is van de zorgplicht.

De praktische verandering is niet dat iedere Cbw-organisatie één verplichte leveranciersscore moet invoeren.

De verandering is dat organisaties aantoonbaar en risicogebaseerd moeten nadenken over:

• afhankelijkheden;
• leveranciersrisico's;
• passende maatregelen;
• beveiligingsafspraken;
• monitoring en actualiteit.

Een verdedigbaar leveranciersproces laat daarom zien waarom leverancier A zwaarder wordt beoordeeld dan leverancier B.

Monitoring: classificatie is niet permanent

Een leverancier kan van klasse veranderen.

Triggers zijn bijvoorbeeld:

• nieuwe systeemtoegang;
• uitbreiding naar gevoelige data;
• nieuwe integratie;
• overname van de leverancier;
• belangrijke subleverancier verandert;
• ernstig security-incident;
• certificering verloopt of scope wijzigt;
• dienstverlening wordt kritieker;
• exitmogelijkheid verslechtert.

Leg daarom naast een vaste reviewdatum ook wijzigingstriggers vast.

Nieuwe leveranciers: classificeer vóór contractering

Het beste moment voor leveranciersrisicoanalyse is vóórdat de overeenkomst getekend is.

Dan kun je nog:

• architectuurkeuzes beïnvloeden;
• minder privilege afspreken;
• data minimaliseren;
• exitvoorwaarden opnemen;
• securitybewijs eisen;
• incidenttermijnen onderhandelen;
• alternatieven vergelijken.

Na implementatie wordt iedere wijziging duurder.

De RDI adviseert daarom cyberbeveiliging bij nieuwe contracten en aanbestedingen vanaf het begin mee te nemen.

Bestaande leveranciers: begin met de grootste afhankelijkheden

Heb je honderden leveranciers en nog geen volwassen proces? Probeer niet alles tegelijk diepgaand te beoordelen.

Begin met leveranciers die één of meer van deze kenmerken hebben:

• privileged access;
• kritieke hosting of SaaS;
• identity en authenticatie;
• grote hoeveelheden gevoelige data;
• operationele single points of failure;
• software-updates naar jouw omgeving;
• lange switching time;
• grote keten- of concentratieafhankelijkheid.

Dat levert sneller risicoreductie op dan honderd laag-risicoleveranciers met dezelfde vragenlijst najagen.

Praktijkvoorbeeld: dezelfde leverancier, andere classificatie

Twee organisaties gebruiken hetzelfde CRM-platform.

Organisatie A

Gebruikt het alleen voor marketingcontacten. Een export wordt dagelijks lokaal opgeslagen. Bij uitval kan het team tijdelijk in een andere tool werken.

Organisatie B

Gebruikt hetzelfde platform voor primaire klantdossiers, contracten, workflowautomatisering en klantportaal. Twintig bedrijfsprocessen zijn geïntegreerd en migratie duurt naar verwachting zes maanden.

Het technische product is hetzelfde.

Het leveranciersrisico voor de afnemer is niet hetzelfde.

Daarom moet leveranciersclassificatie altijd de context van jouw organisatie meenemen.

Checklist voor een verdedigbare leveranciersclassificatie

• Dienst en juridische leverancier zijn duidelijk.
• Kritieke bedrijfsprocessen zijn gekoppeld.
• Data en gevoeligheid zijn vastgelegd.
• Systeem-, netwerk- en beheerrechten zijn bekend.
• Software- en updateprivileges zijn beoordeeld.
• Impact van uitval is beschreven.
• Herstel- en fallbackmogelijkheden zijn bekend.
• Substitueerbaarheid en lock-in zijn beoordeeld.
• Kritieke subleveranciers zijn in beeld.
• Concentratierisico is meegenomen.
• Risicoklasse heeft concrete eisen en reviewfrequentie.
• Dominante risico's zijn beschreven, niet alleen gescoord.
• Een eigenaar en goedkeurder zijn toegewezen.
• Wijzigingstriggers voor herclassificatie zijn vastgelegd.

Bronnen en actuele informatie

• 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
• RDI — Scope thema-inspectie leveranciersmanagement: https://www.rdi.nl/documenten/2025/05/28/scope-thema-inspectie-leveranciersmanagement
• NCSC — Toeleveranciers van Cbw-organisaties: https://www.ncsc.nl/cyberbeveiligingswet-nis2/toeleveranciers-van-cbw-organisaties
• NCSC — De Cyberbeveiligingswet en toeleveranciers: https://www.ncsc.nl/cyberbeveiligingswet-nis2/de-cyberbeveiligingswet-en-toeleveranciers
• NCSC — Zorgplicht: https://www.ncsc.nl/cyberbeveiligingswet-nis2/zorgplicht
• Staatsblad 2026, 189: https://zoek.officielebekendmakingen.nl/stb-2026-189.html

Eerst overzicht krijgen in leveranciersrisico?

Wil je een bestaande leverancierslijst vertalen naar een praktische risicoclassificatie met bewijsverwachting en reviewmomenten? Stuur via contact de omvang van het leverancierslandschap en je belangrijkste processen mee. InstantSecure kan helpen de structuur op te zetten; formele assurance, juridische oordelen en toezichtbesluiten blijven buiten onze rol.