Audit readiness assessment: de generale repetitie voor je IT-audit

Een audit readiness assessment is de laatste controle voordat de auditor komt. De vraag is niet meer wat er ontbreekt, want die heeft de gap-analyse aan het begin van het traject al beantwoord. De vraag is of wat er sindsdien is ingericht ook werkt, of dat te bewijzen is, en of de auditdatum dus kan blijven staan. Het assessment levert geen certificaat en geen assurancerapport op. Het levert een antwoord op die ene vraag, met per maatregel de onderbouwing.

Het verschil met een gap-analyse zit in het moment en in de methode. Een gap-analyse vergelijkt de opzet met de norm: is er beleid, is er een proces, is er een eigenaar. Een readiness assessment toetst de werking: is het proces de afgelopen maanden gevolgd, door wie, en waar staat dat vastgelegd. Een organisatie kan de verbeterlijst uit de gap-analyse keurig hebben afgewerkt en toch niet klaar zijn, omdat de maatregelen pas twee maanden draaien of omdat niemand het bewijs bij elkaar krijgt.

Toets zoals de auditor toetst

Het assessment heeft alleen waarde als het dezelfde methode gebruikt als de audit die volgt. Dat betekent per maatregel drie stappen. Eerst een walkthrough met de eigenaar van de maatregel: laat zien hoe het werkt, van de aanleiding tot de vastlegging. Dan een populatie: alle wijzigingen in de periode, alle nieuwe medewerkers, alle vertrokken medewerkers, alle uitgevoerde toegangsreviews. En dan een steekproef uit die populatie, met het verzoek om voor elk geselecteerd geval het bewijs te leveren.

Die laatste stap is het verschil met een gesprek. In een interview zegt de eigenaar dat elke wijziging wordt goedgekeurd. In een steekproef blijkt of dat voor de vijf geselecteerde wijzigingen ook is vastgelegd, door iemand anders dan de indiener, en voordat de wijziging naar productie ging. Bij een certificeringsaudit voor ISO 27001 werkt de auditor met steekproeven; bij een SOC 2 Type II of een ISAE 3402 Type II is het de kern van het onderzoek. Wie het readiness assessment beperkt tot interviews, oefent iets anders dan wat er straks gebeurt.

Hanteer ook dezelfde spelregels voor het bewijs. Een auditor stuurt een verzoeklijst met een termijn en verwacht bewijs uit de bron: het ticket, de log, de export uit het systeem, en geen screenshot dat voor de gelegenheid is gemaakt. Meet tijdens het assessment hoe lang het duurt voordat een verzoek is beantwoord. Als het bewijs voor een routinematige maatregel dagen zoekwerk kost, is dat op zichzelf een bevinding, ook als het er uiteindelijk wel is. Wat een bruikbaar bewijsdossier is, staat in bewijslast bij een IT-audit.

Volledigheid van de populatie

De lijst waaruit de auditor kiest is voor de meeste organisaties een groter probleem dan het bewijs per geval. Een steekproef zegt alleen iets als de populatie compleet is. Kun je een lijst overleggen van alle wijzigingen in de periode, inclusief handmatige aanpassingen en noodwijzigingen buiten het reguliere proces om? Van alle accounts die zijn aangemaakt, ook de serviceaccounts en de accounts van externen? Van alle incidenten, ook de incidenten die alleen in een chatkanaal zijn afgehandeld?

Als de populatie uit meerdere systemen moet komen, is de reconciliatie het werk: de deploymentlijst uit de pijplijn naast de wijzigingstickets, de HR-lijst naast de accountlijst. Wat in de ene lijst staat en in de andere niet, is precies wat de auditor gaat vragen. Doe die reconciliatie tijdens het assessment en niet tijdens de audit.

Twee soorten gaten, waarvan er maar een te dichten is

Het rapport moet per bevinding zeggen wat voor soort gat het is. Een documentair gat is voor de audit te dichten: een procedure die wel wordt gevolgd maar niet is beschreven, een goedkeuring die vanaf nu wordt vastgelegd, een beleidsdocument zonder eigenaar of versiedatum. Een werkingsgat is dat niet. Een kwartaalreview van toegangsrechten die in het tweede kwartaal is overgeslagen, blijft overgeslagen. Logs die na dertig dagen zijn opgeruimd terwijl de observatieperiode zes maanden beslaat, komen niet terug. Een maatregel die halverwege de periode is ingevoerd, heeft over de eerste helft geen werking.

