SOX Compliance Requirements: The IT and ITGC Checklist

SOX compliance requirements, in plain terms

SOX compliance requires a US public company to maintain, document and test internal control over financial reporting. Section 302 obliges the CEO and CFO to certify disclosures every quarter. Section 404(a) obliges management to assess ICFR annually. Section 404(b) obliges an independent registered public accounting firm to audit that control environment for larger filers.

That is where most IT and security teams get blindsided. Nothing in the text of the Sarbanes-Oxley Act mentions Active Directory, your CI/CD pipeline or your cloud IAM policy. Yet those systems are where your ICFR audit is won or lost, because an auditor cannot trust a number your ERP produces if the controls over who can change that system, and how, do not hold.

What is SOX compliance?

SOX compliance means meeting the obligations of the Sarbanes-Oxley Act of 2002, a US federal law enforced by the SEC, with public company audits overseen by the PCAOB. In practice it means executives certify financial disclosures, management proves its internal controls over financial reporting work, and for most listed companies an outside auditor independently tests those controls.

The law was written after Enron and WorldCom, so its logic is simple: if you cannot trust the process that produces the numbers, you cannot trust the numbers. Every control you build under SOX exists to make sure the figures that reach your P&L, balance sheet and cash-flow statements are accurate, complete and not quietly editable by someone who should never have had the access.

What is the difference between SOX 302 and SOX 404?

Section 302 is a quarterly certification of disclosure controls signed personally by the CEO and CFO. Section 404 is an annual assessment of internal control over financial reporting. 302 asks "did you tell the truth and do you have controls over what you disclose?" 404 asks "prove the controls behind those numbers actually work."

The gap between 404(a) and 404(b) matters enormously to your budget. Management can assess its own controls with internal audit and a spreadsheet. An external ICFR audit under PCAOB AS 2201 is a different animal: the auditor forms an independent opinion on control effectiveness using a top-down, risk-based approach, starting from material accounts and working down through process-level controls to the ITGCs underneath them.

Who has to comply with SOX?

Every company registered with the SEC must comply with Sections 302 and 404(a), starting with its first annual report after going public. Only accelerated filers (public float of $75 million to under $700 million) and large accelerated filers (public float of $700 million or more) must also obtain the Section 404(b) auditor attestation on ICFR.

Three exemptions from 404(b) are worth knowing before you size your program:

• Non-accelerated filers (public float below $75 million) are exempt from the auditor attestation, an exemption made permanent by the Dodd-Frank Act.
• Low-revenue smaller reporting companies are carved out of the accelerated filer definitions. Under the SEC's 2020 amendments to Exchange Act Rule 12b-2, an SRC with less than $100 million in annual revenue is not an accelerated filer, so no 404(b) attestation is required.
• Emerging growth companies under the JOBS Act are exempt from 404(b) for up to five years after IPO, or until they lose EGC status.

Note what is not exempted. No filer is excused from 302 certification, and no filer is excused from management's own 404(a) assessment. Private companies preparing to IPO are not legally bound by SOX yet, but underwriters and auditors will expect a working control environment on day one, which is why serious pre-IPO teams stand their program up twelve to eighteen months before listing.

What are ITGCs in SOX compliance?

ITGCs (IT general controls) are the foundational controls over the systems that produce financial data. Auditors test them first, because if ITGCs fail, no automated control or system-generated report sitting on top of those systems can be relied on. The three domains that carry the most audit weight are access to programs and data, change management, and IT operations.

Access to programs and data

This is the single most common source of SOX deficiencies. The classic findings are dull and repeated every year: a terminated employee still holding an ERP account three weeks after their last day, a developer with standing write access to the production general ledger, a shared admin account nobody owns, a quarterly access review that was performed but never evidenced. Auditors sample dates. If the leaver was disabled promptly but the ticket has no timestamp, you failed the test even though you did the work.

Change management

