Securitymaatregel aantonen: bestaan is niet hetzelfde als werking

Kort antwoord

Een securitymaatregel aantonen bestaat uit meer dan bewijzen dat er iets is ingericht. Sterk bewijs maakt duidelijk:

1. wat de maatregel moet bereiken;
2. voor welke scope hij geldt;
3. hoe hij is ingericht;
4. dat hij daadwerkelijk wordt uitgevoerd;
5. dat de werking is gecontroleerd of getest;
6. welke uitzonderingen en bevindingen bestaan;
7. wanneer opnieuw wordt beoordeeld.

Een MFA-policy, back-upconfiguratie of incidentprocedure is dus nuttig bewijs van bestaan of ontwerp, maar niet automatisch bewijs van werking.

Onder de Cyberbeveiligingswet is dit onderscheid extra relevant: het NCSC noemt als afzonderlijke zorgplichtmaatregel dat organisaties beleid en procedures moeten hebben om de effectiviteit van maatregelen voor het beheersen van cyberbeveiligingsrisico's te beoordelen.

Laatst gecontroleerd: 4 augustus 2026. Dit artikel is praktische duiding voor evidence en leveranciersvragen. Het is geen formele audit- of assuranceconclusie.

Van document naar aantoonbare beheersing

Securityvragenlijsten leiden snel tot een map met:

• beleid;
• screenshots;
• configuratie-exports;
• certificaten;
• procedures;
• rapporten.

Dat is beter dan helemaal geen onderbouwing. Maar een map vol bestanden beantwoordt nog niet de vraag:

Werkt de maatregel in de praktijk zoals bedoeld?

Een volwassen bewijsstructuur maakt onderscheid tussen vier lagen.

Een vijfde laag hoort er eigenlijk altijd achteraan:

review en bijsturing.

Want een maatregel die vandaag werkt kan over drie maanden door een wijziging, uitzondering of nieuw systeem niet meer voldoende zijn.

Waarom 'we hebben een policy' geen eindbewijs is

Een beleidsdocument bewijst vooral dat iets is beschreven.

Dat is waardevol voor governance, maar zegt zonder aanvullende informatie nog weinig over uitvoering.

Voorbeeld:

'Alle medewerkers moeten MFA gebruiken.'

Mogelijke werkelijkheid:

• 82% van de accounts valt onder de policy;
• twee oude protocollen omzeilen moderne authenticatie;
• drie break-glassaccounts zijn terecht uitgezonderd;
• acht serviceaccounts zijn nog niet gemigreerd;
• nieuwe accounts komen niet automatisch in de juiste groep.

Het beleid kan dus correct zijn terwijl de feitelijke dekking onvolledig is.

Sterker bewijs koppelt beleid aan inrichting en uitvoering.

Waarom één screenshot ook niet genoeg is

Een screenshot is vaak makkelijk deelbaar en concreet. Toch heeft een screenshot vier beperkingen:

1. het is een momentopname;
2. de scope is vaak onduidelijk;
3. uitzonderingen zijn niet altijd zichtbaar;
4. het laat niet zien wat er na een fout gebeurt.

Een screenshot van 'MFA enabled' bewijst bijvoorbeeld niet automatisch dat:

• alle relevante accounts worden beschermd;
• legacy authentication is afgedekt;
• uitzonderingen worden beoordeeld;
• beheerders extra sterk zijn beveiligd;
• de configuratie periodiek wordt gecontroleerd.

Voeg daarom context toe:

• datum;
• tenant/omgeving zonder gevoelige identifiers;
• scope;
• aantal of percentage accounts;
• relevante uitzonderingen;
• laatste review;
• eigenaar;
• volgende review.

Praktisch bewijsmodel: maatregel → evidence → werking

Gebruik per belangrijke securitymaatregel een vaste kaart.

1. Doel

Wat moet de maatregel voorkomen of beperken?

Voorbeeld:

MFA: risico verkleinen dat een gestolen wachtwoord alleen voldoende is om een relevant account over te nemen.

2. Scope

Waar geldt de maatregel?

Bijvoorbeeld:

• alle medewerkers;
• alleen beheerders;
• Microsoft 365;
• productieomgeving;
• klantportaal;
• specifieke vestiging.

3. Inrichting

