What an ITGC audit actually tests, and why external auditors care

The reliance problem

An external auditor wants to rely on a system-generated report — an aged receivables listing, say. Before they can, they need to know that the system produced it correctly, that nobody could have altered the underlying data without authorisation, and that the program logic has not been changed without testing and approval.

Those assurances do not come from testing the report. They come from testing the general controls over the environment that produced it. If those controls fail, the auditor cannot rely on any system-generated evidence and has to fall back to substantive testing — which is slower, more expensive, and usually paid for by you.

The four domains

• Access to programs and data. Who can get in, what they can do once inside, and whether that access is authorised, reviewed and removed when it should be. This is where the majority of findings arise, and privileged access is where the majority of those concentrate.
• Program change management. Whether changes to the system are requested, approved, tested and migrated by different people, with evidence. The control that most often fails here is not the standard release process — it is the emergency change path, which is frequently used routinely and documented retrospectively, if at all.
• Program development and acquisition. Whether new systems and major changes go through governance, testing and authorised go-live, with data migration properly controlled and reconciled.
• Computer operations. Whether jobs run as scheduled and failures are detected, whether incidents are managed, whether backups run and restore, and whether the hosting environment is physically and environmentally controlled.

Design versus operating effectiveness

These are separate tests and both are necessary. A control can be well designed and never performed. It can also be diligently performed and useless — a monthly access review that only covers active employees will never find the contractor account that was left enabled.

Design testing asks whether the control, as specified, would address the risk. Operating effectiveness asks whether it actually happened, consistently, across the period. Testing operating effectiveness on a control with a design flaw wastes everyone's time, which is why design comes first.

Population completeness

This is the technical point that separates a defensible ITGC audit from a weak one. If you sample twenty-five changes from a list that management extracted for you, you have tested twenty-five changes from a list — not from the population. You have no basis to conclude anything about changes that never appeared on it.

A competent audit establishes population completeness independently: reconciling the change log to the production deployment record, or the user list to the directory service, before drawing any sample. Ask whoever performs your ITGC audit how they establish completeness. The answer is diagnostic.

Why deficiencies recur

The same ITGC deficiency appearing three years running almost always indicates that remediation addressed the instances rather than the cause. Twelve unauthorised changes were found; twelve were retrospectively approved; the emergency change process that permitted them was never redesigned.

Findings should be reported with root cause, and remediation should be assessed against the cause rather than the symptom. Otherwise you close the finding and meet it again next cycle.