What ITGCs actually protect
On too many engagements, ITGC testing is a tick box exercise. The team requests a user access listing, confirms that segregation of duties looks reasonable, checks a box, and moves on. ISA 315.26 (a) requires something different: identifying the ITGCs that are actually relevant to the audit because the client uses IT in financial reporting. These aren't controls over individual transactions. They're the controls that keep the IT environment itself reliable.
ISA 315 .A148 organises ITGCs into four categories: access to programs and data, program changes, program development, and computer operations. ITGCs exist to support application controls. When ITGCs fail, every automated control that depends on them becomes unreliable, no matter how well that application control is designed. A three-way match in the purchasing system means nothing if an unauthorised user can modify the matching parameters.
Teams don't test ITGCs for their own sake. You test them because they underpin every automated control and every system-generated report the audit relies on. If you plan to use a system-generated aged receivables listing as audit evidence, you need confidence that the system producing it operates in a controlled environment. In our experience, this connection between ITGC reliance and the specific reports you're using as evidence is where most files fall short.
Key Points
- ITGCs support application controls. If ITGCs fail, no automated control that depends on them is reliable.
- ISA 315 .A148 groups ITGCs into four categories (access security, change management, program development, and computer operations).
- Testing ITGCs is not optional when you plan to rely on automated controls or system-generated reports.
- A deficient ITGC has downstream effects on every account processed by the affected system.
Where files fail on ITGCs
The FRC has repeatedly found that engagement teams test ITGCs but don't document how deficiencies affect planned reliance on application controls. The test gets performed. The result gets recorded. But the file doesn't show the link between an access control weakness and the decision to expand sub testing on affected accounts. It's the kind of gap that feels minor until the monitoring visit, and then it's the first thing the inspector pulls.
A second common gap: scope. Teams test only access controls and ignore change management entirely. Just SALY the access testing from PY and move on. ISA 315 .A149 lists change management as a distinct ITGC category. If the client deployed a system update mid-year that altered how revenue is calculated, and the team didn't evaluate the change management process, the audit evidence on revenue post-update is incomplete. Nobody wants to be the person who signed off on revenue when the ERP calculation changed in June and nobody looked at the change ticket.
ISA 315 .A154 requires you to evaluate the downstream effect of ITGC deficiencies. That means tracing the deficiency forward: which application controls depend on the affected ITGC, which FS assertions depend on those application controls, what residual risk remains after you expand sub testing, and whether the expanded testing actually addresses the gap. Four links in that chain. Most files document two of them.
Standard references that matter
ISA 315.26 (a) requires identification of ITGCs relevant to the audit. ISA 315 .A148 defines the four ITGC categories, while A150 connects ITGCs to audit relevance and planned reliance. When ITGCs are deficient, ISA 315 .A154 requires you to evaluate the downstream impact on every account processed by the affected system.
Related terms
Related reading
Frequently asked questions
What are the main ITGC categories?
ISA 315.A148 groups ITGCs into: access to programs and data, program changes, program development, and computer operations. Most firms test access security and change management as the minimum.
What happens if ITGCs are deficient?
If ITGCs fail, no automated application control that depends on them is reliable. ISA 315.A154 requires you to evaluate the downstream effect and expand substantive testing on every affected account.