Agile Audit - vijf lessen uit de praktijk

In internal auditland wordt 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 geen introductie in Agile methoden. Wie nog niet weet wat een backlog of een sprint is, vindt dat elders uitstekend beschreven¹. 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 komen uit de Nederlandse praktijk. Ze laten zien dat Agile audit geen uniforme aanpak is, maar een beweging die zich aan de context aanpast.

Een tweede aanleiding is de invoering van de Global Internal Audit Standards (GIAS) per januari 2025². Die standaarden sluiten conceptueel nauwer aan op Agile denken dan hun voorganger ooit deed. Dat verband is nog te weinig gelegd. Ik leg het hier.

AI speelt ook een rol. Niet als hype, maar als instrument dat de Agile auditcyclus versnelt, 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, vooral bij auditfuncties binnen IT-gedreven organisaties. Sindsdien is de adoptie gegroeid, maar de kwaliteit verschilt enorm.

Wat in de praktijk 'Agile audit' heet, is vaak weinig meer dan een standup op maandagochtend, een digitaal bord met auditonderwerpen en een kortere rapportagetemplate. De kern van Agile ontbreekt vrijwel volledig: fundamenteel anders omgaan met onzekerheid, planning en de relatie met de auditee. 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 verwachtingen bij bestuur en auditcommissie die meebewegen. Dat is een wezenlijk grotere verandering dan het invoeren van een sprint-planningssessie.

Tegelijkertijd zijn er auditfuncties die wél die diepgang bereiken. De vijf voorbeelden in dit document laten dat zien.

2. Wat Agile audit eigenlijk betekent

De kern van Agile audit is geen set 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 van karakter zijn veranderd, binnen een organisatie die er anders uitziet.

Agile audit probeert die vertraging te verkorten. Dat doet het op drie manieren, die pas werken als ze alle drie aanwezig zijn.

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 ligt 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. Nieuwe risico-informatie, verschuivende organisatorische prioriteiten en signalen uit het werkveld bepalen wat voorrang krijgt.

De derde is nauwere samenwerking met de auditee. In een Agile audit is de auditee geen passieve partij die de audit ondergaat, maar een actieve gesprekspartner. Iemand 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 voet aan de grond kreeg³. Wie de Lean-principes begrijpt, begrijpt 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: lange doorlooptijden, uitgebreide documentatie die niemand leest, interne reviewronden die geen kwaliteit toevoegen, en bevindingen die pas worden gedeeld nadat de organisatie al verder is.

3.1 De vijf Lean-principes vertaald naar audit

Lean kent vijf kernprincipes³. 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.
• 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. Van frictie naar flow: identificeer de frictiepunten, elimineer ze, en de flow volgt.
• 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 een dynamische backlog te gebruiken. En het vereist opdrachtgevers die dat begrijpen en willen.
• 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?

3.2 Lean en Agile: het verschil

Lean en Agile worden vaak door elkaar gebruikt, maar het zijn verschillende dingen. Lean is een filosofie die draait om het elimineren van verspilling en het maximaliseren van klantwaarde. Agile is een set werkwijzen gericht op flexibiliteit, iteratie en samenwerking. In de auditpraktijk vullen ze elkaar aan: Lean bepaalt wat je schrapt, Agile bepaalt hoe je beweegt.

Lean zonder Agile optimaliseert het bestaande proces maar verandert de werkwijze niet. Agile zonder Lean werkt in korte cycli maar sleept verspilling mee van sprint naar sprint. De kracht zit in de combinatie.

4. Hoe een Agile audit werkt: drie sprints, één rapport

De vraag die CAE's het vaakst stellen: hoe ziet een individuele audit er dan uit? Hieronder een concreet voorbeeld van een audit in drie sprints over negen tot twaalf weken. De doorlooptijd is vergelijkbaar met 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 door één auditor. Ze begint met een gezamenlijke risicoanalyse waarbij het auditteam én relevante vertegenwoordigers van de auditee aan tafel zitten. Voor auditors die gewend zijn aan een strikte scheiding tussen voorbereiding en uitvoering is dat waarschijnlijk het meest onwennige element.

Eerst 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 allang beschikbaar is. Tegelijk creëert de sessie betrokkenheid: wie meedenkt over de scope, is later 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 en is bewust niet definitief.

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. Bij aanvang bepaalt het team in een sprintplanning 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, met het auditteam en een contactpersoon van de auditee. Vaste structuur: wat is er gedaan, wat staat er gepland, zijn er blokkades? De standup is geen statusrapportage voor het management, maar een werkoverleg dat problemen vroeg zichtbaar maakt.

Tussenrapportage loopt niet via formele documenten. Een Teams-bericht, een mondelinge terugkoppeling, een samenvatting van maximaal één pagina. Bevindingen uit sprint 1 deel je direct, niet bewaren voor het eindrapport. Voorwaarde: ze worden ook direct opgepakt. Zodra een risico bekend is, start de klok.

