IT general controls (ITGCs) are the controls over the systems that produce financial data. In SOX work they are usually grouped into access to programs and data, program change management, and computer operations, and they matter because every automated control and system report depends on them. If ITGCs fail, the auditor cannot rely on automated controls or system reports without extra work.
Last reviewed: 17 October 2026. Facts checked. This guide follows the published structure of PCAOB AS 2201 and common ITGC practice as described in secondary summaries. PCAOB standards and any firm methodology are primary documents that were not opened for this guide; check the current text. Sample sizes and testing frequencies are not given, because they depend on the company's risk and the auditor's methodology.
Why ITGCs matter
Suppose a system automatically blocks payment of an invoice that has no matching goods receipt. That is an automated application control. It works only if nobody has changed the rule without approval, nobody can switch it off without a trace, and the system is running as designed. ITGCs give that comfort.
For the broader Indian view, see our ITGC guide. This article is about SOX testing.
Scope first: which systems
Do not test every system. Start with the financial statement risks, then list the applications that carry them: ERP, billing, payroll, consolidation tool. Then add the supporting layers, usually the database, the operating system and the network or cloud platform, where they affect those applications. For outsourced systems, ask whether you will rely on a service organisation's report. See the Indian subsidiaries article for more on shared service centres: SOX for Indian subsidiaries.
Area 1: Access to programs and data
The risk: wrong people can see, change or post data, so unauthorised or unreviewed entries reach the books.
| Control | Example test | Evidence to keep |
|---|---|---|
| New user access is approved | Pick new joiners and trace to approved requests | Request, approval, role granted |
| Leavers are removed on time | Compare HR leaver list with active user list | Both lists, comparison, exceptions |
| Periodic user access review | Check reviewer, completeness of list reviewed, follow-up of changes | Review sign-off, list used, tickets for removals |
| Privileged access is limited | Review administrator accounts and who approved them | Privileged user list, justification |
| Segregation of duties | Check conflicting role combinations | SoD rule set, conflict report, mitigations |
| Password and authentication settings | Compare settings to policy | Configuration screen or export |
Common failures: the review is signed but the reviewer never saw the full list; leavers retain access for months; generic or shared admin accounts; developers with production access.
Area 2: Program change management
The risk: a change to a system, report or interface goes live without proper authorisation, testing or approval, and corrupts data or breaks an automated control.
| Control | Example test | Evidence to keep |
|---|---|---|
| Changes are requested and approved | Select changes from the system change log and trace to approvals | Ticket, approval |
| Changes are tested before release | Check test evidence and business sign-off | Test scripts, results, sign-off |
| Approval before deployment | Compare approval date with deployment date | Ticket history, deployment log |
| Developers cannot deploy to production | Review who has deployment rights | Access list for deployment tool |
| Emergency changes are controlled | Review emergency changes and after-the-fact approval | Emergency ticket, retrospective approval |
Key point: the sample must come from a complete system-generated list of changes, not from a list the IT team hands you. If the population is incomplete, the test proves nothing.
Area 3: Computer operations
The risk: batch jobs fail, interfaces drop data, or backups are not recoverable.
| Control | Example test | Evidence to keep |
|---|---|---|
| Jobs are scheduled and monitored | Review job failures and how they were resolved | Job logs, incident tickets |
| Interfaces are complete and accurate | Check reconciliation between source and target | Reconciliation reports |
| Backups run and can be restored | Review backup logs and a restore test | Backup logs, restore evidence |
| Incidents are logged and resolved | Sample incidents for resolution and root cause | Incident register |
Some firms also list a fourth area, system development or implementation, for new systems. Include it if the company implemented or migrated a financial system in the period, because data migration errors can sit in the books for years.
Report completeness and accuracy
Controls often depend on a system report, such as an ageing list or a list of exceptions. The tester must be satisfied that the report is complete and accurate. Typical steps: confirm the report logic or parameters, compare record counts to a source, and check that the report was not altered. Without this, the control cannot be tested reliably.
What to do when an ITGC fails
- Understand which applications and controls depend on the failed ITGC.
- Look for compensating controls that address the same risk.
- If the ITGC deficiency is not compensated, consider more substantive testing of the affected data.
- Evaluate the deficiency. See how to classify it.
A failed ITGC does not automatically mean a material weakness. The question is whether a material misstatement could reach the financial statements undetected.
For a working template, see the ITGC audit workbook.
Frequently Asked Questions
What are the main ITGC domains in SOX?
Access to programs and data, program change management, and computer operations. Some programmes add system development or implementation.
Do ITGCs apply to spreadsheets?
Yes, where spreadsheets support key controls or financial reporting. These end-user computing risks usually need controls over access, changes and formula integrity.
Can we rely on a vendor's SOC 1 report?
It can support reliance on a service organisation's controls, but you must read its scope, the period covered and any exceptions, and confirm that the company has its own user-entity controls in place.
How are ITGCs different from application controls?
ITGCs apply across systems. Application controls sit inside a specific process, such as a three-way match.
Related Articles
Statutory facts on this page are checked against their sources, and the page says where it relied on secondary reporting. How we verify · Report an error