Hoe is de maatregel ingericht?

Bijvoorbeeld policy, procedure, technische configuratie of contractuele afspraak.

4. Evidence

Welk bewijs ondersteunt de inrichting?

Bijvoorbeeld:

• export;
• screenshot;
• policy;
• log;
• ticket;
• testverslag;
• managementreview.

5. Werkingstest

Hoe weet je dat de maatregel doet wat hij moet doen?

Bijvoorbeeld:

• restore-test;
• steekproef van uitdienstaccounts;
• access review;
• tabletop-oefening;
• gecontroleerde test van monitoring;
• technische veiligheidstest.

6. Uitzonderingen

Welke delen vallen buiten scope of wijken af?

Een maatregel zonder gedocumenteerde uitzonderingen ziet er vaak mooier uit dan hij werkelijk is.

7. Bevindingen en opvolging

Wat ging niet goed en wie pakt het op?

8. Reviewdatum

Wanneer wordt opnieuw vastgesteld dat het bewijs nog klopt?

Voorbeeld 1: MFA van bestaan naar werking

Zwak bewijs

'MFA staat aan.'

Bijlage: één screenshot van een policy.

Beter bewijs

MFA is verplicht voor alle interactieve Microsoft 365-gebruikers en beheerders binnen tenant X. De Conditional Access-policies zijn op 28 juli 2026 beoordeeld. Noodaccounts en drie technische accounts zijn uitgezonderd en afzonderlijk beheerst. De volgende formele review staat gepland voor oktober 2026.

Onderbouwing:

• geredigeerde policy-export;
• geanonimiseerd registratieoverzicht;
• uitzonderingenlijst;
• reviewregistratie.

Dat laatste pakket toont nog steeds geen absolute veiligheid, maar geeft veel meer context over scope en uitvoering.

Lees ook: Hoe toon je MFA aan zonder gevoelige informatie te delen?.

Voorbeeld 2: back-ups van groen dashboard naar herstelbewijs

Een dashboard met groene vinkjes laat zien dat back-uptaken volgens het systeem succesvol zijn uitgevoerd.

Maar de businessvraag is:

Kunnen we de data of dienst terugzetten wanneer dat nodig is?

Sterker bewijs bestaat bijvoorbeeld uit:

• back-upscope;
• retentie;
• jobhistorie;
• foutopvolging;
• laatste restore-test;
• wat precies is teruggezet;
• tijdsduur;
• resultaat;
• afwijkingen en verbeteracties.

Een hersteltest verandert de bewijssterkte fundamenteel omdat niet alleen het proces van kopiëren, maar ook de bruikbaarheid van herstel wordt getest.

Lees verder: Hoe toon je back-ups én een hersteltest aan een klant?.

Voorbeeld 3: incidentmanagement van procedure naar geoefende respons

Een incidentprocedure kan uitstekend geschreven zijn en toch nooit getest zijn.

Bewijs van bestaan:

• actuele incidentprocedure;
• rollen;
• contactgegevens;
• escalatiepad.

Bewijs van uitvoering/werking kan bijvoorbeeld zijn:

• tabletop-oefening;
• incidentregistratie;
• evaluatie na een oefening of echt incident;
• verbeteracties;
• herziening van contact- en meldroutes.

De vraag is niet of een organisatie ooit een incident heeft gehad. De vraag is of duidelijk is dat rollen en proces ook in de praktijk uitvoerbaar zijn en worden verbeterd.

Zie: Wat moet je aanleveren om incidentmanagement aan te tonen?.

Voorbeeld 4: toegangsbeheer

Bestaan

Er is een joiner/mover/leaver-procedure.

Inrichting

HR meldt personeelswijzigingen via een vast proces aan IT.

Uitvoering

Tickets laten zien dat accounts worden aangemaakt en ingetrokken.

Werking

Een steekproef of periodieke access review controleert bijvoorbeeld:

• of vertrokken medewerkers geen actieve toegang meer hebben;
• of privileged roles nog nodig zijn;
• of tijdelijke rechten zijn verlopen;
• of afwijkingen zijn opgevolgd.

Het sterke bewijs is dus niet alleen de procedure, maar de koppeling tussen procedure, transacties en review.

Voorbeeld 5: logging en monitoring

