Just because you can doesn’t mean you should.

Joshua G
What I think About IA
5 min readMar 9, 2021

Wise words from Dr Ian Malcom of Jurassic Park on scoping an audit.

Our time is precious, we are trained professionals with a mandate to try and increase the chance of success and reduce the probability of disaster.

To best use our time and expertise the world class audit team needs to be like a special forces team. The Navy Seals don’t start on the frontlines of a battle and destroy every single enemy between home and their objective. They infiltrate behind enemy lines achieve their objective and then return home to plan for the next objective. Even more critical is ensuring the best use of the time of those actually on the front lines in the organisation.

Audit is often guilty of trying to achieve a special forces mission using a conventional warfare strategy. We think of everything that could go wrong from beginning to end then beaver away at a seven week project to amass mountains of evidence to prove to the nth degree that nothing could ever go wrong. Sometimes we even know what the outcome of the project is going to be before we even start.

Whenever something is being put into the scope an audit we should stop and think.

  • What would I tell the CEO if this control was fundamentally flawed and not operational?
  • Would the Board care if I told them that this risk was not managed?

If we can't imagine ever communicating a failure in a control we have in scope to the board is it really worth our time? Why test that process xyz was followed if you wouldn’t end up writing anything in a report about it? Why add this control into the scope of your audit if your objective is really to provide assurance in a totally unrelated risk area?

I have often seen instances where teams are told ‘Just put x in your scope as well, you may as well test it as it won’t take too much time’ or ‘Lets put in x that will be a nice easy thing for the junior to test’. Our carefully planned and targeted “Risk based” audit plan starts to become a grab bag of useful stuff mixed whatever risks that look easy to audit. Norman Marks (The OG of auditing what matters) also talks about auditors with favourite topics, its something that many of us have succumbed to or seen others do. You go on a course about something, or you find a significant issue in one area and then wherever you go you are looking to show off your knowledge or chasing the dragon of that great finding you found elsewhere. All of a sudden every assignment includes your favourite risk area irrespective of the actual relevance for the business.

Another common source of lack of focus is the use of generic work programmes. Teams will take a work programme used in another organisation or published by an external standards body and adopt it fully.

For example:

You are doing an audit of an ERP system go-live to make sure everything is ready for the business to be successful with the new system. You download a system introduction audit programme and it has a section looking at the strategic alignment and system selection process. Whilst this is a valid area of concern how much use is it going to be to assess this when we are just about to go live? Will you expect the business to throw away the 14 months of work to build the new system because there was an issue with the RFP?

Maybe there is merit because you are concerned that the process isn’t sufficiently robust and future projects may suffer, but maybe you already know the vendor selection was robust and aligned to the organisations strategy. Is it still worth documenting risks, controls & evidence to prove this?

Issues with kitchen sink auditing

I see a number of issues with some of the reasons above that we add scope areas to audits without clear linkages to important risks.

a) The Planning Fallacy. This is the phenomenon where planners show an optimism bias and underestimate the time it takes to complete a task. This can often arise in audits where the planners are sometime not those doing the work and where even the most basic item can be easily delayed if there are issues obtaining the required information.

b) Areas that are actually minor or irrelevant are prime candidates for disagreements with management. Say you do have a finding in an irrelevant area and try and include it as a reportable item. What follows can be a waste large amounts of time in ‘philosophical’ discussions between audit and management on the merit of the finding.

c) It is much easier to leave something out of scope at the beginning than remove it midway through. If we add something to our scope that we later realise is irrelevant or unnecessary, it can be difficult for teams to have the bravery to throw away the wasted effort. IIA standards also require approvals for changes to work programmes, potentially adding a further layer of bureaucracy to this. It is much better to properly target our scope at the outset and go after the risks that really ‘matter’.

Don’t Do this

Three things to think about when building an audit scope and work programme

  1. What are the RELEVANT risks when considering the objective of your audit. If the objective is “Do an audit of area x because we haven’t done one in a while” you need to have a look at your audit planning process.
  2. What are the KEY controls that are critical to managing the risk.What would I tell management if this control failed? Would I be able to convince them that they should spend money to add a new control or change this one?
  3. Leave the rest! Look at your work as 1 big product roadmap. Increasing scope in one project to make the scope feel “big” enough ignores opportunity cost. Every day you spend auditing area x is one less you can spend auditing area y. No way you should get to the end of a period and say “oh I really wish we got enough time to look at xyz. It’s a shame we spent too much time running around making sure Sven was keeping track of the petty cash and Nigel didn’t expense claim for more than one alcoholic beverage on his hotel bill.”

Be brave and focus on what matters, your customers will thank you for it.

--

--