Auditbewijs bij een IT-audit: wat de auditor accepteert en hoe je het organiseert

Elke auditverklaring rust op bewijs. De auditor stelt niet vast dat een maatregel werkt omdat iemand dat zegt, maar omdat hij iets heeft gezien dat het aantoont: een ticket, een log, een export, een vastgelegd besluit. Een IT-audit loopt in de praktijk vooral vast op bewijs: bewijs dat er niet is, dat te laat komt of dat iets anders laat zien dan de organisatie dacht.

Wat een auditor onder bewijs verstaat

De assurancestandaarden ISAE 3000 en ISAE 3402 vragen om bewijs dat voldoende en geschikt is, en de werkwijze van een certificerende instelling bij ISO 27001 wijkt daar in de kern niet van af. Voldoende gaat over de hoeveelheid: genoeg waarnemingen om een conclusie over de hele periode te dragen. Geschikt gaat over de kwaliteit, en die valt uiteen in relevantie en betrouwbaarheid. Relevant betekent dat het bewijs gaat over precies de maatregel die wordt getoetst. Een screenshot van een firewallregel zegt iets over netwerksegmentatie en niets over de toegangsreview.

Bij betrouwbaarheid hanteert de auditor een rangorde. Wat hij zelf in het systeem ziet, weegt zwaarder dan wat hem wordt toegestuurd. Een export rechtstreeks uit het systeem weegt zwaarder dan een spreadsheet die iemand heeft bijgehouden. Bewijs van een onafhankelijke partij weegt zwaarder dan bewijs van de persoon die de maatregel zelf uitvoert. Een origineel weegt zwaarder dan een kopie of een bewerkt document. Daaruit volgt de regel die het meest wordt onderschat: een gesprek is geen bewijs. Navraag is een geldige auditprocedure, maar voor het oordeel over de werking van een maatregel is navraag alleen nooit genoeg. Er moet altijd iets tastbaars naast liggen.

Vier manieren waarop de auditor toetst

Een auditor gebruikt vier procedures, en welke hij kiest bepaalt wat jij moet aanleveren. Navraag: hij vraagt de eigenaar hoe de maatregel werkt. Observatie: hij kijkt mee terwijl iemand de maatregel uitvoert, bijvoorbeeld een uitrol naar productie of het intrekken van een account. Inspectie: hij bekijkt documenten, records en configuraties. Herhaling: hij voert de maatregel zelf opnieuw uit, bijvoorbeeld door een toegangsreview na te rekenen tegen de actuele accountlijst.

Inspectie en herhaling leveren het sterkste bewijs en vormen daarom het grootste deel van de verzoeklijst. Observatie is beperkt bruikbaar, omdat de auditor alleen ziet wat er gebeurt op het moment dat hij kijkt. Voor een periode van twaalf maanden zegt dat weinig. Wie dat begrijpt, snapt ook waarom een auditor tijdens een walkthrough tevreden knikt bij de uitleg en daarna toch om de tickets vraagt.

Opzet, bestaan en werking vragen ander bewijs

De vraag welk bewijs nodig is heeft drie antwoorden, afhankelijk van wat er wordt getoetst. Voor de opzet wil de auditor zien dat de maatregel goed is ontworpen: het beleid, de procedure, de configuratie of de workflow. Voor het bestaan wil hij zien dat de maatregel op een moment daadwerkelijk aanwezig is: een instantie, op een datum. Dat is wat een Type I-rapport toetst. Voor de werking wil hij zien dat de maatregel gedurende de hele periode consequent is uitgevoerd, en daarvoor heeft hij een populatie en een steekproef nodig. Dat is het verschil tussen Type I en Type II, en het is de reden dat de observatieperiode zoveel bepaalt; zie de observatieperiode bij een ISAE 3402 Type 2.

Bij geautomatiseerde maatregelen werkt het anders. Een systeem dat elke wijziging zonder goedkeuring blokkeert, doet dat elke keer op dezelfde manier. De auditor toetst dan een instantie en leunt verder op de general IT controls rondom het systeem: wie de configuratie kan aanpassen en of wijzigingen daaraan beheerst verlopen. Dat is de reden dat toegangsbeheer en wijzigingsbeheer in elke IT-audit zwaar wegen, welke norm er ook wordt getoetst.

