Toegangsbeoordelingen die auditors accepteren (met sjabloon)
Een gebruikerstoegangsbeoordeling is een periodieke controle of elk account in een systeem nog toebehoort aan iemand die het nodig heeft, op het rechtenniveau dat diegene nodig heeft. Auditors die SOC 2 CC6 of ISO 27001 A.5.18 en A.8.2 testen, wijzen dit bewijs om voorspelbare redenen af: de volledigheid van de accountpopulatie is niet aan te tonen, de beoordelaar was dezelfde persoon die de toegang heeft, de export laat zien wie toegang heeft maar niet wat er is besloten, of intrekkingen zijn goedgekeurd en nooit uitgevoerd. Bruikbaar bewijs benoemt de populatie en waar die vandaan komt, legt per account een besluit vast met beoordelaar en datum, en maakt de cirkel rond met bewijs dat de verwijderingen echt hebben plaatsgevonden.
Een gebruikerstoegangsbeoordeling is een periodieke controle of elk account in een systeem nog toebehoort aan iemand die het nodig heeft, op het rechtenniveau dat diegene nodig heeft. Het is een van de meest gevraagde stukken auditbewijs — en een van de meest afgewezen, omdat teams een export van de gebruikerslijst inleveren terwijl de auditor om een besluitregistratie vroeg.
Dat onderscheid is belangrijker dan welk ander detail in dit artikel ook: een export toont een toestand; een beoordeling toont oordeelsvorming. Een spreadsheet met iedereen die in maart toegang had, bewijst alleen dat je je eigen systemen kunt bevragen. Wat de auditor test, is of een met naam genoemde mens naar elk van die accounts heeft gekeken en er iets over heeft besloten.
Wat de frameworks werkelijk vragen
Toegangsbeoordelingen liggen op het snijvlak van twee frameworkeisen, en daarom komen ze in vrijwel elke audit terug:
- SOC 2 Common Criteria CC6 gaat over logische toegang: hoe toegang wordt geregistreerd, geautoriseerd, gewijzigd en ingetrokken. Beoordelingen zijn de manier waarop je aantoont dat de autorisatie door de tijd heen juist blijft, en niet alleen klopte op het moment van uitgifte. Zie de Common Criteria uitgelegd.
- ISO 27001 Bijlage A.5.18 (toegangsrechten) gaat over het verstrekken, beoordelen en intrekken van toegangsrechten. A.8.2 (geprivilegieerde toegangsrechten) legt de lat specifiek voor beheeraccounts hoger, en A.5.15–A.5.17 dekken de omliggende praktijken rond toegangsbeheer, identiteit en authenticatie. De complete gids voor Bijlage A laat zien hoe dit in elkaar grijpt.
Geen van beide frameworks schrijft een frequentie voor. Wat ze allebei verwachten, is dat je er een vastlegt, die onderbouwt tegen het risico, en je er vervolgens ook echt aan houdt.
Stap 1: Bepaal de populatie — dit wordt als eerste getest
Voordat een auditor naar één besluit kijkt, test hij of jouw lijst volledig was. Dit is de stap die teams overslaan, en het is de stap die alles daarna ongeldig maakt: als de populatie niet klopt, is geen enkel besluit dat erop is genomen te verifiëren.
Volledigheid betekent twee dingen. Ten eerste: je hebt elk account in het systeem beoordeeld, niet alleen de accounts die je je herinnerde — inclusief serviceaccounts, accounts van externe krachten, gedeelde accounts en accounts van mensen die al weg zijn. Ten tweede: je kunt laten zien waar de lijst vandaan komt — een door het systeem gegenereerde export met zichtbare bron en tijdstempel, geen handmatig bijgehouden spreadsheet.
Praktische manier om dat voor elkaar te krijgen: exporteer de gebruikerslijst rechtstreeks uit elk systeem binnen scope, leg de exportdatum vast en wie de export heeft gedraaid, en stem het totaal af met je HR-overzicht en je activa- en systeeminventaris. Elk account dat wel in het systeem staat maar niet bij HR, is ofwel een serviceaccount dat je moet documenteren, ofwel een bevinding die je moet oplossen.
Stap 2: Kies de frequentie op risico, niet op gewoonte
De frequentie hoort de impactradius van de toegang te volgen. Een verdedigbaar patroon voor een klein team:
- Geprivilegieerde en beheertoegang — per kwartaal. Productie-infrastructuur, cloud-root- en adminrollen, databasebeheer, alles wat verdere toegang kan uitdelen.
- Standaardtoegang tot systemen met klantgegevens — halfjaarlijks of jaarlijks, afhankelijk van hoe gevoelig de data is en hoeveel beweging er in je personeelsbestand zit.
- Gebeurtenisgedreven, naast de kalender — een beoordeling die wordt getriggerd door een rolwijziging, een teamreorganisatie of een vertrek, in plaats van wachten op de volgende geplande cyclus.
Schrijf de frequentie in je toegangsbeleid en haal hem vervolgens ook. Een auditor die een beleid dat kwartaalbeoordelingen belooft naast bewijs van twee beoordelingen in een jaar legt, noteert een bevinding — en die bevinding gaat over de gemiste toezegging, niet over de frequentie zelf. Beleid waar je je echt aan houdt, verslaat ambitieus beleid waar je je niet aan houdt.
Stap 3: Zorg dat de beoordelaar niet zichzelf beoordeelt
Onafhankelijkheid is de op één na meest voorkomende reden voor afwijzing. Wie een account beoordeelt, hoort niet degene te zijn die het account heeft — en bij voorkeur ook niet degene die toegang uitdeelt.
Voor de meeste kleine bedrijven is het werkbare model dat de systeemeigenaar of de leidinggevende van de accounthouder de beoordeling uitvoert, en dat iemand anders — een oprichter, de securityverantwoordelijke, wie het ISMS ook beheert — de beoordeling als geheel aftekent. Dan staan er twee namen op de registratie, en dat is precies waar de auditor naar zoekt.
Het ongemakkelijke geval is de startup van twee mensen waar de CTO elk systeem beheert en alle admin-credentials in handen heeft. Het eerlijke antwoord is niet doen alsof dat anders is: laat de andere oprichter de toegang van de CTO beoordelen, documenteer dat de functiescheiding wordt begrensd door de teamgrootte, en noteer de compenserende maatregelen (logging, alerting op rechtenwijzigingen). Auditors accepteren gedocumenteerde, beredeneerde beperkingen veel makkelijker dan een gefingeerde scheiding.
Ready to Streamline Your Compliance?
Discover how AuditBadger can simplify your compliance management process.
Stap 4: Leg per account een besluit vast
Dit is het deel dat een export in een beoordeling verandert. Elke regel in de populatie heeft een expliciete uitkomst nodig — en “geen actie” is ook een uitkomst, zolang een mens die heeft gekozen.
| Kolom | Wat erin komt |
|---|---|
| Systeem | Het systeem binnen scope dat wordt beoordeeld |
| Account / gebruikersnaam | De identificatie zoals die in het systeem staat |
| Accounttype | Persoon, service, gedeeld, externe kracht |
| Eigenaar | De met naam genoemde persoon die verantwoordelijk is voor het account |
| Toegangsniveau | De rol of rechten die iemand heeft, niet alleen “heeft toegang” |
| Zakelijke onderbouwing | Waarom deze persoon dit niveau nodig heeft |
| Besluit | Behouden / Beperken / Intrekken |
| Beoordelaar | De met naam genoemde persoon die het besluit nam |
| Datum beoordeling | Wanneer het besluit is genomen |
| Uitgevoerde actie | Ticketreferentie of wijzigingsregistratie voor Beperken/Intrekken |
| Actie afgerond | Datum waarop de wijziging echt is doorgevoerd, en door wie |
De laatste twee kolommen zijn de kolommen die teams leeg laten, en het zijn precies de kolommen die auditors het hardst controleren.
Stap 5: Maak de cirkel rond — goedgekeurd is niet verwijderd
Een beoordeling die twaalf accounts aanwijst om in te trekken en er vervolgens geen enkele intrekt, is erger dan helemaal geen beoordeling: hij documenteert dat je van een probleem wist en het niet hebt opgelost. Auditors nemen routinematig een steekproef uit de intrekkingen in je beoordeling en gaan in het live systeem kijken of het account echt weg is.
Het bewijspakket voor elke cyclus heeft daarom drie artefacten nodig, niet één:
- De export van de populatie, met bron en datum.
- De ingevulde beoordelingsregistratie, met besluiten per account, namen van beoordelaars en datums.
- Bewijs van de opvolging — tickets, wijzigingsregistraties of een vervolgexport waaruit blijkt dat de ingetrokken accounts echt weg zijn.
Dat derde artefact maakt van een bewering bewijs. Voor hoe dit in het bredere bewijsplaatje past, zie wat auditors echt als bewijs willen.
Beoordelingen vangen op wat offboarding heeft gemist
Het helpt om helder te hebben welk werk de beoordeling doet. Offboarding is je preventieve maatregel: als iemand vertrekt, gaat de toegang dezelfde dag mee. De toegangsbeoordeling is de detectieve maatregel die de gevallen opvangt waarin offboarding niet is afgegaan — de externe kracht wiens opdracht stilletjes afliep, de SaaS-tool die niet op de offboardingchecklist stond, het serviceaccount dat is aangemaakt voor een migratie die een jaar geleden klaar was.
Als je toegangsbeoordelingen structureel vertrokken medewerkers naar boven halen, gaat de bevinding eigenlijk niet over de beoordeling. Hij gaat over het offboardingproces, en daar hoort de oplossing thuis.
De antipatronen
- De export inleveren als de beoordeling. Toestand, geen oordeel. De meest voorkomende afwijzing die er is.
- Alleen de systemen beoordelen die makkelijk te exporteren zijn. Auditors vragen naar de systemen binnen scope, inclusief de lastige.
- Alle regels in één klik massaal goedkeuren. Een beoordeling waarin in een groeiend bedrijf 100% van de accounts is behouden, nodigt uit tot extra kritische blikken — en als er nooit iets verandert, beoordeelt de beoordelaar niet.
- Service- en gedeelde accounts vergeten. Die dragen de meeste rechten en het minste eigenaarschap.
- Geen spoor van de opvolging achterlaten. Het besluit zonder de uitvoering is een openstaande bevinding.
De kern
Toegangsbeoordelingen zijn niet moeilijk, maar wel nauwgezet: een volledige populatie uit een systeemexport, een beoordelaar die de toegang zelf niet heeft, een expliciet besluit op elk account, en bewijs dat de intrekkingen ook echt zijn uitgevoerd. Doe dat vier keer per jaar op je geprivilegieerde accounts en het bewijsverzoek is geen paniekklus meer.
Volgende: de checklist voor jaarrond monitoren voor waar beoordelingen in de bredere kalender zitten, SOC 2-bewijsverzameling voor de rest van de aanvraaglijst, of bekijk hoe geautomatiseerde bewijsverzameling de populatie en het bewijs bij elkaar houdt.
