Welke documenten vraagt een IT-auditor doorgaans op?

Voor wie voor het eerst een IT-audit of interne audit doorloopt, is een van de meest praktische vragen niet wát er getoetst wordt, maar wélke documenten en welk bewijs de auditor concreet wil zien. Zonder dat overzicht ontstaat er vaak onnodige stress vlak vóór de audit: een haastige zoektocht naar toegangsoverzichten, wijzigingslogs of trainingsregistraties die verspreid staan over meerdere systemen en mensen.

Dit artikel geeft een praktisch overzicht van de documenten en het bewijs die een IT-auditor doorgaans opvraagt, hoe zo'n verzoek meestal wordt aangeleverd, en welke fout organisaties het vaakst maken bij de voorbereiding. Voor de bredere context rond IT-audit en assurance, zie de hub-pagina IT-audit & assurance-readiness.

Wat een auditor bedoelt met "aantoonbaar"

Een auditor vraagt zelden alleen om te weten óf een beleid bestaat. De centrale vraag is steeds of iets aantoonbaar is: kunt u met concreet bewijs laten zien dat een maatregel niet alleen is beschreven, maar ook daadwerkelijk wordt toegepast? Een toegangsbeleid dat op papier zegt dat rechten worden ingetrokken bij uitdiensttreding, is voor een auditor pas overtuigend als er ook een overzicht, ticket of logregel bestaat die laat zien dat dit in de praktijk daadwerkelijk gebeurt.

Dat onderscheid tussen "bestaat op papier" en "werkt aantoonbaar in de praktijk" verklaart waarom de documentenvraag van een auditor breder is dan alleen het beleidsdocument zelf. De indeling hieronder — een vaste basis aan beleidsdocumentatie, plus bewijs van werking — komt in vrijwel elke IT-audit terug, ongeacht of het gaat om een interne audit, een voorbereiding op ISO 27001, of een readiness-traject richting een assurance-onderzoek.

De vaste basis: beleid, procesbeschrijvingen, toegangsoverzichten

De eerste laag van een documentenverzoek bestaat doorgaans uit de vastgelegde kaders: wat heeft de organisatie afgesproken, en bij wie ligt de verantwoordelijkheid? Denk aan:

• Informatiebeveiligingsbeleid en onderliggende deelbeleid, bijvoorbeeld toegangsbeleid, wachtwoordbeleid en wijzigingsbeleid
• Procesbeschrijvingen voor terugkerende activiteiten: onboarding en offboarding van medewerkers, wijzigingsbeheer, incidentafhandeling, back-upbeheer
• Een actueel organogram of RACI-overzicht waaruit blijkt wie waarvoor verantwoordelijk is
• Overzichten van gebruikersaccounts en toegangsrechten per systeem, inclusief welke accounts verhoogde ("bevoorrechte") rechten hebben
• Een actuele lijst van in gebruik zijnde applicaties, systemen en, waar relevant, IT-leveranciers

Deze documenten laten zien hóe de organisatie het bedoeld heeft. Ze vormen de basis, maar zijn op zichzelf onvoldoende: een auditor wil ook weten of dat wat hier staat beschreven, ook echt gebeurt.

Bewijs van werking: logs, tickets, wijzigingsregistraties

De tweede, vaak onderschatte laag is bewijs dat een maatregel gedurende een periode daadwerkelijk heeft gewerkt. Dit is het soort bewijs waarop organisaties het vaakst worden verrast, omdat het zelden op één centrale plek staat:

• Toegangslogs en periodieke reviews van gebruikersrechten, inclusief bewijs dát die review daadwerkelijk heeft plaatsgevonden
• Ticketoverzichten uit het servicedesk- of ITSM-systeem, bijvoorbeeld voor onboarding, offboarding of incidentafhandeling
• Wijzigingsregistraties (change records) met bewijs van test, goedkeuring en implementatie
• Rapportages van back-uptests: niet alleen dat een back-up is gemaakt, maar dat een herstel ook daadwerkelijk is beproefd
• Trainings- of bewustwordingsregistraties waaruit blijkt dat medewerkers zijn meegenomen in het beleid
• Een incidentenregister met afhandeling en opvolging

Dit is precies het bewijs dat de meeste tijd kost om te verzamelen, omdat het vaak verspreid staat over meerdere tools, teams en mensen. Wie hiermee wacht tot de week van de audit, loopt vrijwel altijd achter de feiten aan.

De evidence request list (PBC-lijst) — wat het is en hoe u er tijd op bespaart

Om die achterstand te voorkomen, werkt een auditor doorgaans met een evidence request list — ook wel een PBC-lijst genoemd, van het Engelse "Provided By Client". Dit is een vooraf gedeelde lijst met alle documenten en bewijsstukken die de auditor nodig verwacht te hebben, met per item een korte omschrijving van wat wordt gevraagd.

Het grootste tijdvoordeel zit niet in de lijst zelf, maar in hoe u ermee omgaat vóórdat de audit begint:

• Wijs per item een eigenaar aan die verantwoordelijk is voor het aanleveren, in plaats van de hele lijst bij één persoon neer te leggen
• Verzamel bewijs in een gedeelde, overzichtelijke structuur — bijvoorbeeld één map per controlegebied — in plaats van losse e-mailbijlagen
• Begin zodra de PBC-lijst binnen is, niet pas in de week vóór het auditgesprek
• Signaleer ontbrekend of verouderd bewijs zelf al vóór de audit, zodat u niet tijdens het gesprek wordt overvallen

Deze aanpak sluit direct aan op de manier waarop wij zelf werken bij een interne audit en bij de voorbereiding op een ISO 27001-audit: zie ook onze ISO 27001 audit checklist voor een vergelijkbaar overzicht, specifiek gericht op certificeringstrajecten.

Veelgemaakte fout: documentatie die klopt op papier maar niet met de praktijk

De meest voorkomende bevinding bij IT-audits is niet dat documentatie ontbreekt, maar dat documentatie en praktijk uit elkaar zijn gegroeid. Een offboardingproces dat op papier zegt dat toegang binnen 24 uur wordt ingetrokken, maar waarvan een steekproef uit het ticketsysteem laat zien dat dit in de praktijk regelmatig langer duurt, is een klassiek voorbeeld. Hetzelfde geldt voor een wijzigingsbeleid dat goedkeuring vooraf eist, terwijl wijzigingslogs laten zien dat een deel van de wijzigingen pas achteraf is vastgelegd.

Dit soort verschillen ontstaat zelden uit onwil. Beleid wordt op een moment geschreven, en de praktijk verandert daarna geleidelijk mee met nieuwe tools, mensen of prioriteiten — zonder dat het document wordt bijgewerkt. Voor een auditor is dat verschil wél relevant, omdat het precies laat zien of een organisatie haar eigen maatregelen daadwerkelijk beheerst, of alleen documenteert.

De meest effectieve voorbereiding is daarom niet het bijschaven van beleidsdocumenten vlak vóór de audit, maar het vooraf steekproefsgewijs vergelijken van wat het beleid zegt met wat een aantal recente tickets, logs of wijzigingen daadwerkelijk laten zien. Wie die kloof zelf al vindt en oplost vóór de auditor dat doet, voorkomt de meeste bevindingen.