SOX IT general controls: what external auditors actually test

IT general controls matter in a SOX audit because everything else depends on them. If an auditor cannot rely on the systems producing financial data, they cannot rely on the automated controls or the reports inside them — so an ITGC weakness does not stay contained, it propagates into the controls above it.

The three domains

Access to programs and data

The most heavily tested. Auditors look for: provisioning approved before access is granted; timely removal on departure; periodic user access reviews with evidence of the reviewer's decision; privileged access restricted and monitored; and segregation of duties enforced within financially relevant systems.

The recurring failure is developer access to production. It is often operationally necessary and almost never properly compensated — the control is not removing it entirely but restricting, logging and independently reviewing what was done with it.

Program change management

Changes to financially relevant systems must be authorised, tested and approved by someone other than the developer, with migration to production restricted. Auditors sample changes and work in both directions — from approved changes to deployments, and from deployment logs back to approvals. That reverse test is what finds changes that bypassed the process.

Computer operations

Job scheduling and failure handling, backup and recovery, and incident management for the systems in scope. Lighter than the other two, but restore evidence is requested and frequently missing.

Program development is sometimes treated as a fourth domain — relevant when a new financially significant system is implemented during the period, where the auditor examines data conversion and go-live approval.

Scope drives everything

Scope is set by which systems are financially relevant — the ERP, consolidation and reporting tools, and any system feeding material balances. It extends to the supporting layers: the database, operating system and, increasingly, the cloud platform and identity provider underneath.

That last point is where scope has shifted. If access to your financial system is governed by a cloud identity provider, that identity provider is in scope, and so are the administrators who can alter its configuration.

Deficiency escalation

ITGC findings are rated as a deficiency, a significant deficiency, or a material weakness. What drives escalation is not the technical severity but the potential impact on financial reporting combined with whether other controls compensate. A single access exception with strong detective review may stay a deficiency; the same exception with no compensating control, in a system producing material balances, can escalate.

This is why remediation should address the root cause rather than the instance. "We removed that user" closes an exception; "the access review now covers this system and has an owner" closes the deficiency.

Where testing fails

• Access reviews performed but not evidenced with the reviewer's decision per user.
• Leaver access removed late, discovered by reconciling HR terminations against active accounts.
• Emergency changes with no retrospective approval.
• Population completeness — a change list that cannot be shown to be complete.
• Privileged activity logged but never reviewed by anyone independent.

Key takeaways

• ITGC weaknesses propagate into the automated controls that depend on them.
• Scope now includes the cloud platform and identity provider beneath financial systems.
• Auditors test changes in both directions to find process bypasses.
• Remediate the root cause, not the individual exception.