'We loggen alles' is geen bruikbaar antwoord.

Vraag in plaats daarvan:

• welke gebeurtenissen relevant zijn;
• welke bronnen zijn aangesloten;
• hoe lang logs beschikbaar zijn;
• welke signalen tot actie leiden;
• wie meldingen opvolgt;
• hoe false positives en gemiste signalen worden geëvalueerd.

Werkingsbewijs kan bestaan uit:

• testmelding;
• ticket na alert;
• periodieke use-case review;
• incident waar logging aantoonbaar is gebruikt;
• rapportage over dekking en storingen.

De precieze techniek hangt af van organisatie en risico. Claim daarom nooit 'volledige monitoring' als niet duidelijk is wat daadwerkelijk wordt gedetecteerd.

Wat zegt de Cyberbeveiligingswet over effectiviteit?

De Cbw treedt op 15 augustus 2026 in werking.

Het NCSC beschrijft tien zorgplichtmaatregelen. Maatregel 10 gaat expliciet over beleid en procedures om de effectiviteit van maatregelen voor het beheersen van cyberbeveiligingsrisico's te beoordelen.

Het NCSC adviseert onder meer om vast te leggen:

• waarom maatregelen worden getoetst;
• hoe vaak;
• op welke manier;
• wat met uitkomsten gebeurt;
• wie verantwoordelijk is voor borging.

Dit betekent niet dat iedere securitycontrol ieder kwartaal een volledige audit nodig heeft.

Wel moet een organisatie kunnen uitleggen hoe zij voorkomt dat maatregelen jarenlang op papier blijven bestaan zonder te weten of ze nog werken.

Effectiviteit is niet hetzelfde als 'geen incident gehad'

Een gevaarlijke redenering is:

'We hebben nog nooit een incident gehad, dus de maatregel werkt.'

Afwezigheid van een bekend incident bewijst weinig.

Een organisatie kan:

• niet zijn aangevallen;
• aanvallen niet hebben gedetecteerd;
• geluk hebben gehad;
• een maatregel hebben die alleen in een deel van de omgeving werkt.

Effectiviteit beoordeel je met vooraf bedachte criteria en relevante tests, niet alleen met incidenthistorie.

Ontwerp eerst een toetscriterium

Voordat je een maatregel test, bepaal je wat 'werken' betekent.

Voorbeelden:

MFA

Niet: 'MFA bestaat.'

Wel bijvoorbeeld:

• alle relevante interactieve accounts vallen onder afdwinging;
• beheerders vallen onder strengere policy;
• gedocumenteerde uitzonderingen hebben compenserende maatregelen;
• nieuwe accounts worden automatisch meegenomen.

Back-up

Niet: 'Backup job groen.'

Wel bijvoorbeeld:

• afgesproken systemen zijn gedekt;
• back-ups zijn bruikbaar;
• herstel van geselecteerde dataset of workload lukt;
• uitkomst en afwijkingen zijn vastgelegd.

Offboarding

Niet: 'HR stuurt een ticket.'

Wel bijvoorbeeld:

• toegang is binnen afgesproken proces ingetrokken;
• relevante SaaS-toegang wordt meegenomen;
• bedrijfsmiddelen zijn geregistreerd;
• uitzonderingen worden geëscaleerd.

Welke testfrequentie is goed?

Er is geen universele frequentie die voor iedere maatregel en organisatie klopt.

Bepaal de frequentie op basis van:

• risico en kritikaliteit;
• snelheid waarmee de omgeving verandert;
• contractuele verplichtingen;
• wettelijke eisen;
• incidenthistorie;
• betrouwbaarheid van geautomatiseerde controles;
• eerdere bevindingen.

Een jaarlijkse review kan voor stabiel beleid logisch zijn, terwijl privileged access of kwetsbaarheidsmanagement veel frequenter aandacht nodig kan hebben.

Daarnaast kunnen gebeurtenissen een tussentijdse test triggeren:

• migratie;
• nieuwe cloudomgeving;
• grote release;
• reorganisatie;
• security-incident;
• wijziging van leverancier;
• nieuwe beheerrechten.

Evidence freshness: bewijs heeft een houdbaarheid

Een veelvoorkomend probleem in securityvragenlijsten is hergebruik van oud bewijs.