Sprint 1 sluit af met een sprint review: een gesprek van een uur met het team, de auditee en eventueel een vertegenwoordiger van het management. De uitkomsten worden gepresenteerd, vragen beantwoord en de backlog bijgesteld op basis van wat de sprint heeft opgeleverd.

4.3 Sprint 2: verdieping en tussenrapportage

Sprint 2 gaat dieper in op de onderwerpen die in sprint 1 als prioriteit zijn aangemerkt. Heeft de eerste sprint geen noemenswaardige bevindingen opgeleverd, dan pakt het team nieuwe backlog-items op. Die keuze volgt uit de herziene backlog, niet uit een vooraf opgesteld werkprogramma.

De tussenrapportage in sprint 2 is uitgebreider dan in sprint 1: een korte schriftelijke samenvatting van de bevindingen tot dan toe, gedeeld via Teams of e-mail. Geen definitief document, maar een werkdocument waarmee de auditee alvast maatregelen kan voorbereiden.

De sprint review aan het einde van sprint 2 heeft één doel: samen de scope van sprint 3 bepalen. Wat verdient verdere aandacht? Zijn er nieuwe risico's zichtbaar geworden? Die beslissing neemt de auditor niet alleen, maar in overleg met de auditee en de CAE.

4.4 Sprint 3: verdieping of aanvullend onderwerp, dan het rapport

Sprint 3 is de meest flexibele sprint. Afhankelijk van wat de eerste twee sprints hebben opgeleverd, 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. Als de eerste twee sprints een breder beeld hebben gegeven zonder één dominante bevinding, wordt sprint 3 ingezet om een aanvullend onderwerp te toetsen.

De keuze tussen beide richtingen is onderdeel van de sprint-2-review en wordt expliciet vastgelegd. Dat is een van de belangrijkste kenmerken van agile audit: je kiest bewust wat je doet en wat je laat, op basis van actuele informatie.

De tussenrapportage aan het einde van sprint 3 vormt de basis voor het definitieve rapport. Dat rapport bevat geen verrassingen: de auditee is gedurende het hele traject op de hoogte gehouden.

4.5 Het rapport

Het eindrapport van een Agile audit is korter en directer dan het traditionele equivalent. Aanleiding en achtergrond zijn beperkt, want die context is al eerder mondeling gedeeld. Bevindingen zijn geordend naar prioriteit. Aanbevelingen zijn gericht op de ontvanger die ze al kent.

Eén specifiek kenmerk: aanbevelingen worden bij voorkeur geformuleerd als user story, zodat ze direct in de backlog van het betrokken team passen. Dat levert een bruikbare handover op van internal audit naar de agile teams, in plaats van een rapport dat in een la verdwijnt.

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 geeft Kanban het antwoord op de vraag: hoe houd ik overzicht over alle lopende, geplande en potentiële audits?

Kanban komt uit de productiewereld. Toyota ontwikkelde het binnen het Lean Production System⁴. Het principe: maak werk zichtbaar op een bord en beperk bewust hoeveel er tegelijk in beweging is. Dat voorkomt opstoppingen.

5.1 De kolommen van het auditbord

Een Kanban-bord voor een auditfunctie kent doorgaans zes kolommen:

• Audit Universe. De backlog in zijn meest uitgebreide vorm: alle potentiële auditonderwerpen die de IAF in beeld heeft. Gevoed door risicoanalyse, signalen van bestuur en auditcommissie, externe regelgeving en eigen waarneming. De universe is nooit statisch.
• Geselecteerd. Onderwerpen die op korte of middellange termijn worden opgepakt. Typisch drie tot zes items, afhankelijk van de omvang van de IAF.
• In voorbereiding. De audit is gestart. Risicoanalyse gedaan, scope bepaald, sprintplanning voor sprint 1 gemaakt.
• 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.
• Review en rapportage. Het veldwerk is afgerond. 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 staan als referentie voor de follow-up.

5.2 WIP-limieten: bewust beperken

Het krachtigste element van Kanban is de Work In Progress-limiet, niet het bord. Die limiet bepaalt hoeveel audits tegelijk in dezelfde fase mogen zitten. Een IAF van vier FTE die vijf audits tegelijk in fieldwork heeft, werkt niet parallel. Die werkt chaotisch. De WIP-limiet dwingt af dat je een audit afrondt voordat je de volgende start.

Concreet: maximaal twee à drie audits tegelijk in fieldwork, afhankelijk van de bezetting. Wie meer wil, moet eerst iets afronden. Dat voelt voor veel CAE's ongemakkelijk. Het is precies de discipline die doorlooptijden verkort en kwaliteit verhoogt.

5.3 Het bord als gespreksinstrument

