ITGC scoping for SOX: the four controls your auditor tests first
Logical access, change management, deprovisioning, and information used in controls. Get these four right and most of the ITGC conversation goes away. Get them wrong and nothing else you documented matters.
The most common question I get from a controller who has just inherited a SOX program is some version of “how do I scope ITGCs so the auditor accepts it?” Usually it comes with a list of every system in the company and a look of dread. The list is the wrong place to start.
IT general controls exist for one reason in a SOX program: to support the automated controls and system-generated reports that your financial controls depend on. If a control depends on a system, the system has to be reliable. That is the whole test. Scope follows from it.
Start from the financial statements, not the system inventory
Work backwards:
- Significant accounts and disclosures → the transaction cycles that feed them (revenue, purchasing, payroll, close, treasury).
- The key controls in each cycle → which of them are automated, or rely on a system-generated report, calculation, or interface.
- The systems behind those controls → the application, its database, the operating system and infrastructure it runs on, and the interfaces between them.
That last list is your ITGC scope. Everything else — the marketing CRM, the HR survey tool, the dev sandbox — is out of scope unless it feeds a financial control. Write down why each excluded system is excluded. Auditors accept a documented exclusion; they don’t accept a silent one.
The four control areas that decide the outcome
Across first-year and remediation engagements, four areas produce almost all of the ITGC deficiencies. They are not the most technical controls. They are the ones where the evidence is either there or it isn’t.
1. Logical access — who can get in, and who approved it
The auditor will pull a sample of new users during the period and ask for the approved request for each one. Then they will pull the full user list for each in-scope system and ask who reviewed it and when.
What passes: role-based access approved by a business owner before it is granted; a periodic (usually quarterly) review of users and their permissions, by someone who understands what the permissions mean, with the export, the sign-off, and the removals retained.
What fails: access granted “by IT” with no request on file; reviews that say “looks fine” with no population attached; a review of the application that ignores the database and the cloud console underneath it.
2. Privileged access and segregation of duties
This is the one practitioners are venting about most, and for good reason. Administrator accounts, developer access to production, and service accounts are where management override and undetected change live.
What passes: a named list of privileged users, each with a business reason; privileged activity logged and reviewed; developers without standing production access, or with monitored break-glass access that is reviewed after use; segregation conflicts identified and either removed or covered by a documented compensating control that actually operates at a precision that would catch a material error.
What fails: “everyone in IT is an admin”; a compensating control that consists of a manager glancing at a report with no threshold or follow-up.
3. Deprovisioning — the terminated user who still has access
The simplest test in the audit: take the HR termination list, match it against active users in each in-scope system, and look for anyone who should be gone. One match is an exception. Several is a design deficiency.
What passes: termination triggers a ticket; access is removed within a defined window (same day for privileged users, a few days for everyone else); the ticket records the removal date; a periodic reconciliation of HR to active users catches anything that slipped.
What fails: removal depends on a manager remembering to email IT. Contractors and vendor accounts that never appear on the HR list at all.
4. Change management and information used in controls
Two related questions. First: can a change reach production without being authorized, tested, and approved by someone other than the developer? The auditor samples changes and asks for the trail on each.
Second — and increasingly the bigger finding — information used in controls (IUC). If a control relies on a report (an aging, a journal-entry listing, an exception report), management has to show that the report is complete and accurate: where it comes from, what parameters were used, and that it hasn’t been altered. “We pull it from the system” is not evidence. The retained report, the query or parameters, and a tie-out to source is.
What passes: ticketed changes with test evidence and approval; branch protection or equivalent enforced by tooling; a report inventory naming each IUC, its source, and how completeness and accuracy are validated; the reports themselves retained for the period.
What fails: infrastructure and configuration changes that bypass the change process; reports validated once at implementation and never again; spreadsheets that feed a control with no version control or access restriction.
Third-party systems: SOC 1 reports are part of scope, not a substitute for it
If a hosted payroll, billing, or ERP provider runs part of a financial process, you need their SOC 1 Type 2 report, and you need to actually read it: does the period cover yours, what are the complementary user-entity controls, and are you performing them? Exceptions in the vendor’s report are your problem to evaluate. A bridge letter covers the gap between their period-end and yours.
Defending the scope to the auditor
Bring three documents to the planning meeting:
| Document | What it shows |
|---|---|
| Application inventory | Every system, the financial controls it supports, and the components in scope (app, DB, OS, interfaces) — or the reason it is excluded |
| Risk-control matrix with ITGC linkage | Which automated controls and IUC depend on which systems |
| ITGC control listing | Owner, frequency, evidence, and testing approach for each control in the four areas above |
With those three, the scoping conversation is short. Without them, the auditor scopes it for you, which is always broader and always more expensive.