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: 8 juli 2026. De NCSC-pagina over de Cyberbeveiligingswet noemt als verwachte inwerkingtreding rond 15 augustus 2026. Controleer bij concrete verplichtingen altijd actuele overheidsinformatie.
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.
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.
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.
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?
Laat de klantvraag eerst beoordelen als:
- de klant “NIS2-compliant” of “Cyberbeveiligingswet-proof” vraagt;
- je niet weet of je zelf onder de wet valt;
- de klant een ISO 27001-certificaat lijkt te eisen;
- je bewijsstukken moet uploaden in een klantportaal;
- je twijfelt tussen “ja”, “nee”, “gedeeltelijk” of “niet van toepassing”;
- er een deadline, aanbesteding of contractverlenging aan hangt;
- je niet wilt overclaimen richting procurement, legal of security.
Laat je NIS2-klantvraag beoordelen voordat je antwoordt of bewijsstukken uploadt.
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.
Praktische CTA
Heb je een NIS2-, Cbw- of securityvragenlijst van een klant ontvangen?
Laat je NIS2-klantvraag beoordelen. We vertalen de vraag naar eis, maatregel, bewijs en roadmap.
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
