SOX compliance for ITGC and §302/§404 readiness

What SOX requires from your IT organization

The Sarbanes-Oxley Act of 2002 makes executives personally accountable for financial reporting. Two sections drive nearly all of the IT work: §302, under which the CEO and CFO certify each quarter that disclosure controls are effective, and §404, which requires an annual management assessment of internal control over financial reporting (ICFR) — audited for accelerated filers.

Because financial reports are produced by systems, auditors test the IT general controls that keep those systems trustworthy. ITGCs are conventionally grouped into four domains: access to programs and data, program changes, program development, and computer operations. If ITGCs fail, the auditor cannot rely on application controls or system-generated reports, and substantive testing expands — which is why ITGC deficiencies are so expensive.

• Access: user provisioning and deprovisioning, privileged access, periodic access reviews, segregation of duties.
• Change: authorization, testing, and approval of changes to financially relevant systems, with the change-maker separated from the approver.
• Operations: job scheduling and monitoring, incident handling, backup and recovery.
• Information produced by the entity (IPE): any report used in a control must itself be shown complete and accurate.

Why SOX programs outgrow spreadsheets

A first-year program can survive in spreadsheets. It stops scaling the moment the in-scope system count grows: every quarter you re-collect user lists, change tickets, and job logs by hand; every screenshot has to be tied to the period it covers; and by the time the auditor samples, the person who pulled the evidence may be gone. The failure mode is rarely a missing control — it is evidence that cannot be traced, reproduced, or tied to a period.

This is why teams eventually move to purpose-built tooling. Good SOX software replaces the re-collection cycle with continuous, read-only evidence feeds, keeps an append-only record of who accepted what and when, and pre-assembles the workpapers — so the audit becomes a review of standing evidence instead of a quarterly scramble. The value is in the audit trail and reproducibility, not in the checklist.

Evidence vs estimates: what auditors actually test

The core discipline in any SOX program is that a control is either evidenced or it is a gap — there is no partial credit for intent. Some compliance dashboards will still display a readiness percentage when the underlying evidence is missing, but that number fails exactly where it matters, because an auditor tests the evidence, not the score. Treat any control without accepted, traceable evidence as unmet, and report anything you genuinely cannot measure as unmeasured rather than estimating around it.

What auditors actually test is provenance and reliability: where each artifact came from, the period it covers, who reviewed it, and whether it can be reproduced. Strong programs hold evidence with a clear chain of custody, re-verify it on a schedule, and can hand the auditor a bundle they can independently check. None of this substitutes for the external audit opinion — that remains the auditor's independent work — it simply makes reaching that opinion faster and less expensive.

How to evaluate SOX software

Whatever platform you choose, evaluate it against the failure modes that actually burn SOX teams:

• Can it show where each piece of evidence came from, when, and who accepted it? (Traceability is what auditors test first.)
• Does it handle IPE explicitly, or does every system-generated report become a finding?
• Does deficiency evaluation support aggregation, or are deficiencies siloed per control?
• Is tester independence and segregation of duties tracked structurally, or by convention?
• Does it export workpapers in a form your audit firm will actually accept?
• Does it tell you what it cannot measure — or does every dashboard read green?

Frequently asked questions