This article sets out 3 key principles for Data Governance within audit.
A core set of guidelines that we, as audit professionals, can check ourselves against in planning for and using data.
This is the third article in the series.
The first article outlined why the use of data within the IA team (e.g., for audits) should be specifically, and differently, governed. We’ll explore this again in the Background section below.
The second article provided a point of view about keeping access to data – that is collected or used by the audit team – open to the whole audit team, where appropriate.
In this third article, we will take a small step back and lay some of the key principles out.
Why we need to specifically govern data within audit
Governance of data within audit is not a new concept at all.
But with the increasing use of data within audits, there is a growing need to consider different approaches and solidify our thinking about this.
The way in which data and analytics needs to be governed within audit is a bit different to mainstream (read, first and second line) approaches.
This is because of the way in which audit teams use data.
As an example, consider some of the differences here:
|Data is…||1st / 2nd line||Audit||Impact|
|Captured and processed||Yes||No||Different types of access controls – i.e., not the typical ERP access thinking|
|Combined (different domains)||Sometimes||Often||Combined data may be more sensitive|
|Used to identify internal fraud||Limited to some team members||Across the team||Heightened sensitivity, affecting the entire function|
What this means is that we need to think differently. Not with a consistently stricter set of controls, but with the right set of controls that are designed for the unique requirements of an audit function or audit team.
In some cases, for example the way that we classify data, we may need a higher level of sensitivity.
In other cases, for example user access within the audit team, we may need a more open approach.
The principles, then, can help us focus our thinking.
These three principles, and the associated guidance, are designed to provide a starting point.
A common set of expectations that can be applied across our teams and our audits.
Principle 1: Security – maintain risk-adjusted safeguards
In this previous article – we advocated for open access to data – that is, granting access to the entire audit team, not only those team members that were involved in the particular audit for which data was used.
In that article, we indirectly outlined a link between opening access up to the broader team and the Independence principle (“Is objective and free from undue influence”).
Now opening access up, with a few restrictions, will be typical. The approach that most teams will take.
But first you need to make an informed, defensible decision regarding what your approach will be.
That is, whether you will open access up completely (the whole audit team), restrict access to only the individuals involved in the audit, or open access up with a few restrictions.
So you could follow these five steps, as a guide:
Determine what the organizational security, classification and confidentiality expectations are.
Check whether the classifications cover audit scenarios.
Is there audit data that is more sensitive than the existing classifications?
Do you need to be explicit about certain types of audit data?
(e.g., when there is suspicion of fraud, pre-approval by the audit committee of the classification of such data would be prudent).
Consider the eight exceptions listed in this article (or perhaps others), and what you will need to do if any of them apply to you.
Assuming that you have decided to open access up, determine whether you need to ring-fence certain types of datasets.
Determine how you will implement the access privileges.
Pay particular attention to making source data read-only for everyone, and audit files read-only for anyone not involved in the audit, if this has not already been done.
Seek approval (e.g., an exemption) if your approach is going to differ from the organizational expectation – noting that this is usually a courtesy request.
Then implement the approach.
Principles 2 and 3 below look more like groupings of principles than individual items themselves.
This is deliberate. We find it easier to think about them together and the individual items as sub-principles. You may prefer to separate them out for your use.
Principle 2: Quality – audience, objective, QA
This principle includes:
- Understanding the audience (e.g., audit committee members) and meeting their needs.
- Focusing on the audit objective (e.g., outlining relevant hypotheses).
- Ensuring quality, in various layers (i.e., audit QA, business QA, technical QA).
Principle 3: Benefit maximization – share lessons, identify other risks, Continuous Improvement
This principle includes:
- Sharing lessons (functional and technical) amongst the audit team.
- Identifying other risks and opportunities (e.g., by using data/outcomes from other audits).
- Continuous Improvement.
Does your team apply a set of principles in governing your use of data?
 You could argue that this will differ between 1st and 2nd line, but this article focuses on audit, so these have been combined.
 Except perhaps for particular types of data/information, such as audit reports and audit findings, issue closure, etc. But that is a separate topic.