Understanding the use of IT can create headaches for group and component auditors. Andrew Paul considers some practical issues and ways to address them.
Groups may be organised in various ways and so may the information technology (IT) that is used by a group and its components. Structures and complexity can vary widely. Some businesses centralise their IT systems, others take a more decentralised approach. Levels of integration and connectivity between IT systems can differ, as can use of internal and external resources and service providers, and how technologies are combined.
Whichever approach is taken, there can be potential headaches for the auditor of any one component in a group, or the auditor of the group itself, in understanding and testing IT systems that are remote from the audited entity.
This article considers some of the practicalities faced by group and component auditors in understanding such IT use and the risks this may pose. Those involved in the audit of groups and components also need to consider what’s required by the revised group auditing standards, ISA 600 and/or ISA (UK) 600 (effective for audits of financial statements for periods commencing on or after 15 December 2023), and by the revised risk standards, ISA 315 and/or ISA (UK) 315 (effective for audits for periods commencing on or after 15 December 2021), and may benefit from exploring the related Audit and Assurance Faculty resources listed at the end of this article.
Component auditors
Let’s start by thinking about the component auditor.
In my experience, a common response to a component auditor’s enquiry about group IT systems is either “I don’t know, that’s all dealt with by our central IT team” or, even worse, “You don’t need to worry about that, it’s all dealt with centrally”.
Neither of these responses is acceptable and certainly should not be the end of such a discussion.
If the role of the component auditor is simply to audit the component as directed by the group auditor (not issuing an opinion on the component itself, but just providing evidence to the group auditor as part of their opinion on the group financial statements), there is an argument that the component auditor may not need to know all the details of the IT systems in use.
While this may be true, the component auditor will still need an understanding of the IT systems that impact the areas they have been asked to test. Otherwise, how will they know how to carry out that test effectively? As they will certainly need information from the IT systems to carry out the test, they will need to know what systems are in place and how things are set up.
If the component auditor is just doing the work directed by the group auditors, the instructions and briefing they receive should include sufficient detail for the component auditor to be able to understand the group IT systems that will impact their testing. If the instructions do not include this information, the component auditor needs to ask for this.
The revised group auditing standards ISA 600 and ISA (UK) 600 both make clear that component auditors are part of the group audit engagement team. So, the component auditor should be part of planning discussions and actively interacting with the group auditor, not just on the receiving end of a missive telling them what to do.
If the component auditor’s role is broader and they are issuing an opinion on the financial statements of the individual component, as well as reporting back to the group auditor, then the component auditor should treat the assignment as they would any other audit. This means that they will need to obtain a full understanding of the systems and controls in place, including all IT systems that touch the component.
The component auditor should be actively interacting with the group auditor, not just on the receiving end of a missive saying what to do
It may be possible to leverage documentation prepared at the group level, so that the component auditor does not have to recreate everything from scratch, but it must be remembered that the audit is of the component. Simply copying and pasting information on the group policies, procedures and systems onto the component’s audit file will not be appropriate.
For example, documentation on accounting systems needs to be clear on how the component’s transactions get into such systems, how much influence the component’s management has over accounting treatments, policies and so on, and not merely document what happens at the central processing stage.
A question often asked by component audit teams is: “If procedure ‘x’ is being done centrally, do we have to test it or can we rely on it being tested at the group level?”
As with a great many auditing questions, the answer is: it depends!
When considering tests of controls, a centralised procedure may well mean that component auditors can rely on some element of the testing done by others. The work would have to meet the needs of the component auditor in terms of controls tested and risks assessed. However, it is unlikely that a centralised control test will achieve all the control objectives. In particular, the controls over getting the information to and from the central team need to be looked at from the component’s side. This is not something a centralised procedure will necessarily cover.
For substantive testing, centralised testing may not be carried out or, if it is, it is unlikely that a sufficient sample of the component’s transactions has been selected to give the assurance the component auditor requires. Therefore, there will most likely be a need to undertake substantive testing at the component level.
Group auditor
The group auditor needs to know everything about the group IT systems and structure. Just as a component auditor cannot leave it to the group, the group auditor cannot leave it to a component or components.
Let’s consider an example, where the group IT sits in one component, which is a shared services company servicing all of the group. If the group auditor is not the auditor of the shared services company, they still need to understand everything that is happening there, as the operations impact the whole group on which they are reporting. Simply getting a clean audit opinion from auditors of the shared services company is not sufficient.
Just as a component auditor cannot leave it to the group, the group auditor cannot leave it to a component or components
The revised group auditing standards, ISA 600 and ISA (UK) 600 are clearer than ever that the group auditor needs to gather sufficient appropriate audit evidence to support the group audit opinion and that this means directing, supervising and reviewing the whole audit team, including component auditors.
The group auditor must also follow the requirements of the revised ISA 315/ISA (UK) 315 to understand the system of internal control for the whole group and this includes the IT systems.
The group auditor is in a unique position to gain an understanding of IT across the entire group. It is helpful to component auditors if the group auditor collates as much information as possible about the IT systems so that this can be disseminated to component auditors as required. As this information is needed by the group auditor anyway, why not compile it in a way that also helps to streamline work for others in the audit structure?
Wherever an auditor sits in the group structure, it is essential that they understand the breadth of IT systems across the group and the specifics of how IT impacts their particular audit approach and their audit opinion.
Andrew Paul, Audit Software and Technical Manager, Baker Tilly International
Additional ICAEW resources
