The Sarbanes-Oxley Act does not mention IT general controls. Yet for most public companies, ITGCs are where the IT team's SOX year is spent, and where most of its conversations with the auditor happen.
The reason is indirect. SOX requires management to assess internal control over financial reporting, and financial reporting runs on systems. If nobody can show that those systems are protected from unauthorized access and unapproved change, nobody can rely on what they produce.
This article explains what ITGCs are, why auditors care about them, which systems are in scope, and how they differ from the controls you may already run for SOC 2. Later articles in this series go deeper into each ITGC area.
Where ITGCs come from
Section 404 of Sarbanes-Oxley requires management to report on the effectiveness of the company's internal control over financial reporting (ICFR). For larger public companies, the external auditor must also attest to it, under the PCAOB's auditing standard AS 2201. Which companies need the auditor's attestation depends on their filer status, which is a question for your finance team and counsel.
Most companies assess ICFR against the COSO framework, Internal Control: Integrated Framework, in its 2013 edition. One of its principles calls on the organization to select and develop general control activities over technology to support its objectives. That principle is where ITGCs sit in the framework.
AS 2201 directs auditors to a top-down, risk-based approach. They start from the financial statements and the risks of material misstatement, identify the controls that address those risks, and then ask what those controls depend on. Many depend on IT.
Why financial auditors care about IT
Three kinds of financial reporting control depend on systems working as intended.
Automated application controls. A system enforces a rule, such as blocking a payment that does not match a purchase order, or calculating revenue under a configured schedule.
Reports used in controls. A reviewer signs off on an aging report or a reconciliation produced by a system. The control is only as good as the report's completeness and accuracy. Auditors call this information produced by the entity, or IPE.
Interfaces and data flows. Transactions move from a billing system to the general ledger. If the transfer can fail silently, the ledger is wrong.
ITGCs are the controls that keep those systems trustworthy over time. If an automated control was configured correctly in January, ITGCs are what give an auditor confidence it was still configured correctly in December. When ITGCs fail, the auditor generally cannot rely on the dependent controls without substantial extra testing.
The four ITGC areas
Practice, rather than the statute, groups ITGCs into four areas. Some companies and audit firms merge program development into program change.
| Area | The risk it addresses | Typical controls |
|---|---|---|
| Access to programs and data | Unauthorized people can change data, configuration or code | Provisioning with approval, timely removal, periodic access reviews, privileged access restrictions |
| Program change | Changes reach production without testing or approval | Change tickets, testing, approval, separation of development from deployment, emergency change review |
| Program development | New systems or migrations introduce errors | Project approval, testing, data conversion checks, go-live sign-off |
| Computer operations | Processing fails or data is lost without detection | Job scheduling and monitoring, backup and recovery, incident handling |
Access and change are almost always the heaviest areas, and they are where deficiencies tend to cluster. Computer operations is often lighter in a cloud-hosted environment, but it does not disappear.
Which systems are in scope
ITGC scope follows the financial statements. A system is in scope because it supports a relevant control or produces data that flows into financial reporting, not because it is important to the business.
For a SaaS company, the usual candidates are:
The general ledger and the ERP or accounting system around it.
Billing and revenue systems, including subscription billing and any revenue recognition tooling.
Payroll and HR systems that feed compensation expense.
The product itself, where it generates billing data, usage data or other inputs to revenue.
Reporting tools and data warehouses that produce reports used in key controls.
Each in-scope application sits on a stack: the application, its database, the operating system and the network. Auditors decide which layers matter for each application. Direct database access is the layer teams forget most often, because it bypasses every control the application enforces.
Where an in-scope application is a vendor's SaaS product, you cannot test the vendor's ITGCs yourself. The usual answer is the vendor's SOC 1 report, plus the user controls it says you must perform.
How ITGCs are tested
Testing follows the pattern of any controls audit, with two features that matter more under SOX.
Design and operating effectiveness. The auditor first confirms the control is designed to address the risk, often through a walkthrough. Then they test whether it operated through the period, usually by sampling occurrences. Our article on how auditors sample controls explains how sample sizes follow control frequency.
Completeness and accuracy of populations. Before sampling, the auditor needs the full population: every new user, every change, every terminated employee. They will test how that population was produced. A list that cannot be shown to be complete undermines every test drawn from it. System-generated records hold up far better than screenshots here, as our article on screenshots versus system-generated evidence explains.
Management's assessment is made as of the fiscal year-end, but the controls need to have operated for long enough before that date to be tested. A control switched on in the last weeks of the year will not give the auditor much to work with.
How SOX ITGCs differ from SOC 2 controls
If you already have a SOC 2 report, many of your controls will look familiar. The overlap is real, but four differences matter.
Purpose. SOC 2 controls address your service commitments to customers. SOX ITGCs address the risk of a material misstatement in your financial statements.
Scope. SOC 2 usually scopes the product and its infrastructure. SOX scopes financial systems, including the ERP, billing and payroll, which may never have been in a SOC 2.
Segregation of duties. SOX places heavy weight on whether one person can both initiate and approve, or both develop and deploy. Expect more scrutiny of role design.
Reliance. A SOX deficiency feeds into an evaluation of whether financial reporting could be materially misstated. The consequences of an ITGC failure are assessed in that light.
Your SOC 2 evidence for access reviews and code review as a change control can often be extended to SOX scope, rather than rebuilt.
Common ITGC mistakes
Scoping by importance, not by financial relevance. The marketing site is important. It is rarely in SOX scope.
Forgetting the database layer. Application access is reviewed; direct database access with write rights is not.
Reviewing access without testing the user list. The review was done, but nobody can show the list reviewed was complete.
Treating emergency changes as exempt. They need approval and review after the fact, with a record.
Leaving IT out of SOX planning. Finance owns the program. IT owns most of the evidence. Bring them together early.
The SOX ITGC framework page summarizes the control areas, and the glossary defines terms such as ICFR and IPE that recur in auditor conversations.
How TrustLynce helps
TrustLynce runs user access reviews against populations pulled from the source system, with each reviewer's decision recorded. Evidence collection gathers change and access records from your cloud, identity and code systems on a schedule, timestamped and attributed, so populations can be traced back to their source.