De populatie is belangrijker dan de steekproef

Hier gaat het in de praktijk het vaakst mis. Een organisatie levert twintig goedgekeurde wijzigingstickets aan als bewijs voor wijzigingsbeheer. De auditor kan daar niets mee, want hij weet niet uit hoeveel tickets die twintig zijn gekozen en wie ze heeft gekozen. Hij wil eerst de volledige lijst van alle wijzigingen in de periode, en trekt daar zelf een steekproef uit.

De volledigheid van die lijst is het eigenlijke onderwerp. Een lijst uit het ticketsysteem is alleen volledig als elke wijziging via dat systeem loopt. Handmatige wijzigingen, noodwijzigingen en wijzigingen door een leverancier moeten erin staan. De auditor vergelijkt daarom de deploymentlijst uit de pijplijn met de tickets, en de HR-lijst van uitdiensttredingen met de accounts die zijn ingetrokken. Klopt dat niet, dan is de maatregel niet aantoonbaar, hoe netjes de aangeleverde tickets ook zijn. Hoe die reconciliatie bij wijzigingen verloopt staat in wijzigingsbeheer in de IT-audit, en het toegangsdeel in toegangsbeheer en IAM in de audit.

De omvang van de steekproef hangt af van de frequentie van de maatregel en van het risico. Een jaarlijkse maatregel wordt in elke instantie getoetst; bij een dagelijkse maatregel trekt de auditor een steekproef die over de hele periode is gespreid. Vraag de auditor vooraf welke steekproefomvang hij hanteert, dan weet je hoeveel je moet klaarleggen.

Wat een bruikbaar bewijsstuk bevat

Een bewijsstuk moet vijf vragen beantwoorden zonder toelichting van de organisatie: uit welk systeem komt het, wanneer is het vastgelegd, wie heeft de handeling uitgevoerd of goedgekeurd, op welke scope of filter is het gebaseerd, en is het onbewerkt.

Voor een screenshot betekent dat: de systeemnaam of URL in beeld, de datum en tijd, de ingelogde gebruiker, en het volledige scherm in plaats van een bijgesneden fragment. Voor een export: de query of het filter waarmee hij is gemaakt en het aantal regels, zodat de auditor kan vaststellen dat de hele populatie erin zit. Voor een goedkeuring: de naam van de goedkeurder, het tijdstip en het object waarop de goedkeuring slaat, uit het systeem zelf en niet als los mailtje. Voor notulen: datum, aanwezigen, besluiten en acties. Een directiebeoordeling zonder vastgelegde besluiten kan de auditor niet als beoordeling meetellen.

Een screenshot is niet verboden, maar het is het zwakste bewijs op de lijst. Als het systeem een export, een auditlog of een rapport kan leveren, geef dan dat. Een auditor die iets belangrijks toetst, vraagt bovendien vaak of hij het zelf in het systeem mag zien. Reken daarop en leg een leesaccount klaar.

Bewijs per soort maatregel

Governancemaatregelen (beleid, risicobeoordeling, directiebeoordeling, interne audit) leveren documentair bewijs: het goedgekeurde document met versiegeschiedenis, de risicobeoordeling met datum en eigenaar, de notulen met besluiten. Bij ISO 27001 zijn dit de registraties uit clausule 7.5, en de auditor loopt ze langs bij clausule 9.1 tot en met 10.2.

Operationele maatregelen (wijzigingsbeheer, incidentbeheer, toegangsbeheer, leveranciersbeoordeling) leveren transactioneel bewijs: tickets met goedkeuring, incidentrecords met tijdlijn en afsluiting, in- en uitdiensttredingen met de bijbehorende accountacties, periodieke toegangsreviews met de genomen besluiten. Hier zit het populatiewerk.

Technische maatregelen (versleuteling, netwerksegmentatie, kwetsbaarhedenscans, back-up, monitoring) leveren systeembewijs: configuratie-exports, scanrapporten met opvolging, back-uplogs met een geslaagde hersteltest, alertregels en de alerts die daadwerkelijk zijn afgegaan met wat ermee is gedaan. Voor monitoring wil de auditor niet alleen zien dat het is ingericht, maar ook een alert die is opgevolgd; zie logging en monitoring in de audit.

