Understanding ITGC Testing: A Complete Guide

If a financial application automatically calculates a balance, restricts who can post a journal entry, or feeds a number straight into the general ledger, an auditor's ability to rely on that automation depends on the IT General Controls (ITGCs) surrounding it. Get ITGCs wrong and you don't just have one deficient control, you potentially lose the ability to rely on every automated control downstream of it.

The four ITGC domains

Most SOX programs organize ITGCs into four areas. The specific control language varies by company, but the categories are consistent across frameworks like COSO and COBIT:

• Access to Programs and Data — who can get into a system, how access is provisioned, reviewed, and removed, and whether privileged access is appropriately restricted.
• Program Changes (Change Management) — how changes to applications and infrastructure are requested, tested, approved, and deployed.
• Program Development — how new systems or major functionality are designed, tested, and implemented before go-live.
• Computer Operations — how batch jobs, backups, and job scheduling are monitored, and how incidents are identified and resolved.

What auditors actually look at

ITGC testing is evidence-heavy: user access listings, approval tickets, deployment logs, job schedules, backup logs, and incident tickets. The population itself matters as much as the sample, if the list of changes or the list of user accounts isn't complete, everything sampled from it is suspect.

Where ITGC testing commonly breaks down

• Incomplete populations — a change log or access list that's missing entries, often because it was pulled from the wrong system or the wrong date range.
• Evidence that doesn't actually demonstrate the control — an approval email that doesn't specify what was approved, or a ticket status of "Closed" used as a stand-in for "Approved."
• Segregation of duties gaps — a developer who can both write and deploy code without an independent reviewer in the path.
• Timing mismatches — testing evidence dated after the control was supposed to operate, which doesn't demonstrate the control operated when it should have.

Why this is a natural fit for automation

ITGC evidence is voluminous and repetitive in structure, exactly the kind of work where consistent, rule-based testing outperforms manual review: the same attribute, tested the same way, across a full population instead of a sample, with every conclusion traceable back to the underlying ticket or log entry. Audagic currently supports change management and access review testing, with more ITGC domains on the way.