Agile Audit — Five Lessons from Practice

In internal audit, Agile is widely discussed. It is less often thought through. And it is even less often genuinely practised. That is the hard truth behind a term that now features in almost every audit conference, almost every annual plan and virtually every job profile.

This publication is not an introduction to Agile methods. Those unfamiliar with backlogs or sprints will find excellent explanations elsewhere¹. This is a document for the internal auditor who has been grappling with Agile for some time and wants to understand why it sometimes works and sometimes does not. The five examples come from Dutch practice. They demonstrate that Agile audit is not a uniform approach, but a movement that adapts to its context.

A second motivation is the introduction of the Global Internal Audit Standards (GIAS) effective January 2025². These Standards align conceptually with Agile thinking far more closely than their predecessor ever did. That connection has not been sufficiently drawn. I make it explicit here.

AI also plays a role. Not as hype, but as an instrument that accelerates the Agile audit cycle — provided you know what to use it for.

1. The state of play: being honest

Agile audit is no longer a new idea. The first pilots in the Netherlands date back over ten years, primarily within audit functions in IT-driven organisations. Since then, adoption has grown, but quality varies enormously.

What passes for 'Agile audit' in practice is often little more than a Monday morning standup, a digital board with audit topics and a shorter reporting template. The essence of Agile is almost entirely absent: a fundamentally different way of dealing with uncertainty, planning and the relationship with the auditee. The form has been adopted, the substance has not.

Agile demands more than new terminology. It demands a different attitude from the auditor, a different role conception from the CAE and different expectations from the board and audit committee. That is a substantially greater change than introducing a sprint planning session.

At the same time, there are audit functions that do achieve that depth. The five examples in this document show how.

2. What Agile audit actually means

The essence of Agile audit is not a set of techniques. It is an answer to a fundamental problem: the traditional audit cycle was designed for a stable world, and that world no longer exists. An audit programme approved in September and completed in May reports on risks that have since changed in character, within an organisation that looks different.

Agile audit seeks to shorten that lag. It does so in three ways, which only work when all three are present.

The first is working in short cycles. Instead of an audit spanning three to four months, the scope is divided into segments of two to four weeks. At the end of each segment, something usable exists: a finding, an interim report, a targeted feedback to the auditee.

The second is continuous reprioritisation. The audit backlog is not set once but constantly updated. New risk information, shifting organisational priorities and signals from the field determine what takes precedence.

The third is closer collaboration with the auditee. In an Agile audit, the auditee is not a passive party undergoing the audit, but an active conversation partner. Someone who contributes to thinking about scope, direction and relevance.

3. Lean principles as the foundation

Agile audit does not stand alone. It is largely rooted in Lean thinking, the management philosophy Toyota developed in the 1950s and which decades later gained traction beyond manufacturing³. Understanding the Lean principles means understanding why Agile audit works the way it does.

Lean revolves around eliminating waste. Anything that does not directly add value for the recipient is waste. For an internal audit function, that means: long lead times, extensive documentation nobody reads, internal review rounds that add no quality, and findings shared only after the organisation has already moved on.

3.1 The five Lean principles translated to audit

Lean has five core principles³. Here translated to audit practice:

• Define value from the recipient's perspective. It is not the auditor who determines what is valuable, but the organisation that must use the outcomes. A finding that is correct but not actionable has no value. A recommendation that arrives too late has no value. The audit function that works Lean continually asks: for whom are we doing this, and at what moment?
• Map the value stream. Every step in the audit process, from initial risk identification to completed reporting, must contribute to the end result. Steps that do not are eliminated or simplified. A proper Lean analysis of the audit process itself yields, for most internal audit functions, a list of ten to fifteen activities that can be removed or consolidated.
• Create flow. The audit process must flow, without bottlenecks, waiting times or handovers that consume energy without adding value. In practice, the greatest disruptions sit in the review and approval phase. Reports waiting weeks for a signature are a classic flow problem. From friction to flow: identify the friction points, eliminate them, and flow follows.
• Pull instead of push. Audits are not planned on the basis of a predetermined schedule, but on the basis of actual need. The organisation effectively pulls the audit towards itself when the need exists. That requires a CAE willing to move away from fixed annual plans and use a dynamic backlog. And it requires stakeholders who understand and support that.
• Pursue perfection through continuous improvement. Agile audit without retrospectives is not Agile audit. After every sprint or audit engagement, the team looks back: what went well, what can improve, what do we leave out next time?

3.2 Lean and Agile: the difference

Lean and Agile are often used interchangeably, but they are different things. Lean is a philosophy focused on eliminating waste and maximising customer value. Agile is a set of practices aimed at flexibility, iteration and collaboration. In audit practice, they complement each other: Lean determines what you cut, Agile determines how you move.

