Kort antwoord
Ja, je mag vaak gedeeltelijk antwoorden op een securityvraag van een klant, zolang je eerlijk bent over wat al is ingericht, wat nog niet volledig werkt en welk bewijs je kunt laten zien. Een goed gedeeltelijk antwoord is meestal sterker dan een harde "ja" zonder bewijs of een kale "nee" zonder plan.
Veilige vuistregel: antwoord niet alleen met ja of nee. Koppel je antwoord aan drie dingen: de huidige maatregel, het beschikbare bewijs en de volgende stap op de roadmap.
Voorbeeld: "MFA is ingericht voor beheerders en Microsoft 365. Uitrol naar de resterende applicaties staat gepland. We kunnen een geanonimiseerd overzicht van de huidige inrichting delen."
Krijg je een securityvragenlijst, vendor assessment of klantportaal waar veel ja/nee-vragen in staan? Laat de vraag dan eerst inhoudelijk beoordelen via securityvragenlijst van klant invullen, zeker als het antwoord contractueel of commercieel gevoelig is.
Wanneer is een gedeeltelijk antwoord verstandig?
Een gedeeltelijk antwoord is verstandig als de maatregel niet volledig afwezig is, maar ook nog niet overal aantoonbaar of volwassen is ingericht.
Denk aan situaties zoals:
- MFA staat aan voor Microsoft 365, maar nog niet voor alle SaaS-applicaties.
- Back-ups zijn ingericht, maar restore-tests worden nog niet periodiek vastgelegd.
- Er is een incidentprocedure, maar nog geen formele oefening of evaluatie.
- Er is toegangsbeheer, maar reviews worden nog niet aantoonbaar periodiek uitgevoerd.
- Er is securitybeleid, maar het is nog niet volledig vastgesteld of gedeeld met medewerkers.
- Er is logging beschikbaar, maar actieve monitoring of opvolging is beperkt.
- Leveranciers worden praktisch beoordeeld, maar er is nog geen formeel leveranciersregister.
In zulke gevallen is "ja" vaak te hard en "nee" vaak te zwak. Het professionele antwoord zit ertussenin: gedeeltelijk ingericht, met bewijs en verbeterplan.
Ja, nee, gedeeltelijk of niet van toepassing?
Gebruik deze tabel als eerste denkkader voordat je een klantvraag invult.
| Situatie | Antwoordrichting | Voorwaarde | Risico |
|---|---|---|---|
| Maatregel is volledig ingericht en aantoonbaar | Ja | Je hebt bewijs dat past bij de vraag | Laag, mits bewijs klopt |
| Maatregel is deels ingericht | Gedeeltelijk | Benoem scope, bewijs en roadmap | Middel, als je te vaag blijft |
| Maatregel bestaat niet | Nee of gepland | Wees eerlijk en geef eventueel planning | Hoog als je toch "ja" zegt |
| Vraag past niet bij jouw dienstverlening | Niet van toepassing | Leg kort uit waarom | Middel, als klant een toelichting verwacht |
| Vraag is onduidelijk of te breed | Toelichting vragen | Vraag scope of definitie op | Laag, vaak verstandig |
| Vraag is harde contracteis of aanbestedingseis | Eerst beoordelen | Niet blind invullen | Hoog bij verkeerde claim |
Bij twijfel is het slimmer om de klantvraag eerst te laten beoordelen. Zeker bij ISO 27001, NIS2/Cbw, SC10/SC20, aanbestedingen of vendor assessments kan één verkeerd antwoord later als contractuele claim terugkomen.
Waarom een harde "ja" gevaarlijk kan zijn
Een securityvraag lijkt soms simpel, maar de betekenis kan veel breder zijn dan je denkt.
Voorbeeld:
"Do you enforce MFA for all users?"
Als je hier "yes" antwoordt, kan de klant begrijpen dat MFA voor alle gebruikers, alle applicaties en alle externe toegang verplicht is. Misschien bedoel jij alleen Microsoft 365 of alleen beheerdersaccounts. Dan ontstaat later een verschil tussen wat je hebt bedoeld en wat je hebt verklaard.
Dat is precies waarom een gedeeltelijk antwoord soms veiliger is:
"MFA is enforced for Microsoft 365 and administrator accounts. For other business applications, MFA rollout is planned and tracked on our security roadmap."
Dit klinkt minder stoer dan een harde "yes", maar het is veel beter verdedigbaar.
Wanneer moet je juist geen gedeeltelijk antwoord gebruiken?
Gedeeltelijk antwoorden is geen truc om alsnog positief te lijken. Soms moet je duidelijker zijn.
Gebruik geen gedeeltelijk antwoord als:
- de maatregel helemaal niet bestaat;
- je geen enkel bewijs hebt;
- de klant expliciet een certificaat, auditverklaring of harde contracteis noemt;
- het antwoord in een aanbesteding als knock-outcriterium wordt beoordeeld;
- de vraag gaat over een wettelijke of contractuele verplichting die je niet begrijpt;
- je eigenlijk "nee" bedoelt, maar dat commercieel spannend vindt.
Vooral bij ISO 27001 is nuance belangrijk. Als een klant vraagt of je ISO 27001-gecertificeerd bent, is "gedeeltelijk" meestal niet het juiste antwoord. Je bent gecertificeerd of je bent dat niet. Wat je wél kunt doen, is uitleggen welke maatregelen, beleidsstukken en bewijsstukken al aanwezig zijn. Zie daarvoor ook zonder ISO 27001 toch security aantonen.
Voorbeelden van veilige gedeeltelijke antwoorden
Onderstaande voorbeelden zijn bewust voorzichtig. Pas ze altijd aan op je echte situatie.
| Vraag van klant | Te hard antwoord | Beter gedeeltelijk antwoord |
|---|---|---|
| Is MFA actief voor alle gebruikers? | "Ja" | "MFA is actief voor Microsoft 365 en beheerdersaccounts. Uitrol naar overige applicaties staat gepland." |
| Worden back-ups getest? | "Ja, back-ups zijn geregeld" | "Back-ups zijn ingericht. Restore-tests worden uitgevoerd, maar de periodieke vastlegging wordt aangescherpt." |
| Hebben jullie een incident response plan? | "Ja" | "Er is een incidentprocedure met meldpad en rolverdeling. Een formele tabletop-oefening staat nog op de roadmap." |
| Reviewen jullie toegangsrechten periodiek? | "Ja" | "Toegangsrechten worden bij in- en uitdiensttreding aangepast. Periodieke review wordt nog structureel vastgelegd." |
| Zijn leveranciers beoordeeld op security? | "Ja" | "Kritieke leveranciers zijn bekend. Formele securitybeoordeling per leverancier wordt verder ingericht." |
| Hebben jullie ISO 27001? | "Ja, grotendeels" | "Nee, we zijn niet ISO 27001-gecertificeerd. Wel kunnen we aantonen welke maatregelen en bewijsstukken al beschikbaar zijn." |
| Monitoren jullie securityevents? | "Ja" | "Logging is beschikbaar voor kernsystemen. Actieve opvolging en rapportage worden verder ingericht." |
De kracht zit niet in mooier praten. De kracht zit in precies genoeg eerlijkheid: wat is geregeld, wat kun je aantonen en wat staat nog open?
De beste structuur voor een gedeeltelijk antwoord
Een goed gedeeltelijk antwoord bestaat uit vijf onderdelen.
| Onderdeel | Vraag die je beantwoordt | Voorbeeld |
|---|---|---|
| Scope | Waar geldt de maatregel al? | Microsoft 365, beheerdersaccounts, productiesystemen |
| Status | Hoe volwassen is het ingericht? | actief, deels ingericht, gepland, in review |
| Bewijs | Wat kun je laten zien? | screenshot, beleid, procedure, export, log, reviewdatum |
| Beperking | Wat is nog niet af? | nog niet alle applicaties, nog geen periodieke test |
| Roadmap | Wat is de volgende stap? | uitrol Q3, review per kwartaal, procedure formaliseren |
Een simpele formule:
"[Maatregel] is ingericht voor [scope]. We kunnen [bewijsstuk] delen. [Open punt] staat op de roadmap voor [periode/volgende stap]."
Voorbeeld:
"MFA is ingericht voor Microsoft 365 en beheerdersaccounts. We kunnen een geanonimiseerd beleids- of configuratieoverzicht delen. Uitrol naar overige kritieke applicaties staat op de roadmap."
Wat kun je als bewijs meesturen?
Bij een gedeeltelijk antwoord helpt bewijs om te laten zien dat je niet alleen een belofte doet. Maar deel niet zomaar ruwe exports of gevoelige configuratie.
| Thema | Mogelijk bewijs | Liever niet delen |
|---|---|---|
| MFA | geanonimiseerd beleidscreenshot, Conditional Access-samenvatting, korte toelichting | volledige tenantdetails, adminaccounts, gebruikerslijsten |
| Back-ups | back-upoverzicht, testdatum, herstelprocedure | volledige infrastructuurdetails of opslaglocaties |
| Incidenten | incidentprocedure, meldpad, rolverdeling | interne noodnummers of namen zonder noodzaak |
| Toegang | rollenmatrix, reviewproces, joiner/mover/leaver-procedure | volledige autorisatielijsten |
| Logging | samenvatting van logbronnen en bewaartermijnen | ruwe logs met persoonsgegevens of technische details |
| Leveranciers | leveranciersregister, beoordelingsproces, DPA-overzicht | contracten of subverwerkerdetails die niet relevant zijn |
| Awareness | trainingsplanning, korte registratie, beleid | persoonsgegevens van medewerkers zonder reden |
Wil je hier structureel grip op krijgen, dan is een Cybersecurity Bewijsmap logischer dan telkens opnieuw losse screenshots en documenten verzamelen.
Wat als de klant alleen ja/nee toestaat?
Veel klantportalen laten weinig ruimte voor nuance. Toch moet je oppassen met blind "ja" aanvinken.
Mogelijke aanpak:
- Vul alleen "ja" in als het feitelijk klopt binnen de scope van de vraag.
- Gebruik het opmerkingenveld voor nuance.
- Upload een korte toelichting als het portaal dat toestaat.
- Vraag verduidelijking als "all users", "all systems" of "continuous monitoring" onduidelijk is.
- Leg intern vast waarom je voor een antwoord hebt gekozen.
Voorbeeld bij een ja/nee-portaal:
Antwoord: Yes / Partially
Toelichting: "MFA is enforced for Microsoft 365 and privileged accounts. Rollout to remaining business applications is planned and tracked."
Bij een vendor assessment is deze nuance extra belangrijk, omdat procurement of risk teams je antwoorden later kunnen vergelijken met contracten, bewijsstukken of audits.
Hoe voorkom je dat een gedeeltelijk antwoord zwak overkomt?
Veel ondernemers zijn bang dat "gedeeltelijk" slecht klinkt. Maar dat hoeft niet. Een goed gedeeltelijk antwoord laat juist zien dat je grip hebt.
Zwak:
"Nog niet helemaal geregeld."
Sterker:
"De maatregel is ingericht voor de belangrijkste systemen. De resterende scope is bekend en staat op de roadmap. We kunnen het huidige bewijs en de geplande vervolgstap toelichten."
Zwak:
"We zijn ermee bezig."
Sterker:
"Er is een conceptprocedure beschikbaar. Formele vaststelling en jaarlijkse review worden toegevoegd aan de roadmap."
Zwak:
"Niet van toepassing."
Sterker:
"Niet van toepassing, omdat wij geen hosting of beheer van klantdata uitvoeren. Voor onze eigen Microsoft 365-omgeving zijn MFA en toegangsbeheer wel ingericht."
Wanneer is een roadmap geloofwaardig?
Een roadmap is alleen nuttig als hij concreet genoeg is. "We gaan dit verbeteren" is te vaag.
Een geloofwaardige roadmap noemt minimaal:
- welke maatregel ontbreekt of deels is ingericht;
- waarom die maatregel relevant is;
- welke stap wordt genomen;
- wie intern eigenaar is;
- wanneer de stap ongeveer gepland staat;
- welk bewijs daarna beschikbaar komt.
Voorbeeld:
"Een formele restore-test wordt toegevoegd aan het kwartaalproces. Na uitvoering leggen we datum, scope, resultaat en eventuele verbeterpunten vast."
Dat is veel sterker dan:
"Back-ups worden binnenkort getest."
Wanneer moet je klantvraag eerst laten beoordelen?
Laat een securityvraag liever niet blind invullen als:
- er veel vragen over ISO 27001, NIS2/Cbw, SC10/SC20 of certificering in staan;
- de klant vraagt om bewijsstukken die gevoelige informatie bevatten;
- je twijfelt of een antwoord contractueel bindend kan worden;
- de vragenlijst onderdeel is van een aanbesteding;
- procurement vraagt om uploads in een klantportaal;
- je meerdere klanten vergelijkbare vragen ziet stellen;
- je niet zeker weet of je "ja", "nee" of "gedeeltelijk" moet antwoorden.
In dat geval is een Eerste Beoordeling klantvraag vaak verstandiger dan zelf gokken. Je voorkomt daarmee dat je te veel belooft, te weinig uitlegt of bewijs deelt dat je beter had kunnen samenvatten.
Checklist voordat je gedeeltelijk antwoordt
Gebruik deze checklist voordat je iets terugstuurt.
- Begrijp ik precies wat de klant vraagt?
- Is de scope duidelijk: alle systemen, alle gebruikers of alleen klantdata?
- Klopt mijn antwoord feitelijk?
- Kan ik het antwoord bewijzen?
- Deel ik niet te veel gevoelige informatie?
- Benoem ik wat nog openstaat?
- Is er een concrete vervolgstap of roadmap?
- Is dit een harde eis, contracteis of aanbestedingseis?
- Moet iemand intern meekijken voordat dit naar de klant gaat?
- Is dit antwoord later verdedigbaar bij incident, audit of klantreview?
Als je op meerdere punten twijfelt, is "even snel invullen" meestal geen goed idee.
Bronnen en actuele context
- NCSC: Cyberbeveiligingswet (NIS2) — officiële uitleg over Cbw, zorgplicht, meldplicht en registratieplicht: https://www.ncsc.nl/cyberbeveiligingswet-nis2
- NCSC: De Cyberbeveiligingswet en toeleveranciers — uitleg over ketenrisico, toeleveranciers, passende maatregelen en het feit dat certificaten nuttig kunnen zijn maar geen garantie bieden: https://www.ncsc.nl/cyberbeveiligingswet-nis2/de-cyberbeveiligingswet-en-toeleveranciers
Laatst gecontroleerd: 8 juli 2026.
Hulp nodig bij een gedeeltelijk antwoord?
Twijfel je of je "ja", "nee", "gedeeltelijk" of "niet van toepassing" moet antwoorden? Stuur de klantvraag, vragenlijst of portaaltekst eerst door.
We vertalen de vraag naar eis, maatregel, bewijs en roadmap, zonder te overclaimen en zonder compliance te garanderen.
