Audits and assurance. What’s the difference?

What is the difference between an “audit” and “assurance?

I was recently asked, “What is the difference between an “audit” and “assurance”? I like simple questions like this as they can tease out a lot of hidden meanings and misunderstandings. These two words are used frequently and in many different contexts; most of the time people understand what is meant . . . but not always. It is only when the question is asked, that you have to put your brain in gear and start thinking.5-going-ok

As project management has grown as a discipline, a lot of organizations have come up with their own definitions or uses of these words, which were already in use in other disciplines. The terms are often qualified such as:

  • Business assurance – checking the project is viable in business terms
  • Technical assurance – checking the solution is the right on and will work
  • User assurance – checking users get what they need.
  • Quality assurance – ensuring standards and procedures are used
  • Configuration audit – keeping track on all the bits of the solution
  • Financial audit – checking the financial figures reflect reality

You also find the word “review” is often tacked on to “assurance”, hence “assurance reviews”, which can add whole new dimension.

What do the words mean?

It is always a good idea to use words which have a commonly understood meaning, as it makes communication and understanding so much easier. Most people don’t have the time or inclination to understand jargon and nuances which are used to make academic distinctions. Dictionaries are the guardians for this and so, do use them; here are some dictionary definitions of the words:

  • Audit: 1) an official examination of accounts 2) A systematic review or assessment of something.
  • Review: a formal assessment of something with the intention of instituting change if necessary
  • Assurance: positive declaration that a thing is true.

“Audit”, being associated with financial accounts and independent auditors, has an “official” connotation; audits are usually planned, formally undertaken events. In the case of financial audits there are very strict rules on how they are conducted. People are often very wary when told the auditors want to see them; they often think in terms of “passing an audit”. Personally, I have found in healthy companies people welcome audits as it gives them a chance to raise issues which they have found intractable.

“Review”, on the other hand can have a softer meaning, more “helpful” meaning and can imply less formality, although this is not always the case. PMOs often use “review” so as not to scare people! This is how accountants use the terms:

  • Audit — an intensive examination with the highest level of assurance.
  • Review — some analytical procedures conducted with limited assurance

“Assurance” is different, you can have an “audit” or a “review” but you do not have “an assurance”. It is more of a state; you are assured that your project will meet its business objectives. Audits and reviews are simply two forms of assurance related activity.

Where does risk fit into this?

The terms “risk” and “audit” are often linked; Risk based internal audit (RBIA) is an internal method which is primarily focused on the inherent risk involved in the activities or system and provides assurance that risk is being managed, by the management team, within the defined risk appetite level. It has had a very high profile since the collapse of companies like Enron and the introduction of Sarbanes Oxley in the USA. In this connection, you’ll probably come across what is often termed “three lines of defence”:

  • 1st line: business operations, who own and manage risks; risk and control in the business, ensuring the identification and treatment of risk is built into standard management practices.
  • 2nd line: oversight functions, who design policies, set direction, introduce best practice and ensure compliance to ensure the whole management effort works as an integrated whole.
  • 3rd line: independent assurance providers such as internal audit and external assurance providers.

So what can you do in practice?

So what does this all mean for you in a programme and project management context? As always, it depends. You are likely to have this problem if you are responsible for a company-wide programme and project method or if you are responsible for a major programme. If you are a programme o project sponsor then “assurance” is a key aspect of your role. You will be the one asking for audits and reviews . . . although your senior management may also call for them.

In a company context, check how the terms are already used; make contact with the internal audit department and the risk group and work with them. In a programme context, decide how much you want the programme to be driving audits and reviews and how much should be driven externally, always remembering that at a programme level, you’ll need to fill any gaps in corporate capabilities. If there is no corporate audit or review capabilities, the programme team will have to design everything, except the 3rd line of defence assurance, themselves.

 

Case study

Here is how I approached it in one major company:

The programme and project management method included roles definitions which included assurance and risk management accountabilities. There were three supporting procedures relating to these:

  1. a single risk management procedure for use at any level in the programme from work package upwards.
  2. A procedure for auditing a programme or project;
  3. A procedure for reviewing a programme or project;

The programme and project management risk procedure dovetailed into the corporate risk management process, using the same terms and activities (based on ISO 31000). This ensured ease of transfer of risks across boundaries and simpler tools support.

The audit procedure was based on group internal audit’s formal auditing process. This was only used on major programmes which had their own quality and assurance departments. By mirroring group internal audit’s approach we ensured that the method could not be challenged, ensuring that the findings and recommendations were the focus.

The review process was designed to be used by programme and project management practitioners, not directly involved in the work, to review the work of others, based on a brief given by the sponsor. It was simpler and quicker than an audit as it took a less formal approach and was supported by (but not limited to) check-lists and tools.