Bewijs dat achteraf niet meer te maken is

Bewijs voor werking moet ontstaan op het moment dat de maatregel wordt uitgevoerd. Een toegangsreview die in april had moeten plaatsvinden en in augustus alsnog wordt gedaan omdat de auditor erom vraagt, is bewijs van een review in augustus. Voor april blijft de maatregel niet uitgevoerd, en dat wordt een afwijking in het rapport. Reconstructie valt bovendien op: tijdstempels in systemen, metadata van documenten en de volgorde van gebeurtenissen in een ticket laten zien wanneer iets echt is aangemaakt. Een auditor die dat ontdekt, bekijkt de rest van het dossier met andere ogen.

Het tweede gat dat niet te dichten is: bewaartermijnen die korter zijn dan de periode. Als de logs van je monitoring na negentig dagen worden opgeruimd en de observatieperiode twaalf maanden beslaat, bestaat voor negen maanden geen bewijs meer. De auditor rapporteert dat niet als afwijking van de maatregel; hij rapporteert dat hij de werking over die maanden niet heeft kunnen toetsen, en een lezer van het rapport weegt dat even zwaar. Controleer daarom voordat de periode begint of elke bron van bewijs minstens de periode plus de doorlooptijd van de audit bewaart.

Bewijs organiseren zonder dat het een project wordt

De aanpak die werkt, hangt het bewijs aan de maatregel in plaats van aan de audit. Per maatregel leg je vooraf vast welk bewijs de werking aantoont, uit welk systeem het komt, hoe vaak het ontstaat, wie de eigenaar is en waar het wordt bewaard. Wie dat heeft, verzamelt niet meer in de weken voor de audit maar op het moment dat de maatregel draait. Een kwartaalreview levert dan zijn eigen bewijs op de dag dat hij wordt gedaan.

Bewaar het op een plek, onder het nummer van de maatregel, met een bestandsnaam die de periode en de bron bevat. Versnipperd bewijs in mailboxen, gedeelde mappen en lokale schijven kost bij elke audit opnieuw zoekwerk, en het is de reden dat een verzoeklijst van dertig regels soms weken duurt. Meet hoe lang het duurt om een verzoek te beantwoorden. Als het bewijs voor een routinemaatregel dagen zoekwerk kost, zegt dat iets over de maatregel zelf, en het is een goede reden om het audit readiness assessment niet over te slaan.

Werk met de verzoeklijst van de auditor als leidend document. Die lijst noemt per maatregel wat hij verwacht, met een termijn. Lever per regel aan, meld het als iets niet bestaat in plaats van iets vergelijkbaars te sturen, en houd bij wat openstaat. Een auditplatform dat verzoeken, bewijs en beoordeling per maatregel bij elkaar houdt, vervangt de mailwisseling en de Excel-tracker; wat het Secure Audit-platform daarin doet, staat op de dienstenpagina. Wie het bewijs doorlopend uit de systemen laat komen, is nog een stap verder; zie continuous auditing.

Waar het in de praktijk misgaat

Vier patronen komen steeds terug. De organisatie levert een eigen selectie in plaats van de populatie, en moet daarna alsnog de volledige lijst produceren. Screenshots zonder datum, systeem of gebruiker komen terug met de vraag om een export. Periodieke maatregelen waarvan de eerste kwartalen ongedocumenteerd zijn, omdat het verzamelen pas begon toen de audit werd ingepland. En bewijs dat bij de eigenaar in een mailbox staat, waardoor het bij vertrek van die persoon of bij de volgende audit opnieuw bij nul begint.

Alle vier zijn te voorkomen door voordat de periode begint per maatregel te bepalen wat het bewijs is en waar het ontstaat. Dat hoeft maar een keer goed te gebeuren en het betaalt zich bij elke volgende audit terug in de tijd die de verzoeklijst kost. Hoe dat past in de bredere voorbereiding staat in een SOC 2-audit voorbereiden.