Een screenshot uit 2024 kan technisch nog correct lijken, terwijl de omgeving in 2026 volledig anders is.

Leg daarom bij evidence vast:

• evidence date;
• eigenaar;
• scope;
• bron;
• reviewdatum;
• vervaldatum of 'review before';
• gebeurtenis die eerdere herbeoordeling vereist.

Dat maakt van een documentenmap een beheersbaar evidence-register.

Van Bewijsmap naar levend evidence-dossier

Een Cybersecurity Bewijsmap wordt sterker wanneer ieder bewijsstuk metadata krijgt.

Bijvoorbeeld:

Dat helpt bij terugkerende securityvragen, maar ook intern: je ziet welk bewijs veroudert voordat een klant erom vraagt.

Bekijk Cybersecurity Bewijsmap voor de bredere structuur.

Wanneer heb je onafhankelijke assurance nodig?

Zelf bewijs verzamelen en periodiek testen is niet hetzelfde als onafhankelijke assurance.

Zwaardere onafhankelijke beoordeling kan passend of verplicht zijn wanneer:

• een klant dat contractueel eist;
• een aanbesteding een specifieke verklaring verlangt;
• het risico zeer hoog is;
• een toezichthouder of andere stakeholder onafhankelijke zekerheid nodig heeft;
• de organisatie een formeel certificeringstraject kiest.

InstantSecure kan helpen bewijs en open punten voorbereidbaar te maken, maar geeft zelf geen formele audit- of assuranceverklaring.

Zie ook: ISO 27001, SOC 2, ISAE 3402 of CYRA: wat bewijst het bij een leverancier?.

Klantbewijs: deel niet meer dan nodig

Sterker bewijs betekent niet automatisch meer gevoelige informatie delen.

Vermijd waar mogelijk:

• wachtwoorden;
• herstelcodes;
• volledige gebruikerslijsten;
• tenant-ID's zonder noodzaak;
• kwetsbaarheidsdetails die misbruik faciliteren;
• volledige pentestbevindingen als een managementsamenvatting volstaat;
• klantdata;
• interne escalatiegegevens die niet relevant zijn.

Maak liever een geredigeerde klantversie met:

• scope;
• datum;
• methode;
• resultaat;
• uitzonderingen op hoofdlijnen;
• opvolging.

Checklist: is dit bewijs sterk genoeg?

• Is het doel van de maatregel duidelijk?
• Is de scope expliciet?
• Is zichtbaar hoe de maatregel is ingericht?
• Is bewijs beschikbaar dat uitvoering plaatsvindt?
• Is de werking getest of beoordeeld waar dat relevant is?
• Zijn uitzonderingen vastgelegd?
• Zijn bevindingen gekoppeld aan eigenaar en actie?
• Is het bewijs actueel?
• Is een volgende reviewdatum vastgelegd?
• Is duidelijk wat veilig met klanten kan worden gedeeld?
• Wordt geen onafhankelijke assurance gesuggereerd als die niet bestaat?

Bronnen en actuele informatie

• NCSC — Zorgplicht Cyberbeveiligingswet, maatregel 10 effectiviteit: https://www.ncsc.nl/cyberbeveiligingswet-nis2/zorgplicht
• NCSC — Infosheet zorgplicht: https://www.ncsc.nl/cyberbeveiligingswet-nis2/infosheet-zorgplicht
• RDI — Toeleveringsketen en cyberbeveiliging: https://www.rdi.nl/onderwerpen/digitale-weerbaarheid/cyberbeveiligingswet/toeleveringsketen
• ISO — ISO/IEC 27001:2022: https://www.iso.org/standard/27001
• AICPA & CIMA — SOC Type 1/Type 2 en operating effectiveness: https://www.aicpa-cima.com/professional-insights/video/maintaining-high-standards-for-soc-engagements

Wil je bewijs niet alleen verzamelen, maar onderhouden?

Begin met de maatregelen die klanten het vaakst uitvragen en leg per maatregel scope, evidence, datum, werking, uitzonderingen en review vast. Als je dat structureel wilt opzetten, past de Cybersecurity Bewijsmap. Als je eerst wilt weten wat aantoonbaar en nog open is, bekijk de Cybersecurity Bewijs- en Weerbaarheidscheck.