Het Kanban-bord is een planningstool én een gespreksinstrument. In de auditcommissie laat het in één oogopslag zien wat loopt, wat prioriteit heeft en welke keuzes zijn gemaakt. Een item dat lang in de universe blijft staan zonder opgepakt te worden, dwingt de vraag af: is dat bewust? Een audit die langer dan gepland in fieldwork hangt, vraagt om uitleg.

Dat niveau van transparantie voelt voor sommige CAE's oncomfortabel. Onterecht. Wie zijn werk inzichtelijk maakt, bouwt vertrouwen op.

6. De GIAS en Agile: twee kanten van dezelfde munt

De meeste IAF's behandelen de GIAS als compliancevraagstuk: wat moeten wij doen om aan de Standaarden te voldoen? Begrijpelijk, maar te beperkt. Leg de GIAS naast de principes van Agile audit en er valt iets op: de Standaarden opereren in hetzelfde denkkader als Agile audit, zonder dat woord ooit te gebruiken.

Het performance-domein eist 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 organisatiedoelen was in het oude IPPF een aanbeveling; in de GIAS is het een harde vereiste. Agile audit is de 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 geen experiment, 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 fronten het verschil maken⁵.

Per sprintfase ziet dat er zo uit:

Sprintfase	Wat AI versnelt	Waar je op let
Voorbereiding	Documentatie samenvatten, inconsistenties signaleren en op basis van het risicoprofiel een eerste raamwerk van aandachtspunten opstellen.	Het raamwerk is een startpunt, geen risicoanalyse. De auditor bepaalt zelf de scope.
Analyse	Datasets vergelijken, afwijkingen signaleren en informatiebronnen koppelen, ook bereikbaar voor de generalist.	Behandel een AI-signaal als hypothese, niet als bewijs. Onderbouw elke bevinding zelf.
Rapportage	Een eerste concept genereren uit aantekeningen en bevindingen.	De auditor blijft auteur. AI levert een concept, geen oordeel.

Maar pas op. AI vergroot het risico op schijnprecisie: output die er betrouwbaar uitziet maar dat niet is. De auditor die AI inzet, draagt een extra verplichting tot kritisch oordeel. Het instrument werkt alleen als de gebruiker weet wat hij vraagt en waar de grenzen liggen.

8. Vijf lessen uit de praktijk

De onderstaande voorbeelden komen uit werkelijke situaties in de Nederlandse markt. Organisatienamen zijn geanonimiseerd.

Voorbeeld 1: De angst om iets te missen

Een groot ziekenhuis had net een externe kwaliteitsbeoordeling (EQA) afgerond met een positief oordeel. Het auditteam wilde door: minder omvangrijke audits, meer impact. De behoefte was helder. De route niet.

Na vier workshops werd de kern zichtbaar. Het team was geconditioneerd om volledig te zijn. Elk risico afgedekt, elke bevinding onderbouwd, elke conclusie voorzien van een uitputtende toelichting. In een zwaar gereguleerde sector als de zorg is die grondhouding begrijpelijk, maar ze staat haaks op Agile werken.

Het kantelpunt kwam toen een teamlid hardop zei wat iedereen al voelde: wij durven niets te laten. Die formulering, die ze al snel 'The Fear of Missing Things' noemden, opende een ander gesprek. Niet over methoden of templates, maar over de professionele identiteit 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 om bewust te kiezen: we hoeven niet volledig te zijn.

Voorbeeld 2: Het politieke ritme als auditritme

Een middelgrote gemeente met een auditfunctie van drie FTE werkte jarenlang met een klassiek jaarplan: tien tot twaalf audits per jaar, gepland vanuit een risicoanalyse die in september van het voorgaande jaar was vastgesteld. De uitvoering liep structureel achter. Audits kwamen te laat, bevindingen waren al ingehaald door raadsbesluiten. De CAE stond jaarlijks voor de ondankbare taak om achterstand goed te praten bij de auditcommissie.

Het auditritme liep volledig uit de pas met het bestuurlijke ritme. De gemeente werkte in bestuurs- en begrotingscycli die niets gemeen hadden met de kalender van de auditafdeling.

De vaste jaarplanning verdween. Daarvoor in de plaats kwam een vooruitrollend kwartaalplan. Elke drie maanden beoordeelden de auditcommissie en het bestuur samen de prioriteiten. Ook de rapportagevorm veranderde: geen uitgebreide rapporten meer, maar audit-'briefs' van maximaal twee pagina's, gericht op het besluit dat op dat moment bij de raad of het college voorlag.

Het effect was zichtbaar. De gemeentesecretaris vroeg minder vaak naar de planning. Auditresultaten werden vaker aangehaald in commissievergaderingen.

Kernles: In politieke en bestuurlijke omgevingen draait Agile audit om timing. Een goed rapport op het verkeerde moment levert niets op.

