SOX ITGC: The IT Controls Your Auditor Will Test

SOX IT general controls confuse security teams because the objective is narrower than it looks. SOX is about the integrity of financial reporting. ITGC exists to give the auditor confidence that the systems producing financial figures can be relied upon.

That framing resolves most of the confusion. A control that matters enormously for security may be out of scope entirely, and a control that seems trivial may be critical because a financial figure depends on it.

Scope is narrower than the security estate

In scope: systems that produce, process or store data feeding the financial statements. The ERP, the general ledger, the revenue system, the payroll system, the reporting tools, and the infrastructure those depend on.

Out of scope: most of the rest, however important to the business. A marketing platform holding customer data is a serious security concern and is usually not a SOX concern.

Getting scope right early saves a great deal of argument. Auditors have a view; agree it before testing rather than during.

The three families

Access to programs and data. The largest family and the source of most findings.

Segregation of duties is where a security team's instincts and an auditor's differ. The auditor is asking whether one person could both create and approve a payment — a fraud question, not an intrusion question.

Program change. Changes to in-scope systems are authorised, tested and approved before production, with development separated from production and developers not deploying their own changes unchecked.

Modern CI/CD pipelines satisfy this well when the controls are in the pipeline — approval gates, separation of duties enforced by the tool, an immutable record. They satisfy it poorly when anyone can bypass the pipeline.

Computer operations. Job scheduling and failure handling, backup and recovery, and incident management for in-scope systems.

The evidence standard

This is the adjustment for security teams. A SOX auditor is not satisfied that a control exists; they test a sample and expect complete, dated, attributable evidence for each item in it.

• "We review access quarterly" requires four reviews, with dates, reviewer names, and evidence of what changed as a result.
• "Terminations are processed promptly" requires a sample of leavers with termination dates and access removal dates side by side.
• "Changes are approved" requires the approval record for each sampled change, before deployment, by someone authorised.

A review performed without a record is a control failure, regardless of whether it happened.

Where teams most often fail

1. Access reviews done but not evidenced — no record of who reviewed what or what changed
2. Leaver access removed late, with the delay visible in the dates
3. Emergency changes deployed without retrospective approval
4. Developer access to production that nobody can justify
5. Service accounts with broad privilege and no owner
6. Segregation of duties conflicts introduced by a role change nobody reassessed

Numbers one and two are the most common by a wide margin, and both are evidence problems rather than control problems.

Automating the load

Much of ITGC is well suited to automation: identity governance producing access review evidence, CI/CD enforcing change approval, ticketing systems creating the audit trail as a side effect of normal work.

The principle is to make evidence a by-product of the process rather than something assembled before an audit. See compliance automation.

Where to start

Run an access review on one in-scope system and try to produce the evidence an auditor would accept: who reviewed, when, what they saw, what changed. Most teams discover the review happens and the evidence does not exist, which is precisely the finding they would receive.

GuardsArm supports SOX ITGC readiness and control design. See SOX compliance or book a scoping call.