Laatst gecontroleerd
8 juli 2026
Kort antwoord
Stuur bij een securityvragenlijst niet zomaar een map met losse screenshots, policies en exports mee. Koppel per klantvraag één maatregel aan één passend bewijsstuk en voeg een korte toelichting toe. Goede bewijsstukken zijn bijvoorbeeld een MFA-overzicht, back-upbeleid, restore-testverslag, incidentprocedure, toegangsreview, patchproces of leveranciersregister. Deel zo concreet mogelijk, maar anonimiseer gevoelige details.
Kort gezegd: een klant wil meestal niet alles zien wat intern bestaat. De klant wil begrijpen wat je hebt ingericht, hoe je dat kunt aantonen en welke open punten je realistisch oppakt. Daarom werkt een gestructureerde Cybersecurity Bewijsmap vaak beter dan losse documenten.
Waarom bewijsstukken steeds vaker worden gevraagd
Veel leveranciers krijgen niet alleen meer de vraag: “Hebben jullie security op orde?” Klanten vragen steeds vaker om bewijs. Dat gebeurt bijvoorbeeld via een securityvragenlijst van een klant, een supplier security questionnaire, een klantportaal, een vendor assessment of een aanbesteding.
Dat komt doordat klanten hun leveranciersrisico’s beter moeten beheersen. Organisaties die onder de Cyberbeveiligingswet vallen, kunnen bijvoorbeeld eisen stellen aan de digitale veiligheid van hun rechtstreekse toeleveranciers. NCSC benoemt ook dat Cbw-organisaties hun ketenrisico’s in kaart moeten brengen en afspraken kunnen maken over maatregelen, audits, incidentmeldingen of security-updates.
Voor jou als MKB-leverancier betekent dit niet automatisch dat je zelf een zwaar certificeringstraject nodig hebt. Het betekent wel dat je professioneel moet kunnen uitleggen wat je geregeld hebt. Een goed bewijsstuk maakt je antwoord geloofwaardiger, maar alleen als het past bij de vraag.
De basisregel: vraag → maatregel → bewijs → toelichting
Gebruik bij elke klantvraag dezelfde volgorde:
| Stap | Vraag die je jezelf stelt | Voorbeeld |
|---|---|---|
| 1. Vraag | Wat vraagt de klant precies? | “Is MFA verplicht voor alle gebruikers?” |
| 2. Maatregel | Welke maatregel hebben we ingericht? | MFA voor Microsoft 365 en beheeraccounts |
| 3. Bewijs | Welk bewijsstuk toont dit aan? | Geanonimiseerd MFA- of Conditional Access-overzicht |
| 4. Toelichting | Wat moet de klant weten zonder dat je te veel deelt? | “MFA is actief voor accounts met toegang tot klantdata.” |
| 5. Roadmap | Wat is nog niet af? | “Uitrol naar resterende accounts staat gepland in Q4.” |
Deze structuur voorkomt twee problemen. Je stuurt niet te weinig, waardoor de klant blijft doorvragen. Maar je stuurt ook niet te veel, waardoor je onnodig interne details, kwetsbare configuratie-informatie of persoonsgegevens deelt.
Twijfel je of je bewijsstuk sterk genoeg is? Laat dan de securityvragenlijst eerst beoordelen voordat je alles uploadt.
Bewijsmatrix: welke bewijsstukken passen bij welke vraag?
Onderstaande tabel kun je gebruiken als startpunt. Zie dit niet als vaste checklist die voor elke klant genoeg is. De juiste bewijsstukken hangen af van je dienst, klantrelatie, risico en contractuele context.
| Thema | Mogelijke klantvraag | Bruikbaar bewijsstuk | Wel delen | Liever niet delen |
|---|---|---|---|---|
| MFA | “Is multifactor-authenticatie verplicht?” | MFA-rapport, Conditional Access-overzicht, beleid voor beheeraccounts | Geanonimiseerde instellingen, scope, datum | Adminnamen, tenant-ID’s, volledige gebruikerslijst |
| Back-ups | “Worden back-ups gemaakt en getest?” | Back-upbeleid, restore-testverslag, back-upstatus, retentieoverzicht | Samenvatting, laatste testdatum, scope | Volledige infrastructuurdetails, opslaglocaties, credentials |
| Incidentrespons | “Hebben jullie een incidentprocedure?” | Incidentprocedure, meldpad, rolverdeling, oefenverslag | Proces, rollen, responstijden | Privénummers, interne escalatiedetails zonder noodzaak |
| Toegangsbeheer | “Hoe beheren jullie toegang?” | Rechtenmatrix, access review, onboarding/offboarding-proces | Proces en reviewdatum | Complete namenlijst of gevoelige rechtenexport |
| Logging en monitoring | “Worden securitylogs bewaakt?” | Overzicht logbronnen, alertproces, ticketvoorbeeld | Bronnen, bewaartermijn, opvolgproces | Gedetailleerde detectieregels of kwetsbare configuratie |
| Patchmanagement | “Hoe snel patchen jullie kwetsbaarheden?” | Patchbeleid, patchrapport, vulnerability-overzicht | Proces, prioriteiten, voorbeeldrapport | Volledige kwetsbaarhedenlijst zonder context |
| Leveranciers | “Beoordelen jullie eigen leveranciers?” | Leveranciersregister, classificatie, DPA/SLA-overzicht | Categorieën, beoordelingsproces | Commerciële contractdetails, onnodige persoonsgegevens |
| Awareness | “Train je medewerkers?” | Awarenessbeleid, trainingsplanning, deelnameoverzicht | Thema’s, frequentie, deelnamepercentage | Individuele scores of namen zonder reden |
| Beleid | “Hebben jullie securitybeleid?” | Informatiebeveiligingsbeleid, acceptable use, thuiswerkbeleid | Versie, datum, scope, samenvatting | Interne uitzonderingen zonder uitleg |
| Continuïteit | “Kunnen jullie blijven leveren bij verstoring?” | Continuïteitsplan, herstelprioriteiten, contactproces | Hoofdlijnen en verantwoordelijkheden | Gevoelige noodprocedures of technische afhankelijkheden |
1. MFA-bewijs: laat zien dat accounts beschermd zijn
MFA is vaak één van de eerste onderwerpen in securityvragenlijsten. Klanten vragen bijvoorbeeld of MFA verplicht is voor beheerders, medewerkers, externe toegang of systemen met klantdata.
Goede bewijsstukken zijn:
- een geanonimiseerd overzicht van MFA-registratie;
- een Conditional Access-samenvatting;
- een beleid waarin staat voor welke accounts MFA verplicht is;
- een korte toelichting op uitzonderingen;
- een roadmap als MFA nog niet overal actief is.
Een veilig antwoord kan zijn:
MFA is verplicht voor accounts met toegang tot klantdata en voor beheeraccounts. We kunnen een geanonimiseerd overzicht delen waaruit de scope, status en laatste controledatum blijken. Voor resterende accounts staat verdere uitrol gepland.
Vermijd harde claims als “MFA staat overal aan” als dat niet klopt. Als de maatregel gedeeltelijk is ingericht, benoem dan scope en roadmap. Dat is sterker dan een te ruime claim die later niet aantoonbaar blijkt.
2. Back-upbewijs: toon niet alleen dat back-ups bestaan, maar dat herstel getest is
Een klant heeft weinig aan de zin “wij maken back-ups” zonder context. Sterker bewijs laat zien wat wordt geback-upt, hoe vaak, hoe lang het wordt bewaard en wanneer herstel voor het laatst is getest.
Goede bewijsstukken zijn:
- back-upbeleid;
- overzicht van back-upscope;
- restore-testverslag;
- screenshot of rapportage van back-upstatus;
- retentieoverzicht;
- samenvatting van hersteldoelstellingen als die bestaan.
Een veilig antwoord kan zijn:
Voor de relevante systemen is een back-upproces ingericht. De back-upstatus wordt gecontroleerd en periodiek wordt herstel getest. Op verzoek kunnen we een samenvatting delen van scope, retentie en laatste restore-testdatum.
Deel liever geen volledige infrastructuurtekeningen, opslaglocaties, geheime URL’s of technische back-upconfiguraties als dat niet nodig is. Maak een klantvriendelijke samenvatting.
3. Incidentprocedure: bewijs dat je weet wie wat doet bij een incident
Klanten willen weten of je voorbereid bent op incidenten. Dat betekent niet dat je je volledige interne draaiboek hoeft te delen. Vaak is een compacte procedure of samenvatting voldoende.
Goede bewijsstukken zijn:
- incident responseplan;
- meldprocedure;
- rolverdeling;
- escalatiematrix;
- template voor incidentregistratie;
- bewijs van oefening of evaluatie.
Een veilig antwoord kan zijn:
Er is een incidentprocedure ingericht met rollen, meldpad en escalatiestappen. Bij incidenten die impact kunnen hebben op klanten wordt beoordeeld welke melding of communicatie nodig is. We kunnen een samenvatting van het proces delen zonder interne contactgegevens of operationele details.
NCSC benoemt voor toeleveranciers ook het belang van voorbereiding op incidenten, back-ups, bellijst en incident responseplan. Dat maakt dit onderwerp logisch in klantvragen, zeker bij leveranciers die onderdeel zijn van een kritieke keten.
4. Toegangsbeheer: bewijs dat toegang niet willekeurig wordt gegeven
Veel securityvragen gaan over wie toegang heeft tot systemen of klantdata. Klanten willen zien dat toegang wordt toegekend, gewijzigd en ingetrokken op basis van een proces.
Goede bewijsstukken zijn:
- rechtenmatrix;
- onboarding- en offboardingprocedure;
- access review-verslag;
- overzicht van rolgebaseerde toegang;
- procedure voor beheerdersrechten;
- bewijs van periodieke controle.
Een veilig antwoord kan zijn:
Toegang wordt toegekend op basis van rol en noodzaak. Nieuwe toegang loopt via een aanvraagproces en bij uitdiensttreding wordt toegang ingetrokken. Periodiek vindt controle plaats op accounts en rechten.
Deel niet zomaar een volledige gebruikerslijst. Maak liever een geanonimiseerde samenvatting of toon het proces, de reviewdatum en de verantwoordelijkheden.
5. Logging en monitoring: toon dat signalen worden gezien en opgevolgd
Niet elk MKB-bedrijf heeft een SOC of 24/7 monitoring. Dat hoeft ook niet altijd. Maar als een klant vraagt naar logging of monitoring, moet je duidelijk maken welke logs relevant zijn, wie signalen bekijkt en hoe opvolging werkt.
Goede bewijsstukken zijn:
- overzicht van logbronnen;
- beleid voor logretentie;
- alertproces;
- voorbeeld van ticketregistratie;
- samenvatting van monitoringafspraken met IT-partner;
- rapportage uit Microsoft 365, endpointbeveiliging of andere tooling.
Een veilige formulering is:
Voor de belangrijkste systemen worden beveiligingssignalen geregistreerd. Alerts worden opgevolgd door de verantwoordelijke beheerder of IT-partner. De dekking en responstijden verschillen per systeem en zijn opgenomen in onze verbeterroadmap.
Dit is eerlijker dan “wij monitoren alles” als dat niet klopt.
6. Patchmanagement en kwetsbaarheden: bewijs dat updates niet toevallig gebeuren
Klanten vragen vaak of systemen tijdig worden geüpdatet en kwetsbaarheden worden opgevolgd. Een goed bewijsstuk laat zien dat patchen een proces is, geen losse actie.
Goede bewijsstukken zijn:
- patchbeleid;
- updateplanning;
- rapportage van beheerde apparaten;
- kwetsbaarhedenoverzicht met status;
- changelog of ticketvoorbeeld;
- toelichting op kritieke patches.
Een veilig antwoord kan zijn:
Beveiligingsupdates worden beoordeeld op risico en urgentie. Kritieke updates krijgen voorrang. Voor beheerde systemen kunnen we een samenvatting delen van het patchproces en recente controlepunten.
Deel geen volledige kwetsbaarhedenlijst zonder context. Daarmee kun je onnodig nieuwe risico’s blootleggen.
7. Leveranciersbeheer: bewijs dat je eigen keten niet vergeten wordt
Als jij leverancier bent, kijkt jouw klant soms ook naar jouw leveranciers. Denk aan hosting, cloudplatformen, IT-beheer, softwaretools, salarissoftware, supportpartijen of subverwerkers.
Goede bewijsstukken zijn:
- leveranciersregister;
- classificatie van kritieke leveranciers;
- DPA- of verwerkersovereenkomstoverzicht;
- SLA/DAP-samenvatting;
- procedure voor beoordeling van nieuwe leveranciers;
- overzicht van subverwerkers als dat relevant is.
Een veilige formulering is:
Kritieke leveranciers worden geregistreerd en beoordeeld op relevantie voor dienstverlening, data en continuïteit. Voor leveranciers met toegang tot klantdata of belangrijke systemen leggen we afspraken vast over beveiliging, beschikbaarheid en incidenten.
Dit sluit goed aan bij klanten die door NIS2/Cbw meer aandacht besteden aan ketenrisico’s. Lees eventueel ook: NIS2-vragen van klanten: wat betekent dit voor leveranciers?
Wat kun je beter niet meesturen?
Meer bewijs is niet automatisch beter. Te veel informatie kan juist risico’s vergroten of de beoordeling onduidelijker maken.
| Niet zomaar delen | Waarom voorzichtig zijn? | Beter alternatief |
|---|---|---|
| Volledige gebruikerslijsten | Bevat persoonsgegevens en interne rollen | Geanonimiseerde samenvatting of procesbeschrijving |
| Adminnamen en beheeraccounts | Kan aanvallers helpen | Toon scope en controlestatus zonder namen |
| Tenant-ID’s, IP-adressen of geheime URL’s | Kan technisch misbruikt worden | Deel afgeschermde screenshots of samenvatting |
| Volledige kwetsbaarhedenlijsten | Legt zwakke plekken bloot | Deel statusoverzicht en herstelproces |
| Interne escalatienummers | Niet altijd nodig voor klantbeoordeling | Deel rolverdeling en meldkanaal |
| Complete infrastructuurtekeningen | Geeft te veel aanvalsinformatie | Deel high-level architectuur of scopebeschrijving |
| Ongecontroleerde exports | Moeilijk te lezen en vaak te gevoelig | Maak een evidence summary met datum en scope |
Zeker bij een vendor assessment of klantportaal is dit belangrijk. Upload niet alles wat je hebt. Upload wat de vraag beantwoordt.
Wat als je een bewijsstuk nog niet hebt?
Dan is het meestal beter om eerlijk en concreet te zijn dan om te overclaimen. Je kunt vaak gedeeltelijk antwoorden, zolang je duidelijk maakt wat al geregeld is, wat ontbreekt en wat de planning is.
Voorbeeld:
De maatregel is gedeeltelijk ingericht. Voor beheeraccounts en accounts met toegang tot klantdata is MFA actief. Voor overige accounts loopt de uitrol. We kunnen een geanonimiseerd overzicht delen van de huidige status en de geplande verbeterstappen.
Of:
Er is een back-upproces ingericht. Een formeel restore-testverslag is nog niet beschikbaar. De eerstvolgende restore-test staat gepland en wordt daarna als bewijsstuk toegevoegd aan onze bewijsmap.
Gebruik dit soort formuleringen alleen als ze kloppen. Een roadmap is geen excuus om niets te doen. Maar een eerlijke roadmap is vaak sterker dan een te harde claim zonder bewijs.
Meer hierover lees je in: Mag je gedeeltelijk antwoorden op een securityvraag?
Wanneer is een Cybersecurity Bewijsmap handig?
Een losse securityvragenlijst kun je soms eenmalig beantwoorden. Maar als meerdere klanten dezelfde vragen stellen, wordt het inefficiënt en risicovol om steeds opnieuw bewijs te zoeken.
Een Cybersecurity Bewijsmap helpt dan om bewijsstukken gestructureerd klaar te zetten:
- per klantvraag of thema;
- met datum en eigenaar;
- met veilige toelichting;
- met open punten en roadmap;
- zonder onnodige interne details;
- herbruikbaar voor vragenlijsten, vendor assessments, NIS2/Cbw-ketenvragen en aanbestedingen.
Het doel is niet om te doen alsof alles perfect is. Het doel is om aantoonbaar, consistent en eerlijk te laten zien wat geregeld is.
Wanneer is een ISO-certificaat of formele audit toch nodig?
Soms vraagt een klant niet alleen om bewijsstukken, maar om een formeel certificaat of auditrapport. Bijvoorbeeld:
- “Lever een geldig ISO 27001-certificaat aan.”
- “ISO 27001-certificering is verplicht voor gunning.”
- “Alleen leveranciers met certificaat worden toegelaten.”
- “Upload een SOC 2 Type II-rapport.”
In dat geval kun je een Bewijsmap niet presenteren als vervanging. Je kunt wel laten beoordelen of de klantvraag echt een harde certificaateis is, of dat er ruimte is voor aantoonbare beheersing, maatregelen en roadmap. Zie ook: zonder ISO 27001 toch security aantonen.
Praktische checklist voordat je bewijs deelt
Loop deze punten langs voordat je een bewijsstuk uploadt of meestuurt:
- Beantwoordt dit bewijsstuk precies de klantvraag?
- Is duidelijk welke maatregel het bewijsstuk ondersteunt?
- Staat er een datum, scope of eigenaar bij?
- Bevat het geen onnodige persoonsgegevens?
- Zijn technische details afgeschermd als die niet nodig zijn?
- Is de screenshot of export begrijpelijk voor een klantreviewer?
- Is duidelijk wat nog niet geregeld is?
- Staat een open punt op een roadmap?
- Is de formulering niet sterker dan de werkelijkheid?
- Kan dit bewijs later opnieuw gebruikt worden?
Als je op meerdere punten twijfelt, is het verstandig om de bewijsstukken eerst te laten structureren voordat je ze naar de klant stuurt.
Voorbeeld van een veilige toelichting bij bewijsstukken
Je kunt bewijsstukken begeleiden met een korte toelichting zoals:
Bijgevoegd vindt u een geanonimiseerde samenvatting van de relevante beveiligingsmaatregelen. Per onderwerp is aangegeven welke maatregel is ingericht, welk bewijsstuk beschikbaar is en welke verbeterpunten nog op de roadmap staan. Gevoelige interne details, persoonsgegevens en technische configuratiegegevens zijn afgeschermd waar die niet noodzakelijk zijn voor de beoordeling.
Deze tekst maakt duidelijk dat je transparant bent, maar ook zorgvuldig omgaat met interne security-informatie.
Hulp nodig met bewijsstukken bij een klantvraag?
Heeft je klant een securityvragenlijst, vendor assessment of NIS2/Cbw-vraag gestuurd en weet je niet welke bewijsstukken verstandig zijn? InstantSecure helpt de vraag vertalen naar eis, maatregel, bewijs en roadmap.
Logische vervolgstap: start met een Cybersecurity Bewijsmap Sprint of laat je klantvraag beoordelen.
Bronnen en actuele overheidsinformatie
- NCSC, De Cyberbeveiligingswet en toeleveranciers: Cbw-organisaties moeten ketenrisico’s beheersen en kunnen eisen stellen aan toeleveranciers. https://www.ncsc.nl/cyberbeveiligingswet-nis2/de-cyberbeveiligingswet-en-toeleveranciers
- NCSC, Toeleveranciers van Cbw-organisaties: basisprincipes voor digitale weerbaarheid, waaronder risico’s in kaart brengen, veilig gedrag, systemen beschermen, toegangsbeheer en incidentvoorbereiding. https://www.ncsc.nl/cyberbeveiligingswet-nis2/toeleveranciers-van-cbw-organisaties
- NCSC, Verdiepende maatregelen voor toeleveranciers: aanvullende maatregelen rond risicomanagement, patchmanagement, MFA, least privilege, incidentrespons en back-ups. https://www.ncsc.nl/cyberbeveiligingswet-nis2/verdiepende-maatregelen-voor-toeleveranciers