Voorbeeld 3: Auditen van een bewegend doel

De invoering van de Wet toekomst pensioenen (Wtp) dwong fondsen tot een ingrijpende transformatie⁶. Vrijwel alle bedrijfsprocessen, IT-systemen en communicatiestructuren moesten worden herzien. De auditfunctie stelde de 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 lag in een herdefinitie van de auditopdracht. Niet het systeem toetsen op zijn eindtoestand, maar de beheersing van het veranderingsproces zelf beoordelen. Heeft het fonds zicht op de risico's van de transitie? Worden beslissingen genomen op basis van adequate informatie? Is er een mechanisme dat fouten vroeg zichtbaar maakt?

Elke sprint van drie weken werd een specifiek onderdeel van het transformatieprogramma bekeken. Terugkoppeling aan het programmamanagement volgde direct via een korte briefing en een bericht in Teams. De auditcommissie ontving periodieke briefings in plaats van een halfjaarlijks rapport dat bij verschijning al verouderd was. Het omslagpunt kwam toen een sprint-terugkoppeling een fout blootlegde die nog gecorrigeerd kon worden vóór 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 cyberrisico's al jaren prominent op de auditkalender staan. Planning begon in januari, fieldwork vond plaats in mei, het rapport werd in september opgeleverd. Tegen die tijd waren de dreigingen uit het rapport alweer vervangen door nieuwe. De IT-functie zat bovenop de audit en wist al wat er moest gebeuren voordat het conceptrapport was geschreven. Op het moment van rapportage waren de meeste bevindingen al verholpen. Niemand zat nog op dat papier te wachten.

De cyber-audit werd omgezet in een terugkerend kortcyclisch programma: vier keer per jaar een gerichte toets op één specifiek deelaspect. De CISO werd vaste gesprekspartner bij de prioritering, met een heldere 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 ging 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 draaide op het oude tempo. Audits duurden drie maanden, rapporten landden nadat de besluiten al genomen waren en aanbevelingen gingen over processen die inmiddels drie iteraties verder waren.

Een auditor die een Agile organisatie benadert met een watervalmethode, auditt niet de organisatie zoals ze is. Hij auditt een abstractie: hoe de organisatie zou moeten werken in een stabiele wereld.

Drie teamleden volgden een Scrum-training. Niet om zelf Scrum te gaan draaien, 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 konden worden opgenomen.

Die laatste stap telde het zwaarst: bevindingen die als user story zijn geformuleerd, worden eerder opgepakt dan bevindingen die als tekortkomingen zijn gepresenteerd.

Kernles: Als de auditee sneller werkt dan de auditor, is de audit niet leidend maar volgend. Het enige antwoord: je tempo aanpassen. Of je relevantie verliezen.

9. Waar staan we nu? Een eerlijke balans

In de praktijk zie ik drie patronen.

Het eerste is cosmetische adoptie. De terminologie is Agile, de werkwijze niet. Sprints zijn een andere naam voor de planningsfase en de backlog is een digitale versie van het jaarplan. Dit patroon komt het vaakst voor en ontstaat wanneer een top-down besluit niet gepaard gaat met aandacht voor cultuur en gedrag.

Dan de selectieve adoptie. Agile principes worden toegepast op een deel van de auditactiviteiten, meestal de operationele audits, terwijl governance- en compliance-audits traditioneel worden uitgevoerd. Een pragmatische keuze die werkt, en voor sommige auditfuncties het maximaal haalbare.

En tot slot de volledige integratie: Agile denken dat de werkwijze op elk niveau heeft doorgedrongen. Van backlog-opbouw tot de formulering van aanbevelingen en de dialoog met de auditcommissie. Dit patroon komt het minst voor, maar is het meest duurzaam.

De GIAS bieden een normatief kader dat de transitie naar dit derde patroon ondersteunt. Voor CAE's is er nog maar één vraag: hoe diep ben je bereid te gaan.

Literatuur en bronnen

Bronverwijzingen

1. Schwaber, K. & Sutherland, J. (2020). The Scrum Guide. Scrum.org. scrumguides.org
2. IIA (2024). Global Internal Audit Standards. The Institute of Internal Auditors. Gepubliceerd 9 januari 2024, van kracht per 9 januari 2025. theiia.org
3. Womack, J.P. & Jones, D.T. (1996). Lean Thinking. Simon & Schuster. ISBN: 978-0-684-81035-8.
4. Ohno, T. (1988). Toyota Production System: Beyond Large-Scale Production. Productivity Press. ISBN: 978-0-915299-14-0.
5. IIA (2023). Artificial Intelligence in Internal Auditing. Global Guidance. The Institute of Internal Auditors. theiia.org
6. Rijksoverheid (2023). Wet toekomst pensioenen. Staatsblad 2023. rijksoverheid.nl