Kort antwoord
Krijg je als leverancier NIS2- of Cyberbeveiligingswet-vragen van een klant? Dan betekent dat niet automatisch dat jouw organisatie zelf rechtstreeks onder de wet valt. Vaak komt de vraag doordat jouw klant zijn toeleveringsketen moet beoordelen. Controleer daarom eerst of het gaat om een wettelijke plicht voor jouw organisatie, of om een klantvraag waarvoor je maatregelen, bewijsstukken en een roadmap moet aanleveren.
Kort gezegd: als jouw klant onder de Cyberbeveiligingswet valt, kan hij jou als leverancier vragen om securitymaatregelen, bewijsstukken of afspraken. Dat betekent niet automatisch dat jij zelf onder de wet valt. Het betekent wel dat je klant jouw risico in de keten wil beoordelen.
Laatst gecontroleerd: 4 augustus 2026. De Cyberbeveiligingswet en het Cyberbeveiligingsbesluit treden formeel op 15 augustus 2026 in werking. Controleer bij concrete verplichtingen altijd actuele informatie van NCSC, RDI en overheid.
Let op: dit artikel is praktische duiding voor leveranciers. Het is geen juridisch advies, geen auditadvies en geen garantie dat een klant je antwoord accepteert.
Wat verandert er op 15 augustus 2026?
Op 15 augustus 2026 verschuift de Cyberbeveiligingswet van voorbereiding naar geldende Nederlandse wetgeving voor organisaties die binnen het toepassingsbereik vallen. Vanaf dat moment gelden voor deze organisaties onder meer verplichtingen rond registratie, zorgplicht, meldplicht en toezicht.
Voor leveranciers is vooral de indirecte ketenwerking relevant.
Dat betekent niet dat iedere leverancier op 15 augustus automatisch zelf Cbw-plichtig wordt of ineens één verplicht certificaat moet hebben. Wel hebben Cbw-organisaties vanaf de inwerkingtreding een concretere reden om hun leveranciersrisico's, afspraken en bewijs structureel te organiseren.
Het NCSC beschrijft dat Cbw-organisaties cybersecuritymaatregelen kunnen opleggen aan rechtstreekse leveranciers en dienstverleners. Dat kan heel specifiek zijn voor één risico of breder gericht zijn op cybervolwassenheid.
Wat kun je als leverancier de komende maanden praktisch merken?
Denk aan:
- extra securityvragenlijsten bij contractverlenging;
- vragen naar ISO 27001, CYRA, SC10/SC20 of ander aantoonbaar bewijs;
- explicietere eisen rond MFA, privileged access en logging;
- bewijs van back-ups én hersteltests;
- kortere of concretere incidentmeldafspraken;
- vragen over subleveranciers en cloudafhankelijkheden;
- strengere onboarding van nieuwe leveranciers;
- periodieke herbeoordeling in plaats van een eenmalige vragenlijst;
- aanvullende contractclausules over security, incidenten, exit en dataverwijdering.
Niet iedere klant zal dit tegelijk of op dezelfde manier doen. De eisen horen risicogebaseerd en proportioneel te zijn.
De belangrijkste verandering: van vinkje naar risico en werking
De officiële Cbw-uitleg legt nadruk op risicoanalyse en passende maatregelen. Het NCSC noemt daarnaast expliciet dat de effectiviteit van maatregelen periodiek moet worden beoordeeld.
Daarom wordt het voor leveranciers steeds waardevoller om niet alleen te kunnen zeggen wat er bestaat, maar ook:
- voor welke scope een maatregel geldt;
- welk bewijs actueel is;
- welke uitzonderingen bestaan;
- of de werking is getest;
- wanneer opnieuw wordt beoordeeld;
- welke open punten op een roadmap staan.
Lees hiervoor: Securitymaatregel aantonen: bestaan is niet hetzelfde als werking.
Ben je juist de organisatie die leveranciers moet beoordelen?
Dan begint het proces niet met een lange lijst keurmerken. Breng eerst afhankelijkheden en kritieke leveranciers in kaart.
Gebruik daarvoor:
- Leveranciers classificeren op cyberrisico onder de Cyberbeveiligingswet
- Welk securitybewijs vraag je van een leverancier?
- ISO 27001, SOC 2, ISAE 3402 of CYRA: wat bewijst het bij een leverancier?
Voor wie is dit artikel?
Dit artikel is bedoeld voor MKB-leveranciers die een vraag krijgen zoals:
- “Valt jullie organisatie onder NIS2?”
- “Kunnen jullie aantonen dat jullie voldoen aan de Cyberbeveiligingswet?”
- “Lever een NIS2-verklaring of securitybewijs aan.”
- “Vul onze supplier security questionnaire in.”
- “Upload bewijsstukken over MFA, back-ups, incidentmanagement of toegangsbeheer.”
- “Beschrijf hoe jullie ketenrisico’s en onderaannemers beheren.”
Vooral SaaS-leveranciers, IT-dienstverleners, marketingbureaus, detacheerders, MSP’s, webbouwers, consultants en andere B2B-leveranciers kunnen hiermee te maken krijgen.
Heb je een concrete vragenlijst of klantclausule ontvangen? Dan is de commerciële route meestal niet “algemene NIS2-compliance”, maar eerst: laat je klantvraag vertalen naar eis, maatregel, bewijs en roadmap.
Noemt de klant SC10 of SC20, lees dan welke vragen je eerst over kader, scope en toetsing moet stellen. Gaat het om één concrete uitvraag, gebruik dan de securityvragenlijstdienst als passende vervolgstap.
Eerst scheiden: wettelijke plicht of klantvraag?
De belangrijkste fout is om direct te antwoorden met “ja, wij voldoen aan NIS2” of “nee, dit geldt niet voor ons”. Dat is vaak te kort door de bocht.
Maak eerst onderscheid tussen deze situaties:
| Vraag van klant | Betekent dit dat jij zelf onder Cbw/NIS2 valt? | Veilige eerste reactie |
|---|---|---|
| “Vallen jullie onder NIS2?” | Niet automatisch. Dat hangt af van sector, omvang en toepassingsbereik. | Controleer eerst of jouw organisatie zelf onder de Cyberbeveiligingswet valt. |
| “Lever NIS2-bewijs aan.” | Niet per se. Dit kan een keten- of procurementvraag zijn. | Vraag welke maatregelen, bewijsstukken of verklaring de klant precies nodig heeft. |
| “Zijn jullie NIS2-compliant?” | Risicovolle claim als dit niet juridisch is vastgesteld. | Antwoord met concrete maatregelen, bewijs en eventuele open punten. |
| “Upload security evidence.” | Meestal klantvraag of vendor assessment. | Deel alleen relevante, geanonimiseerde bewijsstukken. |
| “Vul onze supplier security questionnaire in.” | Vaak onderdeel van leveranciersbeoordeling. | Behandel dit als een securityvragenlijst van een klant. |
Als je vaker dit soort klantvragen krijgt, kan een Cybersecurity Bewijsmap voor NIS2- en Cbw-klantvragen helpen om bewijsstukken niet telkens opnieuw bij elkaar te zoeken.
Wat zegt de officiële overheidslijn over toeleveranciers?
De Cyberbeveiligingswet is de Nederlandse uitwerking van de Europese NIS2-richtlijn. Organisaties die onder de wet vallen, krijgen verplichtingen zoals registratieplicht, zorgplicht, meldplicht en toezicht.
Voor leveranciers is vooral de ketencomponent belangrijk. De overheid beschrijft dat organisaties die onder de Cyberbeveiligingswet vallen hun toeleveringsketen moeten meenemen in hun risicobeheersing. Dat kan betekenen dat zij eisen stellen aan de digitale veiligheid van rechtstreekse toeleveranciers of dienstverleners.
Dat is precies waarom een MKB-leverancier die zelf niet onder de wet valt toch vragen kan krijgen van een grotere klant.
Belangrijk daarbij: een certificaat of normenkader kan helpen in het gesprek, maar is niet automatisch een garantie dat elk ketenrisico is afgedekt. De gevraagde maatregelen kunnen per leverancier verschillen.
Welke leveranciers krijgen waarschijnlijk vragen?
Niet elke leverancier krijgt dezelfde vragen. De kans is groter als je klant jou ziet als digitaal, operationeel of procesmatig risico.
| Type leverancier | Waarom klantvragen logisch zijn | Voorbeelden van vragen |
|---|---|---|
| SaaS-leverancier | Je verwerkt data of levert een applicatie die de klant gebruikt. | Hosting, toegang, logging, back-ups, incidentmelding, subverwerkers. |
| IT-dienstverlener of MSP | Je hebt toegang tot systemen, accounts of beheeromgevingen. | MFA, privileged access, patching, monitoring, beheerprocedures. |
| Marketingbureau of webbouwer | Je beheert websites, formulieren, tracking, klantdata of CMS-toegang. | CMS-beveiliging, toegangsbeheer, back-ups, datalekprocedure. |
| Detacheerder of consultancybedrijf | Medewerkers werken in klantomgevingen of met klantinformatie. | Screening, geheimhouding, awareness, apparaatbeheer, offboarding. |
| Leverancier aan overheid of gemeente | Inkoopvoorwaarden en aanbestedingen bevatten vaker informatiebeveiligingseisen. | ISO 27001, BIO, securitybeleid, incidentproces, bewijsstukken. |
| MKB zonder eigen security officer | Je moet professioneel antwoorden zonder volledig compliance-team. | “Welke maatregelen zijn ingericht en wat staat nog open?” |
Voorbeeld: een marketingbureau levert campagnesites aan een zorgorganisatie. Het bureau valt mogelijk niet rechtstreeks onder de Cyberbeveiligingswet, maar de klant kan wel vragen stellen over CMS-toegang, MFA, back-ups, datalekproces, hosting en subverwerkers.
Welke klantvragen kun je verwachten?
Klantvragen vallen meestal in vijf groepen.
1. Organisatie en beleid
Voorbeelden:
- Hebben jullie een informatiebeveiligingsbeleid?
- Wie is verantwoordelijk voor security?
- Is er periodieke risicobeoordeling?
- Worden medewerkers getraind?
Mogelijk bewijs:
- informatiebeveiligingsbeleid
- korte rolverdeling
- security awareness-overzicht
- managementsamenvatting van risico’s en maatregelen
2. Toegang en accounts
Voorbeelden:
- Is MFA verplicht?
- Hoe beheren jullie beheerdersaccounts?
- Hoe wordt toegang ingetrokken bij uitdiensttreding?
- Worden rechten periodiek gecontroleerd?
Mogelijk bewijs:
- screenshot of export van MFA-instellingen
- toegangsbeleid
- rechtenreview
- joiner/mover/leaver-proces
Bij klantportalen of procurementtrajecten valt dit vaak onder een vendor assessment hulp, zeker als je bewijsstukken moet uploaden of verklaringen moet afgeven.
3. Technische maatregelen
Voorbeelden:
- Hoe worden systemen gepatcht?
- Zijn back-ups ingericht en getest?
- Is logging of monitoring actief?
- Worden apparaten beheerd?
Mogelijk bewijs:
- patchbeleid of updateproces
- back-upoverzicht
- restore-testverslag
- endpoint/security-instellingen
- logging- of monitoringbeschrijving
4. Incidenten en meldingen
Voorbeelden:
- Hebben jullie een incidentprocedure?
- Hoe snel melden jullie incidenten aan klanten?
- Wie is bereikbaar bij een security-incident?
- Worden incidenten geëvalueerd?
Mogelijk bewijs:
- incidentprocedure
- meldmatrix
- voorbeeld van incidentregistratie
- evaluatieproces
5. Leveranciers en onderaannemers
Voorbeelden:
- Gebruiken jullie subverwerkers?
- Beoordelen jullie eigen leveranciers?
- Zijn afspraken vastgelegd?
- Hoe beperken jullie ketenrisico’s?
Mogelijk bewijs:
- leverancierslijst
- subverwerkersoverzicht
- SLA, DPA of verwerkersovereenkomst
- leveranciersbeoordeling op hoofdlijnen
Wat kun je veilig antwoorden?
Een veilig antwoord is meestal concreet, eerlijk en toetsbaar. Niet te hard, niet te vaag.
Gebruik liever deze structuur:
- Wat is ingericht?
- Voor welke scope geldt dit?
- Welk bewijs kun je delen?
- Wat is nog niet volledig ingericht?
- Welke roadmap of verbeteractie staat gepland?
Voorbeeld:
Voor onze Microsoft 365-omgeving is MFA verplicht voor beheerders en gebruikers met toegang tot klantinformatie. Toegang wordt beheerd via vaste rollen en bij uitdiensttreding ingetrokken. We kunnen een geanonimiseerde samenvatting van de MFA-inrichting en het toegangsproces delen. Periodieke formele rechtenreviews staan op onze roadmap voor Q3.
Dit is sterker dan alleen “ja”, omdat je uitlegt wat er geregeld is en waar de grens ligt.
Wanneer moet je voorzichtig zijn met “wij voldoen aan NIS2”?
Wees terughoudend met algemene complianceclaims. Vooral als je niet juridisch hebt vastgesteld dat je onder de wet valt of als je geen formele audit of certificering hebt.
| Claim | Risico | Veiliger alternatief |
|---|---|---|
| “Wij zijn NIS2-compliant” | Te breed en mogelijk niet onderbouwd. | “Wij hebben maatregelen ingericht op de gevraagde thema’s en kunnen deze onderbouwen met bewijsstukken.” |
| “Wij voldoen aan de Cyberbeveiligingswet” | Kan juridische of contractuele verwachtingen scheppen. | “Wij hebben beoordeeld welke klantvraag op ons van toepassing is en leveren bewijs per gevraagde maatregel.” |
| “ISO 27001 is niet nodig” | Soms is een certificaat wél een harde eis. | “We hebben geen ISO 27001-certificaat, maar kunnen bestaande maatregelen en open punten aantoonbaar maken.” |
| “Alles is geregeld” | Bij incident of audit kwetsbaar. | “De volgende maatregelen zijn ingericht; deze onderdelen staan nog op de roadmap.” |
| “Dit keurmerk bewijst compliance” | Certificaat of keurmerk is niet automatisch wettelijke naleving. | “Dit certificaat kan helpen als bewijsstuk, maar de klant moet beoordelen of het past bij het gevraagde risico.” |
Krijg je een ISO 27001-vraag van je klant, maar heb je geen certificaat? Lees dan ook: zonder ISO 27001 toch security aantonen.
Welke bewijsstukken moet je voorbereiden?
Voor veel leveranciers is een compacte Cybersecurity Bewijsmap praktischer dan losse documenten bij elkaar zoeken zodra een klantportaal dichtgaat.
Een basis-bewijsmap bevat bijvoorbeeld:
| Onderdeel | Voorbeeld van bewijs | Let op |
|---|---|---|
| Securitybeleid | Kort beleid of managementsamenvatting | Geen generieke template zonder toepassing. |
| MFA en toegangsbeheer | Screenshot, beleidsinstelling, rechtenproces | Deel geen gevoelige tenantdetails of gebruikerslijsten zonder noodzaak. |
| Back-ups | Back-upoverzicht en restore-test | Alleen zeggen “we hebben back-ups” is vaak te zwak. |
| Incidentproces | Incidentprocedure en meldpad | Benoem ook klantmelding en escalatie. |
| Leveranciersbeheer | Lijst of procedure voor kritieke leveranciers | Maak duidelijk welke leveranciers echt relevant zijn. |
| Roadmap | Verbeterlijst met eigenaar en planning | Open punten zijn acceptabeler als ze concreet zijn. |
Wil je dit structureel klaarzetten voor meerdere klanten of vendor assessments? Bekijk dan de Cybersecurity Bewijsmap Sprint.
Gebruik de centrale evidence-hub om per thema context en afscherming te bepalen.
Wat als je nog niet alles op orde hebt?
Niet alles hoeft perfect te zijn om professioneel te antwoorden. Maar je moet wel voorkomen dat je harder claimt dan je kunt bewijzen.
Een goede formulering is:
De maatregel is gedeeltelijk ingericht. Voor [scope] is dit al actief. Voor [resterend onderdeel] staat een verbetering gepland op [termijn]. We kunnen het huidige bewijs en de roadmap delen.
Bijvoorbeeld:
Back-ups zijn ingericht voor onze primaire systemen. Een formeel restore-testverslag is nog niet structureel vastgelegd. De eerste gedocumenteerde restore-test staat gepland voor Q3. Tot die tijd kunnen we het back-upproces en de huidige configuratie samenvatten.
Wanneer is een Eerste Beoordeling verstandig?
Vraag eerst verduidelijking wanneer onduidelijk is of de klant een wettelijke kwalificatie, contractuele keteneis, SC10/SC20-route of concrete vragenlijst bedoelt. Voor structureel herbruikbaar klantbewijs is de primaire actie onder dit artikel de Bewijsmap; voor één concrete vragenlijst gebruik je de vragenlijstdienst.
Hoe InstantSecure helpt
InstantSecure is geen auditor, certificerende instelling of juridisch aanbestedingsadviseur. We beloven ook niet dat je klant je antwoord accepteert.
We helpen wel om de klantvraag praktisch te vertalen naar:
- eis
- maatregel
- bewijs
- open punt
- roadmap
Daarmee kun je rustiger, concreter en veiliger reageren op securityvragen van klanten.
Samenvatting
Als leverancier hoef je niet automatisch zelf onder de Cyberbeveiligingswet te vallen om toch NIS2-vragen van klanten te krijgen. De commerciële realiteit is dat grotere klanten hun ketenrisico’s willen beheersen. Daarom vragen ze leveranciers om beleid, maatregelen, bewijsstukken en soms een roadmap.
De beste aanpak is niet overclaimen, maar helder aantonen wat geregeld is, wat nog openstaat en welk bewijs je veilig kunt delen.
Bronnen en actuele overheidsinformatie
- NCSC - Cyberbeveiligingswet (NIS2): https://www.ncsc.nl/cyberbeveiligingswet-nis2
- NCSC - De Cyberbeveiligingswet en toeleveranciers: https://www.ncsc.nl/cyberbeveiligingswet-nis2/de-cyberbeveiligingswet-en-toeleveranciers
- NCTV - Cyberbeveiligingswet: https://www.nctv.nl/onderwerpen/c/cyberbeveiligingswet
