The Sarbanes-Oxley Act is remembered as an accounting law, but for engineering teams at public companies it is really a law about the reliability of the software that produces financial numbers. If your systems record revenue, calculate balances, or feed the general ledger, they sit inside the scope of internal control over financial reporting — and the controls around how that software is changed, accessed, and secured are exactly what auditors test. This guide explains where software fits under SOX and why supply chain integrity matters more than the statute's plain text suggests.
What SOX is
The Sarbanes-Oxley Act of 2002 was enacted after the Enron and WorldCom accounting scandals to restore confidence in public-company financial reporting. Several sections matter to technology teams:
- Section 302 requires the CEO and CFO to personally certify the accuracy of financial reports and the effectiveness of disclosure controls.
- Section 404 requires management to assess and report on the effectiveness of internal control over financial reporting (ICFR). Under 404(b), the external auditor separately attests to that control effectiveness for larger filers.
- Section 409 requires timely, "real time" disclosure of material changes in financial condition.
SOX created the Public Company Accounting Oversight Board (PCAOB) to oversee auditors, and the SEC enforces the statute. Most companies structure their ICFR around the COSO Internal Control framework, with IT controls often mapped to COBIT.
Who is affected and on what timeline
SOX applies to U.S. publicly traded companies (issuers) and the firms that audit them. Compliance is not a one-time project: management must assess ICFR every fiscal year, and the external audit runs on the same annual cycle. Newly public companies phase in over their first filings, and smaller reporting companies and non-accelerated filers are generally exempt from the 404(b) auditor attestation — but not from the underlying obligation to maintain effective controls.
The practical unit of SOX work for software teams is the IT general control (ITGC). Auditors typically examine four domains: access to programs and data, program change management, program development, and computer operations. Weaknesses here are treated as deficiencies that can roll up into a significant deficiency or, in the worst case, a material weakness that must be disclosed.
Software and supply-chain obligations
SOX does not mention open-source dependencies, CVEs, or software bills of materials. But its control objectives land on software all the same, and the supply chain is increasingly part of the picture:
- Change management: every change to a financially relevant application — including dependency upgrades and patches — should be authorized, tested, and traceable, with segregation of duties between the person who writes code and the person who deploys it. An unreviewed dependency bump that alters system behavior is a change-management gap.
- Access controls: access to the code, build systems, and production environments behind financial applications must be restricted and reviewed, so that unauthorized changes to the numbers are prevented and detectable.
- Integrity of the pipeline: if a compromised component or build system can silently alter a financially relevant system, the reliability that ICFR asserts is undermined. Regulators have shown willingness to scrutinize the security representations public companies make; the SEC's 2023 action against SolarWinds over its internal-controls and security disclosures drew attention to this intersection, though the litigation was substantially narrowed in court and remains a cautionary example rather than settled doctrine.
The takeaway: knowing what is in your financially relevant software, controlling how it changes, and being able to show that vulnerabilities are managed all reinforce the ITGCs auditors test.
Compliance checklist
- Identify systems in scope for ICFR (those that produce or process financial data)
- Enforce change management with authorization, testing, and audit trails
- Segregate duties between development and production deployment
- Restrict and periodically review access to code, build, and production
- Maintain an inventory of components in financially relevant applications
- Scan dependencies for vulnerabilities and track remediation
- Retain evidence: change tickets, approvals, scan history, access reviews
- Remediate ITGC deficiencies before they aggregate into a material weakness
How Safeguard helps
Safeguard strengthens the software-integrity side of your SOX program. SBOM Studio maintains a current inventory of every component in your financially relevant applications, so a change-management review can account for what actually shipped rather than what the release notes claimed. Software composition analysis scans those components continuously and records the findings and remediation timestamps that make your control operation evidenced rather than asserted.
Griffin AI prioritizes findings by reachability so remediation effort — and the audit trail behind it — focuses on the vulnerabilities that genuinely matter to system integrity. Our compliance pages show how this evidence maps to IT general control objectives, and for teams comparing tooling approaches our comparisons lay out where automated evidence collection meets continuous vulnerability management.
SOX rewards traceability. The companies that fare best in an audit are those that can produce, on demand, a clean record of what changed, who approved it, and how known risks were handled — including the risks that arrived through their dependencies.
Frequently Asked Questions
Does SOX actually require vulnerability scanning? Not by name. SOX requires effective internal control over financial reporting, and auditors test IT general controls such as change management and access. Scanning is not a statutory line item, but demonstrating that vulnerabilities in financially relevant software are identified and managed supports the integrity objectives those controls exist to protect.
Which systems are in scope for SOX? Systems that create, process, or store data feeding the financial statements — general ledger, revenue, billing, and the applications and infrastructure that support them. The scoping exercise, done with your auditors, determines which applications and their IT general controls are subject to testing.
What is the difference between a deficiency and a material weakness? A control deficiency is a shortcoming in the design or operation of a control. Deficiencies can aggregate into a significant deficiency, or into a material weakness — a deficiency, or combination, that creates a reasonable possibility of a material misstatement going undetected. Material weaknesses must be disclosed.
How does the software supply chain connect to SOX? Through the integrity of financially relevant systems. If a compromised dependency or build process can alter those systems undetected, the reliability that ICFR asserts is weakened. Controlling how components change and managing their vulnerabilities reinforces the change-management and access controls auditors examine.
Ready to build a traceable evidence trail for your financially relevant software? Create a free account or read the Safeguard documentation to connect your first repository.