The control the auditor is really testing here is separation of duties: the person who writes the code cannot be the person who approves it and pushes it to production. Modern engineering practice actually helps you. Pull request approvals, protected branches, CI gates and immutable deployment logs are excellent SOX evidence, provided each change traces back to an approved ticket. What breaks the chain is the emergency hotfix pushed at 2am with no retroactive ticket, and the config change made directly in the production console.

IT operations

Backups, batch jobs and interfaces between systems. If a nightly job that posts subledger entries into the GL fails silently and nobody notices, the financial statements are wrong and nothing in your control set would have caught it. Auditors want to see that failures are detected, escalated and resolved, with a record of each.

What is a SOX compliance checklist?

A SOX compliance checklist is the working sequence a team follows to reach ICFR readiness: scope the in-scope systems, map risks to controls, assign control owners, document each control, gather evidence continuously, test operating effectiveness, remediate deficiencies, and hold that state through the fiscal year so the external audit finds no surprises.

• Scope by materiality. Identify material accounts and disclosures, then trace back to the applications, databases, operating systems and cloud services that feed them. Everything upstream of a material number is in scope. Everything else probably is not, and pulling it in is how SOX programs bloat.
• Adopt a control framework. Almost every US filer uses the COSO 2013 Internal Control framework for management's 404(a) assessment. It is the SEC-recognized reference for what "suitable criteria" means.
• Name a human owner for every control. Unowned controls do not operate. They also do not produce evidence.
• Design controls that emit evidence as a byproduct. A control that requires someone to remember to screenshot something is a control that will fail in Q3.
• Test before the auditor does. Internal testing throughout the year turns a control failure into a remediated issue rather than a reported deficiency.
• Track remediation with dates. A deficiency found in February and fixed in March, with evidence of the fix operating for the rest of the year, is a very different conversation from one discovered in the audit.

If you already run SOC 2 or ISO 27001, a large share of your access, change and operations evidence is the same evidence. Mapping one control to several frameworks at once is the entire point of compliance management software, and it is the difference between one evidence pipeline and three.

What is a material weakness in SOX?

A material weakness is a deficiency, or combination of deficiencies, in ICFR such that there is a reasonable possibility that a material misstatement of the financial statements will not be prevented or detected on a timely basis. It must be disclosed publicly in the 10-K, and it is the outcome every SOX program is built to avoid.

The ladder runs from control deficiency, to significant deficiency, to material weakness. ITGC failures escalate fast, because a broken access control does not stay contained. It undermines every automated control and system-generated report that depends on that system, so one weak logical access environment can pull a dozen downstream controls into scope.

Making SOX evidence a byproduct of how you already work

The teams that suffer least under SOX stopped treating evidence as a quarterly scavenger hunt. Access reviews pulled straight from the identity provider, change records emitted by the tools engineers already use, and job monitoring that logs its own failures produce evidence continuously, not in a two-week panic before fieldwork.

This is exactly the gap that SOX compliance software is meant to close. Scrutineer maps your controls across frameworks, collects evidence from the systems where the work actually happens, flags gaps before they become deficiencies, and scores the third parties that touch your financially relevant systems. Keeping that state live across the fiscal year is what continuous compliance means in a SOX context, and it is what turns fieldwork from an emergency into a formality.

One boundary should be stated plainly, because SOX is a federal law and the distinction is not cosmetic. No platform certifies SOX compliance. Management makes the 404(a) assessment, and an independent registered public accounting firm audits ICFR under 404(b). Scrutineer is decision-support and audit readiness tooling, not an attestation, and nothing here is legal or accounting advice. What good SOX compliance software gives you is a defensible, current, evidenced control environment to hand the auditor. What they do with it is their independent judgment.

Where to start

If you are pre-IPO, start with scope and access. Work out which systems touch material numbers, get provisioning and deprovisioning clean and timestamped, and separate the people who write code from the people who ship it. If you are already filing, start with last year's deficiencies. The same ITGC failures recur year after year, and most are fixable with better plumbing rather than more headcount.

Last updated July 2026.