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.
Gebruik deze evidence-hub
Kies het thema dat bij de klantvraag hoort. Ieder bewijsstuk moet minimaal context bevatten over scope, datum, systeem of omgeving, eigenaar, status, uitzonderingen en de laatste relevante test of review.
- MFA en toegangsbeveiliging
- Gebruikers- en toegangsbeheer
- Back-ups
- Hersteltests
- Logging en monitoring
- Incidentmanagement
- Beleid en procedures
- Leveranciersbeheer
- Awareness en training
- Patching en kwetsbaarheden
- Encryptie en gegevensbescherming
- Continuïteit
- Bewijs van periodieke controle
Een screenshot is niet automatisch sterk bewijs. Beleid zonder aantoonbare uitvoering is onvoldoende en een instelling zonder scope of datum is moeilijk te beoordelen. Lever proportioneel bewijs: een klant hoeft niet automatisch volledige beheerexports te ontvangen en een ontbrekende maatregel mag niet worden verhuld. Lees ook hoe je onderscheid maakt tussen bewijs dat een maatregel bestaat en bewijs dat de maatregel daadwerkelijk werkt.
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 |
Verdiepende gidsen per bewijssoort
De bewijsmatrix hieronder geeft het overzicht. Gebruik voor de drie vaakst gevraagde maatregelen ook deze verdiepende gidsen:
- MFA aantonen zonder gevoelige informatie te delen
- Back-ups en een hersteltest aantonen aan een klant
- Incidentmanagement aantonen met procedure, rollen en oefenbewijs
De verdiepende artikelen behandelen per onderwerp de scope, veilige bewijssoorten, gevoelige informatie, voorbeeldantwoorden en open punten. Gebruik ze als aanvulling op deze evidence-hub, niet als vervanging van de concrete klantvraag.
MFA en toegangsbeveiliging
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.
Verdieping: zo toon je MFA aan zonder gevoelige informatie te delen. Sterk bewijs benoemt wat de klant vraagt, het bruikbare bewijs, de scope en datum, afgeschermde waarden, beperkingen van het bewijs en de aanpak voor ontbrekende dekking.
Back-ups
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.
Verdieping: zo toon je back-ups en een echte hersteltest aan. Een taakstatus of back-updashboard bewijst niet automatisch dat herstel werkelijk is getest.
Hersteltests
- Klantvraag: kan data of dienstverlening aantoonbaar worden hersteld?
- Bruikbaar bewijs: hersteltestverslag, datum, geteste scope, resultaat en verbeterpunten.
- Context: systeem, back-upset, testmethode, eigenaar en eerstvolgende review.
- Afschermen: opslaglocaties, credentials, geheime URL’s en klantdata.
- Niet sterk genoeg: alleen een geslaagde back-uptaak of een ongedateerde screenshot.
- Als het ontbreekt: zeg dat geen gedocumenteerde hersteltest beschikbaar is en plan een realistische test.
Lees de volledige gids over back-ups en hersteltests aantonen.
Incidentmanagement
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.
Verdieping: bekijk hoe je incidentmanagement aantoont met procedure, rollen, registratie en oefenbewijs. Deel geen onnodige incidentdetails, persoonsgegevens of operationele contactgegevens.
Gebruikers en toegangsbeheer
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.
Logging en monitoring
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.
Patching en kwetsbaarheden
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.
Leveranciersbeheer
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?
Beleid en procedures
- Klantvraag: zijn verantwoordelijkheden en werkwijzen vastgesteld?
- Bruikbaar bewijs: vastgesteld beleid, procedure, eigenaar, versie en reviewdatum.
- Context: toepassingsgebied, goedkeurder, ingangsdatum en koppeling met uitvoering.
- Afschermen: interne uitzonderingen, contactgegevens en gevoelige bijlagen zonder noodzaak.
- Niet sterk genoeg: een generieke template zonder eigenaar of aantoonbare toepassing.
- Als het ontbreekt: benoem de huidige werkwijze en plan vaststelling en review.
Awareness en training
- Klantvraag: worden medewerkers passend geïnstrueerd en getraind?
- Bruikbaar bewijs: programma, onderwerpen, frequentie en geaggregeerde deelname.
- Context: doelgroep, periode, eigenaar en opvolging.
- Afschermen: individuele scores, namen en personeelsgegevens.
- Niet sterk genoeg: alleen een uitnodiging of beleidszin zonder uitvoering.
- Als het ontbreekt: leg vast welke instructie al plaatsvindt en plan een passend programma.
Encryptie en gegevensbescherming
- Klantvraag: hoe zijn relevante gegevens tijdens opslag en transport beschermd?
- Bruikbaar bewijs: architectuursamenvatting, beleidsinstelling of gecontroleerde configuratiesamenvatting.
- Context: datatype, systeem, transport of opslag, sleutelverantwoordelijkheid en uitzonderingen.
- Afschermen: sleutels, secrets, certificaat-private keys en volledige technische configuratie.
- Niet sterk genoeg: “encryptie staat aan” zonder scope of controle.
- Als het ontbreekt: benoem de feitelijke situatie en laat technische inrichting eerst beoordelen.
Continuiteit en herstel
- Klantvraag: kan de organisatie kritieke diensten bij verstoring voortzetten of herstellen?
- Bruikbaar bewijs: continuïteitsplan, prioriteiten, afhankelijkheden, oefening en verbeterpunten.
- Context: kritieke dienst, eigenaar, scenario, datum en hersteldoel.
- Afschermen: gevoelige noodprocedures, privécontactgegevens en kwetsbare afhankelijkheden.
- Niet sterk genoeg: alleen een algemene beschikbaarheidsbelofte.
- Als het ontbreekt: identificeer kritieke processen en plan een proportionele oefening.
Bewijs van periodieke controle
- Klantvraag: wordt de maatregel niet alleen ingericht, maar ook onderhouden?
- Bruikbaar bewijs: reviewverslag, controlelog, testdatum, goedkeuring en opvolgactie.
- Context: frequentie, scope, eigenaar, uitkomst en volgende controledatum.
- Afschermen: volledige ruwe logs, gebruikerslijsten en interne kwetsbaarheidsdetails.
- Niet sterk genoeg: een oude eenmalige screenshot zonder opvolging.
- Als het ontbreekt: vermeld dat periodieke controle nog niet aantoonbaar is en plan eigenaar en ritme.
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.
Deel nooit onbewerkt: wachtwoorden, herstelcodes, secrets, volledige gebruikerslijsten, interne IP-adressen, volledige kwetsbaarheidsdetails, klantdata, ongeredigeerde logs of configuratie-exports met gevoelige waarden.
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?
Voor één concrete vragenlijst is de primaire route hulp bij die uitvraag. Keren dezelfde klantvragen en bewijsstukken terug, dan kan een Cybersecurity Bewijsmap als secundaire vervolgstap helpen met versies, eigenaren, scope, reviewdatums en open punten.
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?
Gebruik de primaire actie onder dit artikel om bewijs voor één concrete vragenlijst te laten beoordelen. Breng terugkerend bewijs pas daarna structureel samen.
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
Bewijs direct aan de vragenlijst koppelen
Werk niet met een losse map bewijsstukken. Bekijk hulp bij het invullen van een securityvragenlijst om per klantvraag het juiste bewijs, de veilige deelversie, scope en open punten vast te leggen.
