SOX ITGC: The 4 Essential IT General Control Domains (2026)

Last updated 19 September 2026

SOX ITGC — the IT general controls in a Sarbanes-Oxley programme — are the controls over the systems that process, store and report financial data, and they matter because every automated application control and every system-generated report an auditor relies on is only as good as the general controls beneath it. PCAOB Auditing Standard 2201 names the categories directly: in its benchmarking paragraphs it refers to general controls over program changes, access to programs, and computer operations, and to controls over application and system software acquisition and maintenance — the four domains that every SOX programme organises its IT testing around: access to programs and data, program changes, program development and acquisition, and computer operations.

AS 2201 also lists reliance on IT general controls as a factor in the risk associated with a control, which is why an ITGC failure can escalate into a deficiency in the application controls and reports that depend on it. This guide sets out the four SOX ITGC domains with the controls in each, explains how ITGCs relate to application controls and to information produced by the entity, describes scoping to in-scope systems, sets out how ITGCs are tested and how a deficiency is evaluated, and lists the failures auditors find most often.

Why SOX ITGC exist

Internal control over financial reporting relies on IT in three ways: automated application controls (a three-way match, a system-enforced approval limit), system-generated reports used in manual controls (the aged receivables report a reviewer signs off), and the integrity of the data in the financial systems themselves. None of those can be relied on unless the systems are controlled — unauthorised access could change a configuration, an untested change could break a calculation, a failed job could drop transactions.

AS 2201 treats reliance on IT general controls as a risk factor for the controls that depend on them and, in paragraphs .B28–.B33, allows an auditor to benchmark an automated application control — not re-test it every year — only if the general controls over program changes, access and computer operations are effective and continue to be tested. Effective ITGCs are therefore both a requirement and the thing that makes the rest of the programme cheaper. Our guide to SOX compliance covers the five-step ICFR cycle the ITGCs sit inside.

The four SOX ITGC domains

SOX ITGC, application controls and information produced by the entity

The consequence for scoping: an ITGC is in scope when a control or report the programme relies on depends on it. That is why ITGC scoping starts from the significant accounts, not from the IT inventory. Our guide to SOX scoping and materiality covers the top-down path from accounts to systems.

Scoping SOX ITGC to in-scope systems

1. Start from significant accounts and relevant assertions. AS 2201’s top-down approach identifies the accounts, then the processes, then the controls; the systems are the ones those controls and reports run on.
2. List the application layer. The ERP and its financially relevant modules, sub-ledgers, consolidation, treasury, payroll, revenue systems, and the spreadsheets and end-user tools that carry key calculations.
3. Add the supporting layers. Databases, operating systems, middleware and interfaces, identity and access management, job scheduling and backup — for each in-scope application.
4. Bring service organisations in. AS 2201 .B17–.B27: where a service organisation’s services are part of the information system, its controls are part of ICFR; a SOC 1 Type 2 report with the relevant ITGCs, and the user-entity controls it assumes, is the evidence.
5. Scope out with reasons. Systems that hold no financially relevant data or logic are documented as out of scope, so the next auditor can see why.

Testing SOX ITGC

When a SOX ITGC fails

An ITGC deficiency is evaluated like any other, but its consequence spreads. The evaluation asks: which application controls, reports and data depend on the failed general control; could the failure have allowed a misstatement in them; do compensating controls exist — a detailed manual review of the report, a reconciliation that would catch a wrong calculation, monitoring of privileged activity — and were they tested.

A deprovisioning failure with a compensating quarterly access review that operated is often a deficiency; a change-management failure on the revenue system with no compensating review can be a significant deficiency or a material weakness, because the automated controls beneath revenue can no longer be relied on and the auditor loses the benchmarking basis in .B29. Our guide to material weakness vs significant deficiency covers the severity test.

SOX ITGC failures auditors find most often

• Leavers with active accounts. Deprovisioning that depends on HR telling IT, with no reconciliation.
• Access reviews that approve everything. A reviewer signs a list without evidence that inappropriate access was found and removed.
• Developers deploying their own changes. Segregation of duties absent in small teams with no compensating post-deployment review; our guide to segregation of duties covers the mitigations.
• Emergency changes never regularised. Retrospective approval and testing skipped once the fire is out.
• Privileged access uninventoried. Generic and shared administrator accounts, service accounts with interactive logon, database access outside the application.
• Job failures without follow-up. Monitoring that alerts and nobody records what was done.
• Cloud and SaaS gaps. Financial SaaS with no SOC 1, or a SOC 1 whose complementary user-entity controls the company never implemented.

Frequently asked questions

What are SOX ITGC?
The IT general controls over the systems that support internal control over financial reporting, organised in four domains: access to programs and data, program changes, program development and acquisition, and computer operations. PCAOB AS 2201 refers to them as general controls over program changes, access to programs and computer operations, and over software acquisition and maintenance.

Why do ITGCs matter if we test the financial controls?
Because automated application controls, system-generated reports and the financial data itself can only be relied on if the systems are controlled. AS 2201 treats reliance on IT general controls as a risk factor, and lets auditors benchmark automated controls only while the general controls are effective and tested.

Which systems are in scope for ITGC?
Those that support significant accounts and relevant assertions — the applications running the in-scope controls and reports, plus the databases, operating systems, middleware, identity and scheduling infrastructure beneath them, and service organisations whose services are part of the information system.

How are ITGCs tested?
Walkthroughs for design, sampled testing of occurrences for operating effectiveness with population completeness proven, configuration inspection for settings, and roll-forward where interim testing is used.

Is an ITGC failure a material weakness?
Not automatically. It is evaluated by which application controls, reports and data depend on it, whether a misstatement could have resulted, and whether tested compensating controls exist. A failed change control over a key financial system without compensating review can rise to a significant deficiency or material weakness.

Where this leaves you

Run SOX ITGC as the foundation they are: scope from significant accounts to the systems and service organisations beneath them, implement and evidence the four domains — access, change, development and operations — test with complete populations and real roll-forward, and evaluate any failure by what depends on it, because the application controls and reports the whole programme relies on are only as reliable as the general controls under them.

References

• PCAOB — AS 2201: An Audit of Internal Control Over Financial Reporting That Is Integrated with An Audit of Financial Statements — Paragraphs .34–.47 (controls to test, risk factors including IT general controls), .B17–.B27 (service organisations) and .B28–.B33 (benchmarking automated controls).
• 15 U.S.C. § 7262 — Sarbanes-Oxley Act section 404 — Management assessment and auditor attestation of ICFR.

More on SOX

• SOX ITGC — you are here
• SOX compliance: the five ICFR steps
• SOX 404: who needs the auditor attestation
• SOX scoping and materiality
• SOX control testing and sample sizes
• Segregation of duties for SOX and ISO 27001

The ITGC control matrix for the four domains, the in-scope system inventory, the access review, change management and job monitoring procedures, the test plans with population and sampling steps and the deficiency evaluation template are in the SOX Compliance Toolkit, or start with the free templates.