Een audit faal je zelden op de techniek. Je faalt op het ontbreken van bewijs dat de techniek doet wat je zegt dat ze doet. Dat onderscheid bepaalt of een rapport met bevindingen een administratief ongemak is of het begin van een opgeschort certificaat.
Audit recovery is het traject tussen die twee uitkomsten. Het is het werk dat begint op de dag dat het auditrapport binnenkomt en eindigt op de dag dat een auditor tekent dat de controle aantoonbaar werkt. In mijn ervaring is dat traject vrijwel nooit een technisch probleem. Het is een prioriterings-, governance- en bewijsvoeringsprobleem. En precies daarom loopt het zo vaak vast.
Dit artikel beschrijft hoe je een verzameling auditbevindingen in ongeveer zes maanden terugbrengt tot aantoonbare, werkende controle, zonder de business plat te leggen en zonder dat je het halve jaar daarna dezelfde discussie opnieuw voert.
Wat audit recovery eigenlijk is
Audit recovery is het gestructureerd wegwerken van non-conformiteiten die een externe of interne audit heeft vastgesteld, tot een niveau waarop de certificerende instelling of toezichthouder ze als afgesloten beschouwt. Het raakt vrijwel altijd drie lagen tegelijk: de techniek (de control zelf), het proces (wie doet wat, wanneer) en het bewijs (kun je laten zien dat het is gebeurd).
De meeste organisaties richten al hun energie op de eerste laag. Ze repareren de control en gaan ervan uit dat de bevinding daarmee weg is. Maar een auditor sluit een bevinding niet omdat je iets hebt gerepareerd. Hij sluit ze als je kunt aantonen dat de reparatie de onderliggende oorzaak adresseert én dat de control sindsdien aantoonbaar functioneert. Dat is een wezenlijk hoger bewijsniveau dan “het is gefixt”.
Waarom auditbevindingen zich opstapelen
Bij vrijwel elk hersteltraject zie je dezelfde patronen terugkomen. Het loont om ze te herkennen voordat je aan een actieplan begint.
Bevinding versus onderliggende oorzaak
De grootste valkuil is symptoombestrijding. Een bevinding luidt bijvoorbeeld dat drie vertrokken medewerkers nog actieve accounts hadden. De reflex is: die drie accounts intrekken, bevinding afvinken. Maar de auditor heeft geen probleem met drie accounts, hij heeft een probleem met een joiner-mover-leaver-proces dat ze liet bestaan. Trek je alleen de drie accounts in, dan komt dezelfde bevinding bij de volgende audit gewoon terug, met andere namen.
Een correctief actieplan dat geen root-cause analyse bevat, is daarom in de praktijk waardeloos. ISO/IEC 27001 maakt dit in clausule 10.2 ook expliciet: je moet de oorzaak van de non-conformiteit wegnemen zodat ze zich niet herhaalt, niet alleen het gevolg.
Klein versus groot: het verschil dat je termijn bepaalt
Niet elke bevinding weegt even zwaar, en de zwaarte bepaalt je klok. Een kleine non-conformiteit is een geïsoleerde tekortkoming; een grote wijst op een structureel gebrek in opzet of werking van je managementsysteem. Bij uitsluitend kleine bevindingen blijft een ISO 27001-certificaat doorgaans geldig zolang je tijdig corrigeert. Bij een grote non-conformiteit wordt de certificering opgeschort of ingetrokken tot je herstel hebt aangetoond.
Praktisch betekent dit: je dient meestal binnen dertig dagen een correctief actieplan in, met implementatie binnen ongeveer drie maanden voor kleine en zes maanden voor grote bevindingen. Die termijnen zijn je echte deadline, niet het moment waarop het jou uitkomt.
De zes maanden, fase voor fase
Hieronder de fasering die in mijn ervaring het verschil maakt tussen een hersteltraject dat één keer wordt gedaan en een dat halfjaarlijks terugkeert.
Week 1–2: triage en root-cause
Begin niet met repareren. Begin met sorteren. Leg alle bevindingen naast elkaar en scoor ze op twee assen: zwaarte (klein/groot, en de bijbehorende termijn) en onderliggende oorzaak. Je zult merken dat tien bevindingen vaak terug te voeren zijn op twee of drie oorzaken. Eén zwak offboarding-proces, één ontbrekende eigenaarschapsstructuur, één control die wel bestaat maar nooit wordt uitgevoerd.
Die clustering is de belangrijkste stap van het hele traject. Ze bepaalt of je tien losse reparaties doet of drie structurele ingrepen die tien bevindingen tegelijk afdekken.
Week 3–6: het corrigerende actieplan
Per cluster schrijf je één corrigerend actieplan: de oorzaak, de maatregel, de eigenaar, de termijn en — cruciaal — de manier waarop je straks aantoont dat het werkt. Dat laatste vergeten veel mensen. Een actieplan zonder benoemde bewijsvoering levert over vier maanden opnieuw een discussie met de auditor op.
Houd de plannen realistisch en haalbaar binnen de gestelde termijn. Een ambitieus plan dat je niet haalt, is schadelijker dan een bescheiden plan dat je wél afmaakt: een gemiste zelf-opgelegde deadline is voor een auditor een extra signaal van zwakke governance. Dit is overigens waar veel trajecten al sneuvelen — niet op de techniek maar op de aansturing. Ik heb dat patroon eerder beschreven in waarom IAM-projecten falen op governance, niet op techniek.
Maand 2–4: implementeren zonder de business plat te leggen
Hier botst compliance met de waan van de dag. Een control aanscherpen betekent vaak dat iemands werk trager of strenger wordt, en dat levert weerstand op. Mijn advies: behandel de zwaarste cluster als een klein verandertraject, niet als een ticket. Communiceer vooraf, wijs één eigenaar aan die mandaat heeft, en plan de implementatie in blokken in plaats van “erbij”.
Toegangscontroles zijn hierbij het gevoeligst, omdat ze direct raken aan wat mensen dagelijks kunnen. Zie de aanpak die ik beschrijf in recertificering als changemanagement — diezelfde logica geldt voor vrijwel elke control die je in een hersteltraject aanscherpt.
Maand 5–6: aantoonbaar maken en heraudit
De laatste fase gaat niet over repareren maar over bewijzen. Verzamel per cluster de evidence: de gewijzigde procesbeschrijving, een steekproef die laat zien dat het proces sinds invoering daadwerkelijk is gevolgd, en de logbestanden of rapportages die dat onderbouwen. Vraag daarna pas een heraudit of opvolgingsbeoordeling aan.
Het verschil tussen een geslaagde en een mislukte heraudit zit bijna altijd in dit detail: kun je niet alleen tonen dát de control bestaat, maar ook dat ze in de tussenliggende maanden heeft gewerkt.
De controls waar auditors als eerste op duiken
Niet alle bevindingen zijn even waarschijnlijk. In hersteltrajecten op het snijvlak van security en identiteit komen een paar controls structureel terug.
Toegangsbeheer en recertificering
Toegangsrechten die niet meer kloppen zijn de meest getoetste en meest gevonden tekortkoming. Recertificering — het periodiek bevestigen dat rechten nog terecht zijn — is een verplichte control onder vrijwel elk raamwerk, van ISO 27001 tot NIST SP 800-53 (control AC-2). Een recertificering die op papier groen staat maar feitelijk uit bulk-goedkeuringen bestaat, is voor een ervaren auditor zo doorzien, en levert dan een zwaardere bevinding op dan helemaal geen review.
Privileged access
Beheeraccounts en andere rechten met hoge impact horen in een aparte categorie, met een strakkere cadans en expliciete validatie. Steeds vaker geldt dat ook voor niet-menselijke identiteiten: service accounts, tokens en de identiteiten van AI-agents die zelfstandig handelen. Wie die laatste categorie in een hersteltraject overslaat, dekt de bevinding van vandaag af en bouwt de bevinding van volgend jaar alvast op. Ik werk dat verder uit in wie beheert de identiteit van je AI-agent.
Aantoonbaarheid: groen op papier versus werkende controle
De rode draad door elk geslaagd hersteltraject is hetzelfde principe: een auditor koopt geen reparatie, hij koopt bewijs. Dat verandert hoe je het hele traject inricht. Je documenteert niet achteraf — je bouwt de bewijsvoering in vanaf de eerste week, omdat je anders over vijf maanden geen steekproef hebt die ver genoeg terugloopt.
Dit is ook waarom audit recovery geen puur technische klus is. De techniek repareren kan een specialist in dagen. Aantonen dat de organisatie de control consequent volgt, met benoemde eigenaren en herhaalbaar bewijs, is een governance- en verandervraagstuk. Dat is het deel dat tijd kost, en het deel dat bepaalt of de bevinding écht weg is.
NIS2 verhoogt de inzet
Wat tot voor kort vooral een certificeringsrisico was, wordt onder de Cyberbeveiligingswet — de Nederlandse uitwerking van NIS2 — een bestuursrisico. Toezichthouders zoals de Rijksinspectie Digitale Infrastructuur krijgen ruimere bevoegdheden om te inspecteren en bevindingen op te volgen, en bestuurders worden persoonlijk aanspreekbaar op de adequaatheid van hun maatregelen.
Een papieren control die niet feitelijk klopt, is in dat regime een grotere blootstelling dan onder eerdere kaders. Audit recovery verschuift daarmee van een taak voor de compliance-afdeling naar een onderwerp dat aantoonbaar tot in de directie wordt belegd. Het bredere mechanisme achter die verschuiving beschrijf ik in digitale soevereiniteit: waarom ‘EU’ geen vinkje is.
Tot slot
Auditbevindingen oplossen lukt vrijwel altijd binnen de termijn, op één voorwaarde: dat je niet de bevindingen repareert maar de oorzaken, en dat je het bewijs inbouwt in plaats van het achteraf bij elkaar zoekt. Drie structurele ingrepen die tien symptomen afdekken, met benoemde eigenaren en herhaalbaar bewijs, leveren een rapport op dat je aan een auditor kunt laten zien én dat feitelijk klopt.
Wie de bevindingen stuk voor stuk wegvinkt, krijgt een groen rapport en over zes maanden dezelfde audit terug.
Veelgestelde vragen over audit recovery
Wat betekent audit recovery precies?
Audit recovery is het gestructureerd herstellen van een organisatie na een audit met non-conformiteiten, tot het punt waarop een auditor of toezichthouder de bevindingen als afgesloten beschouwt. Het omvat de techniek (de control repareren), het proces (eigenaarschap en uitvoering borgen) en de bewijsvoering (aantonen dat de control werkt).
Hoeveel tijd krijg je om auditbevindingen op te lossen?
Je dient doorgaans binnen dertig dagen een correctief actieplan in bij de certificerende instelling. De implementatie moet meestal binnen ongeveer drie maanden voor kleine en zes maanden voor grote non-conformiteiten zijn afgerond. De exacte termijn staat in het auditrapport en is leidend.
Wat is het verschil tussen een kleine en een grote non-conformiteit?
Een kleine non-conformiteit is een geïsoleerde tekortkoming die het managementsysteem als geheel niet ondermijnt. Een grote non-conformiteit wijst op een structureel gebrek in opzet of werking en kan leiden tot opschorting of intrekking van de certificering tot herstel is aangetoond.
Waarom komen dezelfde auditbevindingen elk jaar terug?
Meestal omdat het corrigerende actieplan het symptoom adresseerde in plaats van de onderliggende oorzaak. Zonder root-cause analyse repareer je het gevolg, terwijl het zwakke proces dat de bevinding veroorzaakte blijft bestaan. ISO 27001 clausule 10.2 vereist daarom expliciet dat je de oorzaak wegneemt zodat de non-conformiteit zich niet herhaalt.
Welke controls worden bij een audit het vaakst afgekeurd?
Toegangsbeheer staat bovenaan: accounts van vertrokken medewerkers, rechten die niet meer kloppen, en recertificeringen die alleen op papier zijn uitgevoerd. Privileged access en de identiteiten van service accounts en AI-agents zijn een tweede categorie die in moderne omgevingen snel tot bevindingen leidt.
Is audit recovery een technisch of een organisatorisch traject?
Overwegend organisatorisch. De technische reparatie van een control is vaak het kleinste deel. Het zwaartepunt ligt bij root-cause analyse, het beleggen van eigenaarschap en het opbouwen van herhaalbaar bewijs dat de control consequent wordt gevolgd — dat is een governance- en verandervraagstuk, geen installatieklus.