An audit function that applies only Lean without Agile optimises the existing process but does not fundamentally change the way of working. An audit function that applies only Agile without Lean works in short cycles but carries waste from sprint to sprint. The power lies in the combination.

4. How an Agile audit works: three sprints, one report

The question CAEs ask most frequently: what does an individual audit actually look like? Below is a concrete example of an audit in three sprints over nine to twelve weeks. The lead time is comparable to a traditional audit, but the distribution of activities and the interaction with the auditee are fundamentally different.

4.1 Before the first sprint: risk analysis with the team

An Agile audit does not begin with an extensive preliminary study by a single auditor. It begins with a joint risk analysis where the audit team and relevant representatives of the auditee sit together. For auditors accustomed to a strict separation between preparation and execution, this is probably the most unfamiliar element.

The purpose is twofold. First, it quickly becomes clear what the auditee perceives as risk and what is already known within the organisation. This prevents the auditor spending weeks rediscovering information that is already available. Additionally, the session creates engagement: those who contribute to scoping are more receptive to the outcomes later.

The risk analysis produces an initial backlog: an ordered list of audit topics with a first estimate of risk and priority. That backlog is the starting point for sprint planning and is deliberately not definitive.

4.2 Sprint 1: determining scope and first findings

The first sprint lasts three to four weeks. The team works on a limited, sharply defined aspect of the total audit. At the outset, the team determines in a sprint planning which backlog items are taken up and what the concrete goal is at the end of the sprint.

During the sprint, there is a weekly standup of no more than thirty minutes, with the audit team and a contact person from the auditee. Fixed structure: what has been done, what is planned, are there blockers? The standup is not a status report for management, but a working meeting that surfaces problems early.

Interim reporting does not run through formal documents. A Teams message, verbal feedback, a summary of one page at most. Findings from sprint 1 are shared immediately, not saved for the final report. Condition: they are also acted upon immediately. Once a risk is known, the clock starts.

Sprint 1 closes with a sprint review: a one-hour conversation with the team, the auditee and possibly a management representative. The outcomes are presented, questions answered and the backlog adjusted based on what the sprint has delivered.

4.3 Sprint 2: deepening and interim reporting

Sprint 2 goes deeper into the topics identified as priorities in sprint 1. If the first sprint produced no noteworthy findings, the team takes up new backlog items. That choice follows from the revised backlog, not from a pre-established work programme.

The interim reporting in sprint 2 is more extensive than in sprint 1: a short written summary of findings to date, shared via Teams or email. Not a definitive document, but a working document enabling the auditee to prepare remedial actions.

The sprint review at the end of sprint 2 has one goal: jointly determining the scope of sprint 3. What deserves further attention? Have new risks become visible? That decision is not made by the auditor alone, but in consultation with the auditee and the CAE.

4.4 Sprint 3: deepening or additional topic, then the report

Sprint 3 is the most flexible sprint. Depending on what the first two sprints have delivered, two directions are possible.

If the first two sprints produced clear, substantive findings in a defined area, sprint 3 is used to go deeper on one specific topic. If the first two sprints provided a broader picture without one dominant finding, sprint 3 is used to test an additional topic.

The choice between both directions is part of the sprint 2 review and is explicitly documented. That is one of the most important characteristics of Agile audit: you consciously choose what you do and what you leave, based on current information.

The interim report at the end of sprint 3 forms the basis for the definitive report. That report contains no surprises: the auditee has been kept informed throughout the entire engagement.

4.5 The report

The final report of an Agile audit is shorter and more direct than its traditional equivalent. Background and context are limited, as that context has already been shared verbally. Findings are ordered by priority. Recommendations are targeted at a recipient who already knows them.

One specific feature: recommendations are preferably formulated as user stories, so they fit directly into the backlog of the relevant team. That delivers a usable handover from internal audit to the agile teams, rather than a report that disappears into a drawer.

5. The Kanban board as a management tool for the IAF

At the level of the individual audit, sprints provide structure. At the level of the audit function as a whole, Kanban answers the question: how do I maintain oversight of all ongoing, planned and potential audits?

Kanban originates from manufacturing. Toyota developed it within the Lean Production System⁴. The principle: make work visible on a board and consciously limit how much is in motion simultaneously. That prevents bottlenecks.

5.1 The columns of the audit board

A Kanban board for an audit function typically has six columns:

• Audit Universe. The backlog in its most comprehensive form: all potential audit topics the IAF has in view. Fed by risk analysis, signals from the board and audit committee, external regulation and own observation. The universe is never static.
• Selected. Topics to be taken up in the short or medium term. Typically three to six items, depending on the size of the IAF.
• In preparation. The audit has started. Risk analysis completed, scope defined, sprint planning for sprint 1 made.
• Fieldwork. The auditor is executing the sprints. The board shows which sprint the audit is in and when the next sprint review is scheduled. Audits remaining in this column longer than expected are a signal for the CAE to intervene.
• Review and reporting. Fieldwork is completed. In a well-functioning Agile IAF, this phase is short, because findings have already been shared during the engagement.
• Completed. The report has been finalised and shared with the engagement sponsor. The card remains as a reference for follow-up.

5.2 WIP limits: conscious constraint

The most powerful element of Kanban is the Work In Progress limit, not the board. That limit determines how many audits may simultaneously be in the same phase. An IAF of four FTE with five audits in fieldwork at once is not working in parallel. It is working chaotically. The WIP limit enforces completing one audit before starting the next.

In concrete terms: a maximum of two to three audits simultaneously in fieldwork, depending on capacity. Whoever wants more must first complete something. That feels uncomfortable for many CAEs. It is precisely the discipline that shortens lead times and raises quality.

5.3 The board as a conversation tool

The Kanban board is both a planning tool and a conversation tool. In the audit committee, it shows at a glance what is running, what has priority and what choices have been made. An item that remains in the universe for a long time without being taken up forces the question: is that deliberate? An audit that hangs in fieldwork longer than planned requires an explanation.

That level of transparency feels uncomfortable for some CAEs. Unjustifiably so. Those who make their work visible build trust.

6. The GIAS and Agile: two sides of the same coin

Most IAFs treat the GIAS as a compliance matter: what must we do to conform to the Standards? Understandable, but too narrow. Place the GIAS alongside the principles of Agile audit and something becomes apparent: the Standards operate within the same thinking framework as Agile audit, without ever using that word.

The performance domain requires the CAE to develop objectives and KPIs for the IAF and monitor their achievement. That is precisely what Agile-oriented audit functions already do through sprint reviews and retrospectives. The requirement that the IAF strategically aligns with organisational objectives was a recommendation in the old IPPF; in the GIAS it is a mandatory requirement. Agile audit is the method to keep that alignment dynamic.

The GIAS thereby provide a normative basis for Agile audit that was previously absent. CAEs who still need to convince their board or audit committee of an Agile transition now have a powerful argument: it is not an experiment, it is GIAS-conformant.

7. AI as an accelerator of the Agile audit cycle

Agile audit depends on speed. Sprints of two to four weeks are only feasible if the time investment in preparation, analysis and reporting decreases. Generative AI can make the difference on all three fronts⁵.

Per sprint phase, this looks as follows:

Sprint phase	What AI accelerates	What to watch for
Preparation	Summarising documentation, flagging inconsistencies and drafting an initial framework of focus areas based on the risk profile.	The framework is a starting point, not a risk analysis. The auditor determines the scope.
Analysis	Comparing datasets, flagging anomalies and linking information sources — also accessible to the generalist.	Treat an AI signal as a hypothesis, not as evidence. Substantiate every finding yourself.
Reporting	Generating an initial draft from notes and findings.	The auditor remains the author. AI delivers a draft, not a judgement.

But beware. AI increases the risk of false precision: output that looks reliable but is not. The auditor who deploys AI carries an additional obligation of critical professional judgement. The instrument only works if the user knows what to ask and where the boundaries lie.

8. Five lessons from practice

The examples below come from real situations in the Dutch market. Organisation names have been anonymised.

Example 1: The fear of missing something

A large hospital had just completed an external quality assessment (EQA) with a positive outcome. The audit team wanted to move forward: less comprehensive audits, more impact. The need was clear. The route was not.

After four workshops, the core issue became visible. The team was conditioned to be complete. Every risk covered, every finding substantiated, every conclusion accompanied by an exhaustive explanation. In a heavily regulated sector like healthcare, that disposition is understandable, but it is fundamentally incompatible with Agile working.

The tipping point came when a team member said aloud what everyone already felt: we dare not leave anything out. That formulation, which they soon called 'The Fear of Missing Things', opened a different conversation. Not about methods or templates, but about the professional identity of the auditor.

The practical consequence was a radical intervention in the way of reporting. 'The Art of Leaving Out', as the team called it, proved to be not a loss but an improvement for the recipient.

Key lesson: Agile audit does not begin with a tool or a method. It begins with the willingness to consciously choose: we do not need to be comprehensive.

Example 2: The political rhythm as audit rhythm

A medium-sized municipality with an audit function of three FTE had worked for years with a classic annual plan: ten to twelve audits per year, planned from a risk analysis established in September of the preceding year. Execution consistently fell behind. Audits arrived too late, findings had already been overtaken by council decisions. The CAE annually faced the thankless task of justifying delays to the audit committee.