Bij een Type II-rapport verschijnen werkingsgaten als afwijking in het rapport. Bij een certificeringsaudit leiden ze tot een afwijking, en bij een major moet de correctie zijn geverifieerd voordat het certificaat wordt afgegeven; bij een maatregel die een periode nodig heeft, kan dat betekenen dat de auditor terug moet komen. De uitkomst van het assessment is daarom een besluit, met de actielijst als bijlage: de datum blijft staan, de periode schuift op, of de organisatie accepteert dat een specifieke afwijking in het rapport komt en bereidt de toelichting daarop voor. Alle drie zijn verdedigbare keuzes, zolang de organisatie ze zelf maakt en ze niet door de auditor worden afgedwongen.

Wat vlak voor de audit vaak nog ontbreekt

Een paar onderwerpen keren in bijna elk assessment terug. Bij ISO 27001 zijn dat de interne audit en de directiebeoordeling. De norm vraagt in clausule 9.2 en 9.3 dat beide zijn uitgevoerd, en een certificerende auditor geeft geen certificaat af zolang ze nog moeten plaatsvinden. Een interne audit die een week voor stage 2 in elkaar wordt gezet, herkent een auditor aan het ontbreken van opvolging. Plan die dus niet als sluitstuk van het readiness assessment, maar ruim daarvoor, zodat de bevindingen nog een corrigerende maatregel kunnen krijgen.

Bij SOC 2 en ISAE 3402 is het de systeembeschrijving. Die is van de organisatie en niet van de auditor, en beschrijft de dienst, de grenzen van het systeem, de maatregelen en de rol van subserviceorganisaties. In de praktijk wordt hij vaak pas geschreven als de auditor erom vraagt, en dan blijkt dat de beschrijving en de maatregelenlijst niet op elkaar aansluiten. De volgorde waarin je dat aanpakt staat in een SOC 2-audit voorbereiden.

En bij elke norm: de eigenaar die de maatregel niet kan uitleggen. Een control die op papier bij het hoofd IT ligt maar in werkelijkheid door een beheerder wordt uitgevoerd die niet bij de walkthrough zit, levert in de audit een stroef gesprek op. Zet tijdens het assessment de mensen aan tafel die het werk doen en laat hen het bewijs aanwijzen.

Wie het assessment doet

Een readiness assessment kan door de eigen interne auditfunctie worden gedaan, mits die onafhankelijk genoeg staat van de afdeling die de maatregelen uitvoert en de auditmethode kent. Voor een organisatie in de eerste cyclus is dat vaak te veel gevraagd en wordt een externe partij ingeschakeld.

Let daarbij op de rolverdeling. Voor ISO 27001 mag de certificerende instelling niet adviseren over het managementsysteem dat ze daarna certificeert, dus het assessment komt van een andere partij. Bij SOC 2 en ISAE 3402 mag de rapporterende accountant in beginsel wel vooraf beoordelen of de organisatie klaar is, zolang de organisatie zelf de maatregelen ontwerpt en de beslissingen neemt. De grens ligt bij het ontwerpen en inrichten van maatregelen: wie dat doet, kan er niet meer onafhankelijk over rapporteren.

Wanneer je hem kunt overslaan

Niet elke organisatie heeft een apart readiness assessment nodig. Wie op een SOC 2-rapport afkoerst, kan een Type I-rapport als nulmeting gebruiken. Dat toetst de opzet op een moment en dwingt dezelfde discipline af, en er komt een rapport uit dat je aan klanten kunt laten zien. Een organisatie in de tweede of derde cyclus met een werkend intern auditprogramma heeft de controle meestal al ingebouwd. Voor een eerste certificering of een eerste Type II-periode is overslaan een gok met de auditdatum als inzet.

Wilt u vooraf weten of de datum kan blijven staan, kijk dan bij onze compliancedienstverlening. De plaats van het assessment in het hele traject staat in het stappenplan voor ISO 27001-certificering.