Controlling access to data within the audit team – open or closed? (DGIA #2)Feb 02, 2020
This article is about control over access to data within the audit function, to help guide the decision regarding which of these two options would be appropriate:
- Open access: The entire audit team is granted access to data collected by the team, across audits (with specific exceptions as necessary).
- Closed access: Specific audit team members are allowed access to data that is relevant to the audit they are working on and, conversely, anybody that is not involved in the specific audit is not granted access.
The core issue – do you or don’t you segregate access?
The decision regarding who to grant data access to is usually based on need.
That is, whoever needs to use the data will be given access to it.
If the need has not yet been identified, then access is restricted.
These sorts of restrictions have been discussed previously, in the article “More access to data to reduce risk and enhance business decisions”.
Access to data, for audit purposes, will typically not include the ability to make changes to the systems from which that data is collected.
The risk that unauthorised changes are made, deliberately or in error, is the key reason for user access controls having been introduced and then strengthened over the past few decades.
If a need has not yet been identified, this doesn’t mean that there is no legitimate reason for granting access.
Reusing existing data for other audits can provide a range of benefits. Among these are improving results, identifying other risks and minimising exceptions. Reuse also enables auditors to reduce the duplication of work.
Limiting access, then, can result in a decrease in value, which increases risk.
Implementing the restrictions
There is cost associated with putting restrictions in place – this includes:
- determining what the access model will be (who gets access, who doesn’t, etc.).
- signing off on the access model
- implementing the restrictions broadly (e.g., where data is stored)
- implementing the restrictions on each audit (audit team members up-front, then sometimes there are changes as the audit progresses)
- monitoring the restrictions
- determining how to share data between audits (e.g. cleansing data before passing it on to another audit team, etc.).
The effort that is associated with these steps and controls can be non-trivial.
What does this mean?
There are disadvantages associated with restricting access – reduced potential for innovation, reduced reuse of work across audits, increase in effort to implement the restrictions.
So, in general, data used within audits should be made available to the entire audit team.
However, there are some exceptions to this, some based on organizational factors and others based on audit team-related considerations. Let’s explore those.
Some specific exceptions, based on organizational factors
- Cross-border concerns. This is relevant to audit functions within multi-national organisations and to audit teams that outsource audit work to offshore processing centres. This only becomes a valid case for exception If the data itself is classified as sensitive and cross-border transfer is a real risk.
Remember, offshore processing centres are not always linked to offshore data centres; quite often, the data and systems remain onshore and are accessed remotely.
- Strict organizational data governance regimes. If there is a very strict DG regime in place across the organization more broadly, you may decide to follow this. However, be careful with this because if it limits your ability to provide a strong third line, then it can be seen as an impairment to independence.
For example, John (an auditor) is obliged to follow the strict DG regime. Melissa (an auditor on a different project) can't access data that John collected. John's data could have been used to strengthen the quality of Melissa's audit. Now ordinarily Melissa would be able to request that data, if she knew the value in it. But this is an unknown to her, because following the strict DG regime means that there is limited sharing of such detailed knowledge amongst the team. Has independence been inadvertently impaired?
- Highly sensitive data. Where all of, or most of, the organization’s data is (correctly) classified as highly sensitive. There aren’t too many of these sorts of organizations – this typically happens with singularly focused entities.
- The need to maintain Chinese walls, for audit functions that regularly provide consulting or advisory services. Again, here, the risk needs to be clearly articulated.
As an example, if a member of the audit team was seconded to a business unit, they wouldn't usually be directly involved in related audits for some time; but does that mean that they should not have access to the data used for those audits?
- Very large audit teams (e.g., more than ~100 FTE) – arguably the smallest of these factors. There are some situations in which larger teams opt to exert higher levels of control. Be careful with this, because it could point to poor culture - these sorts of measures are often put in place to overcome suboptimal management practices.
Considerations relevant to the audit team and/or individual audits
- Where specific data is sensitive. This could be due to privacy or regulatory compliance expectations, or for protection of competitive intelligence. And there is a real need to maintain confidentiality.
Restrictions can be put in place for the sensitive data specifically. It is easier and more cost-effective to ringfence (by exception) and control those datasets specifically, while allowing open access generally.
- If there is risk that data will be altered. Change permissions to read-only so that data from one audit file needs to be copied to the new audit’s file before it can be changed to suit the new audit’s objectives. This should be the case for any source data anyway.
- Vulnerability. If there is heightened security/cyber risk because of the access to data that the broader team has, consider how this can be mitigated without removing access.
As auditors, we typically adopt risk-based approaches to the audits that we conduct, and we recommend risk-based approaches to management.
It is clear then, except for certain circumstances, that we should be making data available freely across our audit teams, with specific exceptions for highly sensitive data.
If we adopt a risk-based approach, the first option (“open access”) will usually make sense.