Having recently used an agile (with a small "a") approach to deliver a risk analytics project to a large customer, I have been thinking about how such an approach could be used by Internal Audit functions.
This is not a new concept, others have produced frameworks for such approaches within IA, but IA functions continue to lag significantly behind other functions (Finance, Marketing, IT, etc.) in this regard.
How often have we decided to undertake active audits in phases, defining the specific number of phases upfront, and then wondering how we go to that number? I faced that challenge again recently, and the IA team (that I was helping with the active audit) are now considering whether this upfront decision is necessary - if the project is iterative, why can't we be?
Let's start by looking at an area that consumes roughly half of our effort (and cost). Traditional IA methodologies are laden with documentation requirements:
The norm: detailed audit risk assessments, risk and control matrices, planning papers, agendas and minutes, working papers, observation logs, various versions of draft reports, etc.
A bit heavier: forms to capture what audit staff would like to achieve from the audit, post project evaluation forms.
And more: organisation specific methodologies, with time spent on making sure that they align with specific standards. I have had a few people mention that they engage external consultants to help with these, as recently as this year!
All captured in audit working paper systems/tools - some of which take a long time to implement, configure and then use on individual audits.
Do we need these? Do our customers care? Does anybody care?
No, they have no idea how well documented the working papers are, and may be pretty unimpressed if they did find out how much time is spent on templating and formatting and revision and review. In some cases, the specific bits that outline the background to findings, with some level of detail, will be important.
The audit committee:
Traditional: you're stuck, keep wasting money on documentation, or try to educate perhaps.
Contemporary and forward thinking: looking for value, still expecting rigour and a level of formality, but not to the extent that it diminishes the ability to add value.
If reliance is being placed on a piece of work, then they will follow ISA610/ASA610/equivalent. Reliance is usually placed on those audits that are directly related to financials. In the old days (with fixed audit plans) that worked. Nowadays, IA plans change, don't cover the same area every year, etc. The reliance areas should be limited, so reliance by the external auditors isn't a reason to over-document elsewhere.
Are expected to reduce the compliance costs imposed on business and other regulated entities. Will care that positive assurance can be backed up appropriately.
Businesses are turning to more efficient (e.g. lean), faster and more effective (e.g. agile) ways of working. In Australia and elsewhere, this is starting to happen within IA, but not at the same pace as other functions.
In part 2 (of x), I will outline our experience with the (small "a") agile approach, how this enabled us to produce a result that we didn't anticipate and that significantly exceeded expectations, and then some thoughts on relevance to IA methodologies.
This article is part of the assurance analytics series.