The audit rhythm was completely out of step with the governance rhythm. The municipality worked in governance and budget cycles that bore no relation to the calendar of the audit department.

The fixed annual plan disappeared. In its place came a rolling quarterly plan. Every three months, the audit committee and the board jointly assessed priorities. The reporting format also changed: no more extensive reports, but audit briefs of two pages at most, focused on the decision before the council or executive board at that moment.

The effect was visible. The municipal secretary asked less frequently about the planning. Audit results were more often cited in committee meetings.

Key lesson: In political and governance environments, Agile audit is about timing. A good report at the wrong moment delivers nothing.

Example 3: Auditing a moving target

The introduction of the Future of Pensions Act (Wtp) forced pension funds into a far-reaching transformation⁶. Virtually all business processes, IT systems and communication structures required overhaul. The audit function posed the uncomfortable question: how do you audit something that is constantly changing shape?

The traditional approach — first understand the system, then test whether it works — was unworkable. By the time the audit was completed, the system had already gone through three iterations.

The solution lay in redefining the audit engagement. Not testing the system against its end state, but assessing the control over the change process itself. Does the fund have visibility of transition risks? Are decisions being made on the basis of adequate information? Is there a mechanism that surfaces errors early?

Every three-week sprint examined a specific component of the transformation programme. Feedback to programme management followed immediately via a short briefing and a Teams message. The audit committee received periodic briefings instead of a semi-annual report that was already outdated upon publication. The turning point came when a sprint feedback exposed an error that could still be corrected before execution.

Key lesson: In transformation audits, the object of examination is the change process, not the end result. Those who wait for the result are too late.

Example 4: Cyber does not respect the annual plan

A utilities company had cyber risks prominently on its audit calendar for years. Planning began in January, fieldwork took place in May, the report was delivered in September. By then, the threats in the report had already been replaced by new ones. The IT function was on top of the audit and already knew what needed to happen before the draft report was written. By the time the report was issued, most findings had already been remediated. Nobody was still waiting for that paper.

The cyber audit was converted into a recurring short-cycle programme: four times per year a targeted test on one specific aspect. The CISO became a standing conversation partner for prioritisation, with a clear agreement on independence. The CISO provided information on the threat landscape. The auditor determined what to examine and how to assess it.

The audit committee received four cybersecurity briefings per year based on current findings. The lead time per audit went from four months to six weeks.

Key lesson: Technical risks demand a technical tempo. A twelve-month audit cycle is structurally inadequate for cyber risks.

Example 5: Auditing an auditee that moves faster than you

A medium-sized retail chain worked fully Agile: product teams in two-week sprints, weekly IT releases, daily adjustments based on data. The audit function operated at the old pace. Audits lasted three months, reports landed after decisions had already been taken and recommendations addressed processes that had since gone through three iterations.

An auditor who approaches an Agile organisation with a waterfall method does not audit the organisation as it is. He audits an abstraction: how the organisation ought to work in a stable world.

Three team members attended Scrum training. Not to run Scrum themselves, but to understand how the organisation thought and worked. Audits were shortened to a maximum of four weeks. Feedback took place in the sprint review of the relevant team, not in a separate audit report. Recommendations were formulated as user stories, so they could be incorporated directly into the backlog.

That last step was the most impactful: findings formulated as user stories are acted upon sooner than findings presented as deficiencies.

Key lesson: When the auditee works faster than the auditor, the audit is not leading but following. The only answer: match your pace. Or lose your relevance.

9. Where do we stand now? An honest assessment

In practice, I see three patterns.

The first is cosmetic adoption. The terminology is Agile, the way of working is not. Sprints are another name for the planning phase and the backlog is a digital version of the annual plan. This pattern occurs most frequently and arises when a top-down decision is not accompanied by attention to culture and behaviour.

The second is selective adoption. Agile principles are applied to part of the audit activities, usually operational audits, while governance and compliance audits are conducted traditionally. A pragmatic choice that works, and for some audit functions the maximum achievable.

The third pattern is full integration: Agile thinking that has permeated the way of working at every level. From backlog construction to the formulation of recommendations and the dialogue with the audit committee. This pattern occurs least frequently, but is the most sustainable.

The GIAS provide a normative framework that supports the transition to this third pattern. The question for CAEs is not whether Agile is relevant. That question has been answered. The question is how deep you are willing to go.

Literature and sources

References

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. Published 9 January 2024, effective 9 January 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). Future of Pensions Act (Wet toekomst pensioenen). Staatsblad 2023. rijksoverheid.nl