Er wordt in internal auditland veel over Agile gesproken. Er wordt minder over Agile nagedacht. En er wordt nog minder echt Agile gewerkt. Dat is de harde waarheid achter een begrip dat inmiddels op bijna elke auditdag, in bijna elk jaarplan en in vrijwel elk vacatureprofiel opduikt.
Deze publicatie is niet bedoeld als introductie in Agile methoden. Wie nog niet weet wat een backlog of een sprint is, vindt dat elders uitstekend beschreven
1. Dit is een document voor de internal auditor die al een tijdje met Agile worstelt en wil begrijpen waarom het soms wel en soms niet werkt. De vijf voorbeelden zijn alle ontleend aan de Nederlandse praktijk. Ze laten zien dat Agile audit geen uniforme aanpak is, maar een beweging die zich aan de context moet aanpassen.
Een tweede aanleiding voor deze publicatie is de invoering van de Global Internal Audit Standards (GIAS) per januari 2025
2. Die nieuwe standaarden sluiten conceptueel nauwer aan op Agile denken dan hun voorganger ooit deed. Het verband is nog te weinig gemaakt en dit artikel maak dat inzichtelijk.
Ten slotte staat AI als onderwerp aan de poort. Niet als hype, maar als instrument dat de Agile auditcyclus substantieel kan versnellen, mits je weet waarvoor je het inzet.
1. De stand van zaken: eerlijk zijn
Agile audit is geen nieuw idee meer. De eerste pilots in Nederland dateren van ruim tien jaar geleden, aanvankelijk vooral bij auditfuncties die werkten voor of binnen IT-gedreven organisaties. Sindsdien is de adoptie gegroeid, maar de kwaliteit van die adoptie is ongelijkmatig.
Wat in de praktijk vaak 'Agile audit' heet, is in werkelijkheid niet veel meer dan een standup gepland op maandagochtend, een digitaal bord met auditonderwerpen en een kortere rapportagetemplate. De geest achter Agile, namelijk het fundamenteel anders omgaan met onzekerheid, planning en de relatie met de auditee, is nauwelijks aanwezig. De vorm is overgenomen, de inhoud niet. Agile vraagt meer dan nieuwe terminologie. Het vraagt een andere houding van de auditor, een andere rolopvatting van de CAE en een andere verwachting bij het bestuur en de auditcommissie. Dat is een veel omvangrijkere verandering dan het invoeren van een sprint-planningssessie.
Tegelijkertijd zijn er auditfuncties die wel degelijk de diepgang bereiken. De vijf voorbeelden in dit document zijn daarvan getuige. Ze laten zien dat Agile audit in zeer uiteenlopende contexten werkt.
2. Wat Agile audit eigenlijk betekent
De kern van Agile audit is niet een set van technieken. Het is een antwoord op een fundamenteel probleem: de traditionele auditcyclus is ontworpen voor een stabiele wereld, en die wereld bestaat niet meer. Een auditprogramma dat in september wordt vastgesteld en in mei wordt afgerond, rapporteert over risico's die inmiddels anders van aard zijn geworden, in een organisatiecontext die ondertussen is veranderd.
Agile audit probeert die vertraging te verkorten. Dat doet het op drie manieren die, als ze alle drie aanwezig zijn, pas echt verschil maken.
De eerste is het werken in korte cycli. In plaats van een audit die drie tot vier maanden loopt, wordt de scope opgedeeld in deelstukken van twee tot vier weken. Aan het einde van elk deelstuk is er iets bruikbaars: een bevinding, een tussenrapportage, een gerichte terugkoppeling aan de auditee.
De tweede is continue herprioritering. De auditbacklog wordt niet eenmalig vastgesteld maar voortdurend bijgewerkt op basis van nieuwe risico-informatie, veranderende organisatorische prioriteiten en signalen uit het werkveld.
De derde is nauwere samenwerking met de auditee. In een Agile audit is de auditee geen passief persoon die de audit maar moet ondergaan, maar een actieve gesprekspartner die meedenkt over scope, richting en relevantie.
3. Lean principes als fundament
Agile audit staat niet op zichzelf. Het is voor een groot deel geworteld in Lean-denken, de managementfilosofie die Toyota in de jaren vijftig ontwikkelde en die decennia later ook buiten de productie-industrie ingang vond
3. Wie de Lean-principes begrijpt, begrijpt ook waarom Agile audit werkt zoals het werkt.
Lean draait om het elimineren van verspilling. Alles wat geen directe waarde toevoegt voor de ontvanger, is verspilling. Voor een auditfunctie betekent dat concreet: lange doorlooptijden zijn verspilling, uitgebreide documentatie die niemand leest is verspilling, interne reviewronden die geen kwaliteit toevoegen zijn verspilling, en bevindingen die pas worden gedeeld nadat de organisatie al verder is gegaan zijn verspilling.
3.1 De vijf Lean-principes vertaald naar audit
Lean kent vijf kernprincipes
3. Hier vertaald naar de auditpraktijk.
- Waarde definiëren vanuit de ontvanger. Niet de auditor bepaalt wat waardevol is, maar de organisatie die de uitkomsten moet gebruiken. Een bevinding die correct is maar niet bruikbaar, heeft geen waarde. Een aanbeveling die te laat komt, heeft geen waarde. De auditfunctie die Lean werkt, stelt voortdurend de vraag: voor wie doen wij dit, en op welk moment?
- De waardestroom in kaart brengen. Elke stap in het auditproces van eerste risico-identificatie tot afgeronde rapportage moet bijdragen aan het eindresultaat. Stappen die dat niet doen, worden geëlimineerd of vereenvoudigd. Een goede Lean-analyse van het eigen auditproces levert voor de meeste IAF's een lijst van tien tot vijftien activiteiten op die kunnen worden geschrapt of samengevoegd. Zie ook mijn twee eerder publicaties Heb je even tijd voor een interview? en De zin en onzin van advies in een audit rapport
- Flow creëren. Het auditproces moet vloeien, zonder opstoppingen, wachttijden of overdrachten die energie kosten zonder waarde toe te voegen. In de praktijk zitten de grootste verstoringen in de review- en goedkeuringsfase. Rapporten die weken wachten op een handtekening, zijn een klassiek flow-probleem. Het motto moet zijn; van frictie naar flow. Identificeer eerst de frictiepunten, elimineer ze en je zult zien dat de flow gaat komen.
- Pull in plaats van push. Audits worden niet gepland op basis van een vooraf bepaald schema, maar op basis van actuele behoefte. De organisatie trekt als het ware de audit naar zich toe wanneer de behoefte bestaat. Dat vereist een CAE die bereid is van vaste jaarplannen af te stappen en te werken met een dynamische backlog. Maar dat vereist ook stakeholders en opdrachtgever die dat snappen en ook willen. Opdrachtgevers die niet van verandering houden zijn hier beperkend en houden de frictie in stand.
- Streven naar perfectie door voortdurende verbetering. Agile audit zonder retrospectief is geen Agile audit. Na elke sprint of elk audittraject wordt teruggekeken: wat ging goed, wat kan beter, wat laten we de volgende keer achterwege? Die discipline van voortdurende verbetering is het Lean-equivalent van de sprint retrospective.
3.2 Lean en Agile: het verschil
Lean en Agile worden vaak door elkaar gebruikt, maar ze zijn niet hetzelfde. Lean is een filosofie gericht op het elimineren van verspilling en het maximaliseren van klantwaarde. Agile is een set van werkwijzen gericht op flexibiliteit, iteratie en samenwerking. In de auditpraktijk vullen ze elkaar aan: Lean zegt wat je moet weggooien, Agile zegt hoe je moet bewegen.
Een auditfunctie die alleen Lean toepast zonder Agile, optimaliseert het bestaande proces maar past de werkwijze niet fundamenteel aan. Een auditfunctie die alleen Agile toepast zonder Lean, werkt in korte cycli maar neemt verspilling mee van de ene sprint naar de volgende. De combinatie is het meest effectief.
4. Hoe een Agile audit werkt: drie sprints, één rapport
De meest praktische vraag die CAE's stellen wanneer ze Agile overwegen, is: hoe ziet een individuele audit er dan uit? Onderstaande beschrijving geeft een concreet voorbeeld van een audit die in drie sprints wordt uitgevoerd over een periode van negen tot twaalf weken. De audit loopt daarmee even lang als een traditionele audit, maar de verdeling van activiteiten en de interactie met de auditee zijn fundamenteel anders.
4.1 Vóór de eerste sprint: risicoanalyse met het team
Een Agile audit begint niet met een uitgebreid vooronderzoek dat door één auditor wordt uitgevoerd. Ze begint met een gezamenlijke risicoanalyse waarbij het auditteam én relevante vertegenwoordigers van de auditee aanwezig zijn. Dat is misschien het meest ongebruikelijke element voor auditors die gewend zijn aan een strikte scheiding tussen voorbereiding en uitvoering.
Het doel van die gezamenlijke sessie is tweeledig. Ten eerste wordt snel helder wat de auditee zelf als risico ervaart, en wat er in de organisatie al bekend is. Dat voorkomt dat de auditor weken besteedt aan het herontdekken van informatie die al beschikbaar is. Ten tweede creëert de sessie betrokkenheid bij de auditee: wie meedenkt over de scope, is later ook ontvankelijker voor de uitkomsten.
Uit de risicoanalyse volgt een initiële backlog: een geordende lijst van auditonderwerpen met een eerste inschatting van risico en prioriteit. Die backlog is het vertrekpunt voor de sprintplanning. Hij is niet definitief. Dat is bewust.
4.2 Sprint 1: scope bepalen en eerste bevindingen
De eerste sprint duurt drie tot vier weken. Het team werkt aan een beperkt, scherp afgebakend deelaspect van de totale audit. Aan het begin van de sprint wordt in een sprintplanning bepaald welke backlog-items worden opgepakt en wat het concrete doel is aan het einde van de sprint.
Gedurende de sprint is er wekelijks een standup van maximaal dertig minuten. Deelnemers zijn het auditteam en een contactpersoon van de auditee. De standup heeft een vaste structuur: wat is er gedaan, wat staat er voor deze week gepland, en zijn er blokkades? De standup is geen statusrapportage voor het management. Het is een werkoverleg dat problemen vroeg aan de oppervlakte brengt.
Tussenrapportage vindt niet plaats via formele documenten maar via korte updates: een Teams-bericht, een mondelinge terugkoppeling, een samenvatting van maximaal één pagina. De auditee weet waar het team staat en kan op dat moment al reageren en de CAE kan tussentijds bijsturen. Bevindingen die in sprint 1 worden vastgesteld, worden direct gedeeld en niet bewaard voor het eindrapport. Maar dan horen ze ook direct te worden opgepakt door de auditee. Als een risico eenmaal bekend is, dan start de ‘klok’.
Aan het einde van sprint 1 is er een sprint review: een gesprek van een uur met het team en de auditee en eventueel een vertegenwoordiger van het management. De uitkomsten van de sprint worden gepresenteerd, vragen worden beantwoord en de backlog wordt bijgesteld op basis van wat er in de sprint is geleerd. Dat kan bijvoorbeeld betekenen dat een aantal deep-dives in de todo wordt gezet of juist minder diep maar breder; meer onderwerpen van hoger niveau in de todo.
4.3 Sprint 2: verdieping en tussenrapportage
Sprint 2 gaat dieper op de onderwerpen die in sprint 1 als prio zijn geïdentificeerd, of pakt nieuwe backlog-items op als de eerste sprint geen noemenswaardige bevindingen heeft opgeleverd. De keuze wordt gemaakt op basis van de herziene backlog en todo lijst, niet op basis van een vooraf opgesteld werkprogramma.
De wekelijkse standup zorgt dat wordt doorgestart. De tussenrapportage in sprint 2 is iets uitgebreider dan in sprint 1: een korte schriftelijke samenvatting van de bevindingen tot dan toe, gedeeld via Teams of e-mail. Niet als definitief document, maar als werkdocument dat de auditee in staat stelt alvast meer maatregelen voor te bereiden.
De sprint review aan het einde van sprint 2 heeft een specifiek doel: het gezamenlijk bepalen van de scope van sprint 3. Wat verdient verdere aandacht? Zijn er nieuwe risico's zichtbaar geworden? Is er een specifiek onderwerp dat dieper moet worden onderzocht? Die beslissing wordt niet eenzijdig door de auditor genomen, maar in overleg met de auditee en (natuurlijk) uiteindelijk de CAE.
4.4 Sprint 3: verdieping of aanvullend onderwerp, dan het rapport
Sprint 3 is de meest flexibele sprint. Afhankelijk van wat er in de eerste twee sprints is gevonden, zijn er twee richtingen mogelijk.
Als de eerste twee sprints duidelijke, substantiële bevindingen hebben opgeleverd op een afgebakend terrein, wordt sprint 3 gebruikt om op één specifiek onderwerp dieper te gaan. Dat kan een kwetsbaar proces zijn dat nadere analyse verdient, een technisch systeem dat meer onderzoekstijd vraagt, of een bevinding die dusdanige implicaties heeft dat aanvullend bewijs noodzakelijk is voor een stevig oordeel.
Als de eerste twee sprints een breder beeld hebben opgeleverd zonder één dominante bevinding, wordt sprint 3 ingezet om een aanvullend onderwerp te toetsen dat in de oorspronkelijke backlog stond maar nog niet was opgepakt. De audit heeft dan een breder bereik maar minder diepte op individuele onderdelen.
De keuze tussen beide richtingen is onderdeel van de sprint-2-review en wordt expliciet gemaakt. Dat is een van de meest wezenlijke aspecten van Agile audit: de bewuste keuze over wat je doet en wat je laat, gemaakt op basis van actuele informatie.
De standups continueren ook in sprint 3. De tussenrapportage aan het einde van sprint 3 is de basis voor het definitieve rapport. Dat rapport bevat geen verrassingen, want de auditee is gedurende het hele traject op de hoogte gehouden. De formele rapportage is daardoor sneller af en vergt minder discussie. Typisch geval van “frictie naar flow”.
4.5 Het rapport
Het eindrapport van een Agile audit is korter en directer dan het traditionele equivalent. De aanleiding en achtergrond zijn beperkt, omdat die context al eerder mondeling is gedeeld. De bevindingen zijn geordend naar prioriteit, niet naar de volgorde waarin ze zijn gevonden. De aanbevelingen zijn scherp en gericht op de ontvanger die ze al kent er iets mee gaat doen. Waarschijnlijk is men al begonnen. Een specifiek kenmerk van het Agile auditrapport is dat aanbevelingen bij voorkeur worden geformuleerd op een manier die direct bruikbaar is voor de ontvanger. In organisaties die zelf Agile werken, betekent dat: geformuleerd als user story, zodat de aanbeveling direct in de backlog van het betrokken team kan worden opgenomen. Zo krijg je een bruikbare handover van internal audit naar de agile teams in plaats van een moeilijk verhaal dat niet iedereen snapt in een vorm dat niet uitnodigt tot actie.
5. Het Kanban-bord als management tool voor de IAF
Op het niveau van de individuele audit bieden sprints structuur. Op het niveau van de auditfunctie als geheel biedt Kanban het antwoord op de vraag: hoe houd ik overzicht over alle lopende, geplande en potentiële audits?
Kanban is oorspronkelijk een productiebeheersysteem, ontwikkeld bij Toyota als onderdeel van het Lean Production System
4. De kern is eenvoudig: werk wordt zichtbaar gemaakt op een bord, en de doorstroom van werk wordt bewust beperkt om opstoppingen te voorkomen. In de auditpraktijk werkt het als volgt:
5.1 De kolommen van het auditbord
Een Kanban-bord voor een auditfunctie kent doorgaans zes (soms ook meer) kolommen, die samen de volledige levenscyclus van een audit weergeven.
- Audit Universe. Dit is de backlog in zijn meest uitgebreide vorm: alle potentiële auditonderwerpen die de IAF in beeld heeft. De universe wordt gevoed door de risicoanalyse, signalen van het bestuur en de auditcommissie, externe regelgeving, vorige auditresultaten en eigen waarneming. Elk item in de universe heeft een risicogewicht en een datum van laatste behandeling. De universe is nooit statisch. Uit de universe worden onderwerpen geselecteerd die op korte of middellange termijn worden opgepakt. De selectie vindt plaats op basis van actuele risicobeoordeling, capaciteit en de agenda van de auditcommissie. Typisch staan hier drie tot zes onderwerpen, afhankelijk van de omvang van de IAF.
- In voorbereiding. De audit is gestart. De risicoanalyse met het team heeft plaatsgevonden, de scope is bepaald en de sprintplanning voor sprint 1 is gemaakt. Er is een contactpersoon bij de auditee aangewezen en de eerste standup is gepland.
- Fieldwork. De auditor voert de sprints uit. Op het bord is zichtbaar in welke sprint de audit zit en wanneer de volgende sprint review is gepland. Audits die langer dan verwacht in deze kolom blijven staan, zijn een signaal voor de CAE om in te grijpen of de scope bij te stellen.
- Review en rapportage. Het veldwerk is afgerond. Het conceptrapport wordt opgesteld, intern beoordeeld en met de auditee besproken. In een goed functionerende Agile IAF is deze fase kort, omdat de bevindingen al tijdens het traject zijn gedeeld.
- Afgerond. Het rapport is vastgesteld en gedeeld met de opdrachtgever. De kaart blijft op het bord staan als referentie voor de follow-up en de volgende prioriteringsronde.
Dit alles is beschreven vanuit het idee dat het rapport het product is; dan doorloopt de audit (= het rapport) de kanban. Geavanceerder is om te werken met deel-audits die onderdeel uitmaken van een groter geheel. De deelaudits doorlopen de sprints en ‘trekken’ het rapport door het bord heen. Alle deelaudits afgerond = audit afgerond.
5.2 WIP-limieten: bewust beperken
Het krachtigste element van Kanban is niet het bord zelf, maar de Work In Progress-limiet. Die bepaalt hoeveel audits tegelijk in een bepaalde fase mogen zitten. Een IAF van vier FTE die vijf audits tegelijk in de fieldwork-fase heeft, werkt niet parallel, maar chaotisch. De WIP-limiet dwingt af dat een audit wordt afgerond voordat een nieuwe wordt gestart.
In de praktijk betekent dat: maximaal twee à drie audits tegelijk in fieldwork, afhankelijk van de bezetting. Wie meer wil, moet eerst iets afronden. Die discipline is voor veel CAE's ongemakkelijk, maar het is precies de discipline die de doorlooptijden verkort en de kwaliteit verhoogt.
5.3 Het bord als gespreksinstrument
Het Kanban-bord is niet alleen een planningstool. Het is ook een communicatiemiddel. In gesprekken met de auditcommissie biedt het bord in één oogopslag overzicht van de voortgang, de prioriteiten en de keuzes die zijn gemaakt. Een item dat al lang in de universe staat zonder opgepakt te worden, opent een gesprek over of dat bewust is. Een audit die langer dan gepland in fieldwork staat, vraagt om een toelichting.
Dat niveau van transparantie voelt voor sommige CAE's als kwetsbaarheid. In werkelijkheid is het het tegenovergestelde: wie zijn werk inzichtelijk maakt, bouwt vertrouwen op. Wie dat niet doet, wekt de indruk iets te verbergen.
6. De GIAS en Agile: twee kanten van dezelfde munt
De meeste IAF's benaderen de GIAS als een compliancevraagstuk: wat moeten wij doen om aan de Standaarden te voldoen? Dat is begrijpelijk maar beperkt. Want wie de GIAS naast de principes van Agile audit legt, ziet iets opmerkelijks: de Standaarden ademen dezelfde filosofie als Agile audit, zonder dat woord ooit te gebruiken.
Het performance-domein vraagt dat de CAE doelen en KPI's ontwikkelt voor de IAF en de realisatie bewaakt. Dat is precies wat Agile-gerichte auditfuncties al doen via sprint reviews en retrospectives. De eis dat de IAF strategisch aansluit bij de doelen van de organisatie, was in het oude IPPF een aanbeveling; in de GIAS is het een vereiste. Agile audit is bij uitstek een methode om die aansluiting dynamisch te houden.
De GIAS biedt daarmee een normatieve basis voor Agile audit die eerder ontbrak. CAE's die hun bestuur of auditcommissie nog moeten overtuigen van een Agile transitie, hebben nu een krachtig argument: het is niet alleen modern, het is GIAS-conform.
7. AI als versneller van de Agile auditcyclus
Agile audit staat of valt bij snelheid. Sprints van twee tot vier weken zijn alleen haalbaar als de tijdsinvestering in voorbereiding, analyse en rapportage omlaag gaat. Generatieve AI kan op alle drie die onderdelen een bijdrage leveren
5.
Bij de voorbereiding kan AI grote hoeveelheden documentatie samenvatten, inconsistenties signaleren en op basis van een risicoprofiel een eerste raamwerk van aandachtspunten genereren. Bij de analyse maakt AI eenvoudigere data analyses toegankelijk voor de generalist: het vergelijken van datasets, het signaleren van afwijkingen, het koppelen van informatiebronnen. Bij de rapportage kan AI helpen bij het genereren van een eerste concept op basis van aantekeningen en bevindingen.
Een kanttekening is noodzakelijk. AI vergroot het risico op schijnprecisie: output die er betrouwbaar uitziet maar dat niet is. De auditor die AI inzet, heeft een extra verplichting tot kritisch oordeel. Het instrument werkt alleen goed als de gebruiker weet wat hij vraagt en wat de beperkingen zijn.
8. Vijf lessen uit de praktijk
De onderstaande voorbeelden zijn ontleend aan werkelijke situaties in de Nederlandse markt. Namen van organisaties zijn in geanonimiseerd. De beschreven lessen zijn echter reëel.
Voorbeeld 1: De angst om iets te missen
Een grote ziekenhuisinstelling had een externe kwaliteitsbeoordeling (EQA) afgerond met een positief oordeel. Het team was er klaar voor om de volgende stap te zetten: minder omvangrijke maar meer impactvolle audits. De behoefte was helder. De weg er naartoe niet.
Vier workshops later was de kern van het probleem zichtbaar geworden. Het auditteam was geconditioneerd om volledig te zijn. Ieder risico moest zijn afgedekt, iedere bevinding onderbouwd, iedere conclusie voorzien van een uitputtende toelichting. Die grondhouding is begrijpelijk in een zwaar gereguleerde omgeving als de zorg, maar ze staat haaks op Agile werken.
Het doorbraakmoment kwam toen een teamlid uitsprak wat iedereen al voelde: wij hebben angst om dingen te laten. Die formulering, die algauw 'The Fear of Missing Things' werd genoemd, opende een gesprek. Niet over methoden of templates, maar over de professionele zelfopvatting van de auditor.
De praktische consequentie was een radicale ingreep in de manier van rapporteren. 'The Art of Leaving Out', zoals het team het noemde, bleek voor de ontvanger geen verlies maar een verbetering.
Kernles: Agile audit begint niet bij een tool of een methode. Het begint bij de bereidheid van het team om bewust te kiezen om niet volledig te proberen te zijn.
Voorbeeld 2: Het politieke ritme als auditritme
Een middelgrote gemeente met een auditfunctie van drie FTEhad jarenlang gewerkt met een klassiek jaarplan: tien tot twaalf audits per jaar, gepland op basis van een risicoanalyse die in september van het voorgaande jaar was vastgesteld. De uitvoering liep structureel achter op de planning. Audits kwamen te laat, bevindingen waren al ingehaald door besluiten uit de raadsvergadering, en de CAE stond jaarlijks voor de onmogelijke taak om achterstand goed te praten bij de auditcommissie.
Het auditritme was losgeregeld van het bestuurlijke ritme. De gemeente werkte in bestuurs- en begrotingscycli die niets gemeen hadden met de kalender van de auditfunctie. Audits leverden informatie op het moment dat besluiten al genomen waren.
De vaste jaarplanning werd vervangen door een vooruitrollend kwartaalplan, waarbij de auditcommissie samen met het bestuur elke drie maanden mee-beoordeelde wat de prioriteiten waren. Daarnaast werd de rapportagevorm herzien: in plaats van uitgebreide rapporten met aanbevelingen op detailniveau, werkte de auditfunctie voortaan met beknopte audit-'briefs' van maximaal twee pagina's, gericht op het besluit dat op dat moment in de raad of het college voorlag.
Het effect was merkbaar. De vraag van de gemeentesecretaris naar de planning van nieuwe audits nam af, en de frequentie waarmee auditresultaten in commissievergaderingen werden aangehaald, nam toe.
Kernles: In politieke en bestuurlijke omgevingen is Agile audit in de eerste plaats een kwestie van timing. Een goed rapport op het verkeerde moment heeft geen waarde.
Voorbeeld 3: Auditen van een bewegend doel
De invoering van de Wet toekomst pensioenen (Wtp) dwong fondsen tot een grote transformatie
6. Vrijwel alle bedrijfsprocessen, IT-systemen en communicatiestructuren moesten worden herzien. De auditfunctie stelde een ongemakkelijke vraag: hoe audit je iets wat voortdurend van vorm verandert?
De traditionele aanpak, eerst het systeem begrijpen en dan toetsen of het werkt, was onwerkbaar. Tegen de tijd dat de audit was afgerond, had het systeem alweer drie iteraties doorgemaakt.
De oplossing was een herdefinitie van de auditopdracht. In plaats van het systeem te toetsen op zijn eindtoestand, richtte de audit zich op de beheersing van het veranderingsproces zelf. Heeft het fonds zicht op de risico's die met de transitie samenhangen? Worden beslissingen genomen op basis van adequate informatie? Is er een mechanisme om fouten vroeg te signaleren?
Per sprint van drie weken werden specifieke onderdelen van het transformatieprogramma bekeken, met een directe terugkoppeling aan het programmamanagement via een korte mondelinge briefing en een samenvattend bericht in Teams. De auditcommissie ontving periodieke briefings in plaats van een halfjaarlijks (en ondertussen al verouderd) rapport. De doorbraak in het vertrouwen kwam toen een sprint-terugkoppeling een fout blootlegde die nog gecorrigeerd kon worden voor de uitvoering.
Kernles: Bij transformatieaudits is het object van onderzoek het veranderingsproces, niet het eindresultaat. Wie wacht op het resultaat, is te laat.
Voorbeeld 4: Cyber houdt geen rekening met het jaarplan
Een nutsbedrijf had de cyberrisico's al jaren prominent op de auditkalender staan. De uitvoering liet echter te wensen over. Planning begon in januari, fieldwork vond plaats in mei en het rapport werd in september opgeleverd. Tegen die tijd waren de dreigingen die in het rapport werden beschreven, alweer vervangen door andere. Niet zo gek, want de IT functie zat bovenop de audit en wist al wat er moest gebeuren voordat het concept rapport geschreven was. Ten tijde van de rapportage waren de meeste bevindingen al verholpen en zat eigenlijk niemand meer op het papier te wachten.
De cyber-audit werd omgezet in een terugkerend kortcyclisch programma: vier keer per jaar een gerichte toets op een specifiek deelaspect. De CISO werd betrokken als structurele gesprekspartner bij de prioritering. De samenwerking vereiste een expliciete afspraak over onafhankelijkheid: de CISO leverde informatie over het dreigingslandschap, de auditor bepaalde zelf wat hij onderzocht en hoe hij dat beoordeelde.
De auditcommissie ontving vier keer per jaar een cyberbriefing op basis van actuele bevindingen. De doorlooptijd per audit was teruggebracht van vier maanden naar zes weken.
Kernles: Technische risico's vragen een technisch tempo. Een auditcyclus van twaalf maanden is voor cyberrisico's structureel ongeschikt.
Voorbeeld 5: Auditen van een auditee die sneller is dan jij
Een middelgrote retailketen werkte volledig Agile: productteams in sprints van twee weken, wekelijkse IT-releases, dagelijkse bijsturing op data. De auditfunctie werkte op het oude tempo. Audits duurden drie maanden, rapporten werden gedeeld nadat de relevante besluiten al waren genomen, en aanbevelingen raakten processen die inmiddels alweer drie iteraties verder waren.
Een auditor die een Agile organisatie benadert met een waterval-methode, audit niet de organisatie zoals ze is, maar een abstracte weergave van hoe ze zou moeten zijn in een stabiele wereld.
Drie teamleden volgden een Scrum-training, niet om zelf Scrum te gebruiken maar om te begrijpen hoe de organisatie dacht en werkte. Audits werden ingekort tot maximaal vier weken. Terugkoppeling vond plaats in de sprint review van het betrokken team, niet in een apart auditrapport. Aanbevelingen werden geformuleerd als user stories, zodat ze direct in de backlog van het team konden worden opgenomen.
Die laatste innovatie was misschien wel de meest impactvolle: bevindingen die als user story worden geformuleerd, worden eerder opgepakt dan bevindingen die als tekortkomingen worden gepresenteerd.
Kernles: Als de auditee sneller werkt dan de auditor, is de audit niet leidend meer maar volgend. Het enige antwoord is je tempo aanpassen, of je relevantie verliezen.
9. Waar staan we nu? Een eerlijke balans
Drie patronen zijn zichtbaar in de praktijk.
- Het eerste is de cosmetische adoptie: de terminologie is Agile, de werkwijze niet. Sprints zijn ingevoerd als alternatieve naam voor de planningsfase en de backlog is een digitale versie van het jaarplan. Dit patroon is het meest verbreid en is vaak het resultaat van een top-down besluit zonder voldoende aandacht voor cultuur en gedrag.
- Het tweede patroon is de selectieve adoptie: Agile principes worden toegepast op een deel van de auditactiviteiten, typisch de operationele audits, terwijl governance- en compliance-audits op de traditionele manier worden uitgevoerd. Dat is een pragmatische keuze die werkt, en kan voor sommige audit functies het maximaal haalbare zijn.
- Het derde patroon is de volledige integratie: Agile denken heeft de werkwijze op alle niveaus doorgedrongen, van de opbouw van de backlog tot de formulering van aanbevelingen en de dialoog met de auditcommissie. Dit patroon is het minst verbreid maar het meest duurzaam.
De GIAS bieden nu een normatief kader dat de transitie naar het derde patroon kan ondersteunen. De vraag voor CAE's is niet of Agile relevant is. Die vraag is beantwoord. De vraag is hoe diep ze bereid zijn te gaan in de verandering die echte Agile adoptie vereist.
Literatuur en bronnen
Bronverwijzingen
- Schwaber, K. & Sutherland, J. (2020). The Scrum Guide. Scrum.org.
- IIA (2024). Global Internal Audit Standards. The Institute of Internal Auditors. Gepubliceerd 9 januari 2024, van kracht per 9 januari 2025.
- Womack, J.P. & Jones, D.T. (1996). Lean Thinking. Simon & Schuster.
- Ohno, T. (1988). Toyota Production System: Beyond Large-Scale Production. Productivity Press.
- IIA (2023). Artificial Intelligence in Internal Auditing. Global Guidance. The Institute of Internal Auditors.
- Rijksoverheid (2023). Wet toekomst pensioenen. Staatsblad 2023.