IT general controls (ITGC), defined
Updated
IT general controls (ITGC) are the controls over the IT environment that financially relevant systems run on, conventionally grouped into four domains: access to programs and data, program changes, program development, and computer operations. Auditors rely on them to trust application controls and system-generated reports.
ITGCs do not process transactions themselves. Their job is environmental: they determine whether anything the systems produce — an automated calculation, an interface, a report — can be believed. That is why an ITGC failure is disproportionately expensive: it undermines every downstream control that depended on the affected system.
What IT general controls are
IT general controls are the controls over the environment in which financially relevant systems are developed, changed, operated, and accessed. They sit underneath application controls — the automated checks inside a system, like a three-way match or an input validation — and underneath every report those systems generate. The conventional grouping has four domains:
The phrase does not appear in the Sarbanes-Oxley Act itself. It comes from audit practice — PCAOB auditing standards and IT governance frameworks — as the standard way to organize IT risk in an audit of internal control over financial reporting, and the same territory shows up under other names in SOC 2 and ISO 27001 work.
- Access to programs and data: user provisioning and deprovisioning, privileged access, authentication, periodic access reviews, segregation of duties.
- Program changes: authorization, testing, and approval of changes to in-scope systems, with the change-maker separated from the approver.
- Program development: controls over new systems and major implementations, including data conversion and go-live approval.
- Computer operations: job scheduling and monitoring, incident handling, backup and recovery.
Why auditors rely on ITGCs — and what failures cost
Auditors rely on ITGCs indirectly. An automated application control only needs to be tested once — rather than across hundreds of samples — if change controls give assurance that its logic stayed the same all period. A system-generated report is accepted as evidence because access and change controls preserve the integrity of the data and the report logic behind it. ITGCs are the reason a single test can cover a whole period.
When an ITGC fails, that reasoning collapses for the affected system and period. The auditor can no longer assume the automated control operated consistently or that reports are complete and accurate, so the response is to test more: extended testing of application controls, revalidation of each report every time it is used, and expanded substantive testing of the underlying transactions. All of that work is manual and sample-heavy, which is why ITGC deficiencies drive audit cost even when no misstatement is ever found. Severe or aggregated ITGC deficiencies can also rise to a significant deficiency or material weakness in their own right.
Common ITGC deficiencies
Most ITGC findings are not exotic. They are ordinary process gaps that recur because the evidence is scattered across systems and quarters:
| Domain | What it covers | Common deficiencies |
|---|---|---|
| Access to programs and data | Provisioning, deprovisioning, privileged access, access reviews | Terminated users retaining access; shared or generic admin accounts; access reviews performed but not evidenced. |
| Program changes | Authorization, testing, and approval of changes | Developers deploying their own changes to production; emergency changes never retrospectively approved; approvals with no record. |
| Program development | New systems, major implementations, data conversion | Migrated data never reconciled to source; go-live without documented testing or approval. |
| Computer operations | Job scheduling, monitoring, incident handling, backup and recovery | Failed jobs not investigated; backups never tested for restorability; alerts routed to nobody. |
Evidencing ITGCs across a period
ITGC evidence has to cover the whole period, not a moment. A screenshot proves what a setting looked like on one day; the auditor's question is what happened across the quarter — every joiner, leaver, change, and failed job. Programs that collect evidence by hand end up re-pulling user lists, change tickets, and job logs every quarter, and the linkage between an artifact and the period it covers is the first thing that breaks.
What good looks like is evidence pulled directly from the systems that produce it — identity providers, source-control and CI systems, cloud platforms, and observability tools — rather than re-keyed by hand, with each artifact tied to the period it covers. Strong programs preserve a tamper-evident, append-only trail with clear chain-of-custody, re-verify on a schedule instead of once at quarter-end, and require a named human to accept each piece of evidence before a control counts as met. When evaluating any tool for this, the tests that matter are whether it reads from source systems without write access, whether it can demonstrate population completeness across the whole period, and whether it reports gaps honestly rather than estimating them away. Whatever the tooling, the audit opinion remains the auditor's — internal readiness work only prepares management's side.
Frequently asked questions
What are the four ITGC domains?
Access to programs and data, program changes, program development, and computer operations. The grouping comes from audit practice rather than statute; some firms present variations, but nearly all ITGC work sorts into these four areas.
What is the difference between ITGCs and application controls?
Application controls are automated checks inside a specific system — an edit check, a tolerance limit, an automated match. ITGCs are the controls over the environment those systems live in: who can access them, how they change, and how they operate. Application controls can only be relied on when the ITGCs beneath them are effective.
Are ITGCs only relevant for SOX?
No. SOX is where the term is most formalized, because ITGC effectiveness determines how the ICFR audit is scoped. But SOC 2, ISO 27001, and most security frameworks cover the same territory — access management, change management, and operations — under their own control language, which is why evidence collected for one framework usually maps to the others.
What happens when an auditor finds an ITGC deficiency?
The deficiency is evaluated for severity — deficiency, significant deficiency, or material weakness — both individually and in aggregate with others. Separately, the auditor adjusts reliance: automated controls and system reports from the affected system may need direct testing or revalidation, which expands substantive work for the period.
How are ITGCs tested?
Through a mix of inquiry, observation, inspection of evidence, and reperformance, sampled across the period. Access controls are typically tested against population lists of joiners and leavers, change controls against a complete change population, and operations controls against job schedules and incident records — which is why complete, traceable populations matter as much as the controls themselves.
Published by ShipReady Metrics, an evidence-based technology and compliance intelligence platform. This guide is educational and vendor-neutral.