SOX IT General Controls: The Four Domains Auditors Actually Test
Sarbanes-Oxley is a financial regulation, but it reaches straight into IT. Here is what an ITGC audit covers, what the auditor tests in each domain, the deficiencies that fail audits, and how to make your controls produce their own evidence.
By William Bradshaw | July 13, 2026 | 12 min read
Sarbanes-Oxley is a financial regulation. It was written after accounting scandals to make public companies stand behind their numbers, and most of it is about financial reporting, not technology. Yet ask any IT manager at a publicly traded company, a subsidiary of one, or a business heading toward an IPO what their most demanding annual audit is, and a large share will name the SOX IT controls review. The reason is simple: the numbers live in the systems, and the auditor cannot trust the numbers without trusting the systems.
That trust is what IT general controls (ITGC) are for. They are not the flashy part of security, and they rarely stop an attacker on their own. What they do is give an auditor a defensible reason to rely on a financial system: to believe that only authorized people can change it, that only the right people can reach the data, that processing runs and can be recovered, and that new systems reached production under control. When those general controls are strong, the auditor can lean on the application's automated controls and its reports. When they are weak, the auditor has to assume the numbers might be wrong and test far more by hand, which is slower, more expensive, and a finding in its own right.
This article walks what a SOX ITGC program has to cover: why the financial audit reaches into IT at all, the four control domains an auditor works through, what they actually test in each, the deficiencies that reliably become findings, and how to run the controls so they produce their own evidence instead of a fire drill every year. Two of those domains, backup and recovery and the underlying inventory, connect directly to work we cover elsewhere, and this piece ties them back into the financial-controls picture.
Why a Financial Law Audits Your IT
SOX Section 404 requires that a company document and test its internal control over financial reporting, and that the external auditor form an opinion on it. Internal control over financial reporting, usually shortened to ICFR, is the set of controls that gives reasonable assurance the financial statements are accurate. The moment financial reporting moved off paper and into an ERP, a general ledger, and a stack of reports and spreadsheets fed by them, ICFR stopped being purely a finance-department concern. The reliability of the close now depends on the systems that run it.
That is where the audit splits into two layers. Application controls are the checks inside the financial system: a three-way match on a purchase order, a posting rule, an approval workflow. IT general controls are the controls around those systems that keep the application controls trustworthy. An automated three-way match is only reliable if no one can quietly change its configuration, if only authorized staff can reach the data, and if the system that runs it is under change and access control. The general controls are the foundation the application controls stand on, which is why the auditor tests them first.
The practical stakes are about reliance. If ITGC is effective, the auditor can rely on the system's automated controls and its system-generated reports, and test a small sample. If ITGC is deficient, that reliance collapses: the auditor has to treat the reports as potentially unreliable and expand substantive testing across the board. A single significant ITGC deficiency can turn a routine audit into a much larger one and, if it rises to a material weakness, becomes a disclosure. The goal of an ITGC program is to keep the auditor in the first world, not the second.
The Four ITGC Domains
ITGC is conventionally organized into four domains. Every in-scope financial system is assessed against them, and each domain answers a different question the auditor has about whether the system can be trusted.
1. Change Management
Changes to a financial system are requested, authorized, tested, and approved before they reach production, and the person who builds a change is not the one who deploys it. This is what keeps an untested or unauthorized change from silently altering how the numbers are calculated.
2. Logical Access (Access to Programs and Data)
Access is granted on approval, matched to the person's role, reviewed periodically, and removed promptly when someone leaves or changes jobs. Privileged access is limited and monitored, and duties are segregated so no single person can both commit and conceal an error or fraud.
3. IT Operations
The day-to-day running of the systems: scheduled jobs and interfaces complete or their failures are caught and resolved, backups run and are provably recoverable, and incidents are logged and worked. This is the domain that assures the financial data is processed completely and can be restored.
4. Program Development (SDLC)
New systems and major implementations are approved, developed, tested, and migrated to production under control, with data migration validated. Smaller organizations often fold this into change management, but the controls are the same idea applied to a bigger event.
The four domains are not equally weighted for every company. A stable environment with few changes leans hardest on logical access and operations; a company mid-implementation lives in change management and development. The scoping conversation with the auditor decides which systems are in scope and which domains carry the risk, and that scope is where an ITGC program should focus its evidence.
What the Auditor Actually Tests
Testing is evidence-driven. The auditor picks a sample and asks the control to prove it operated for every item, not just that a policy exists. This is the table an ITGC program should be able to fill in on demand.
| Domain | What the auditor samples and expects to see |
|---|---|
| Change management | A sample of production changes, each with a ticket showing request, testing evidence, and approval before deployment, and evidence that the developer and deployer were different people. |
| Logical access | A current user access listing, new-hire and termination samples tied to tickets, the last periodic access review with sign-off, the privileged-account list, and password and multi-factor configuration. |
| IT operations | Batch-job failure handling for a sample of failures, backup success records, at least one tested restore with results, and incident tickets showing resolution. |
| Program development | Project approval, user acceptance testing sign-off, and validation that data migrated to the new system completely and accurately. |
The recurring theme is the same one that runs through every controls audit: a control that cannot produce evidence did not, as far as the auditor is concerned, operate. The design of an ITGC program is really the design of how each control leaves a durable, sampleable trail behind it.
The Deficiencies That Fail Audits
Most ITGC findings are not exotic. They are the same handful of gaps year after year, and each one gives the auditor a concrete reason to doubt the system.
Terminated users who still have access
The single most common finding. An access listing that includes people who left months ago tells the auditor the removal control is not operating, and every access-dependent conclusion weakens with it.
Changes without documented approval or testing
A production change with no ticket, no test evidence, or an approval dated after the deployment. If one sampled change fails, the auditor questions all of them.
No periodic access review, or no segregation of duties
Access that is granted once and never re-examined drifts out of alignment with roles. And when the same person can request, approve, and deploy, the control has no independent check, which is a design deficiency regardless of whether anything went wrong.
Shared or generic administrator accounts
A single "admin" login used by several people breaks accountability: the logs cannot tie an action to a person, so the auditor cannot rely on them.
Backups that have never had a tested restore
A green backup job is not recoverability. Without a documented restore test, the operations control cannot demonstrate that the financial data could actually be recovered.
The tested-restore gap is worth calling out because it spans two worlds. It is a SOX ITGC operations control and a resilience control at the same time, and the way to close it is the same in both: a scheduled, documented restore. Our guide to backup and disaster recovery covers the design that makes a restore both auditable and real.
Make the Controls Produce Their Own Evidence
The organizations that dread SOX season are usually the ones reconstructing a year of evidence in the weeks before fieldwork. The ones that do not have arranged for each control to leave its evidence behind as a byproduct of normal work. That shift, from documenting after the fact to instrumenting up front, is most of what separates a smooth audit from a painful one.
Concretely, that means: ticket every change with its approval and test sign-off, so the change-management sample is a query rather than an archaeology project. Ticket every access grant and every termination, and run a documented user access review each quarter so the listing never drifts far from reality. Separate who requests, who approves, and who deploys, so segregation of duties is structural rather than promised. Test restores on a schedule and keep the results. Keep a current inventory of the in-scope systems, because a control cannot cover a system no one remembered was in scope; a network assessment builds that inventory and keeps the scope honest.
It also helps to stop treating SOX as its own island. The ITGC domains map cleanly onto a recognized security framework, and running the controls against the NIST Cybersecurity Framework means one control set answers the SOX auditor, the security program, and the next framework question at once. Our compliance framework mapping guide shows how a single piece of evidence can satisfy several regimes, and ITGC is one of the clearest places that leverage pays off. Bullium has run this kind of change, access, backup, and recovery discipline at enterprise scale, including a multi-year utility infrastructure program built on documented change management, identity-based access control, and tested disaster recovery.
Frequently Asked Questions
What are SOX IT general controls (ITGC)?
The controls over the IT environment that financial applications and reports depend on. Because SOX requires management and the auditor to assess internal control over financial reporting, and the numbers live in IT systems, the auditor tests the general controls around those systems: change management, logical access, IT operations, and program development.
Why does SOX apply to IT if it is a financial regulation?
SOX Section 404 requires internal control over financial reporting to be documented and tested. Financial reporting runs on the ERP, the general ledger, and the reports that feed the statements, so the reliability of the numbers depends on who can change and access those systems and whether they can be recovered. Those are IT general controls.
What are the four ITGC domains?
Change management, logical access, IT operations, and program development. Smaller organizations often fold program development into change management, leaving three working domains.
What is the most common ITGC deficiency?
Terminated or transferred users who still have access. Others that recur are changes without documented approval or testing, no periodic access review, shared administrator accounts, missing segregation of duties, and backups with no tested restore.
How do we prepare for a SOX ITGC audit?
Instrument the controls to produce evidence as a byproduct: ticket changes, access grants, and terminations; run a quarterly access review; enforce segregation of duties; test restores on a schedule; keep a current system inventory; and map the controls to a recognized framework so one control set answers everything at once.
Turn SOX Season Into a Query, Not a Fire Drill
Bullium helps publicly traded companies and their subsidiaries stand up IT general controls that produce their own evidence: change management with real approvals, access reviews that hold, segregation of duties, and tested recovery. We have run this discipline at enterprise scale, and we build it to fit your team rather than a template. No commitment to engage further.
Related Reading
Backup and Disaster Recovery
The tested-restore control ITGC operations requires, designed so the restore is both auditable and real.
SMB Compliance Mapping
How one control set and one piece of evidence can satisfy CIS, NIST, PCI-DSS, SOC 2, and SOX at once.
NIST CSF 2.0
The framework the ITGC domains map onto, so security and financial-controls work reinforce each other.
Enterprise Infrastructure at Utility Scale
A four-year program built on the change, access, backup, and recovery discipline ITGC depends on.
Related Services
Security Consulting
Design the change, access, and operations controls, and the evidence trail that makes them auditable.
vCIO Practice
Own the control environment at a leadership level: segregation of duties, access governance, and the annual review.
Managed IT Services
Run the operations controls day to day: job monitoring, backups, tested restores, and incident handling.
Network Assessment
The in-scope system inventory an ITGC program depends on, kept current so scope stays honest.