SOX applies to public companies, and its IT controls matter to a product manager when your product feeds financial reporting. Expect auditors to test who can change the system, who can access it, and whether outputs are complete and accurate. Plan evidence and approval flows into the roadmap, not after launch.
Where does SOX reach a product team?
Section 404 of the Sarbanes-Oxley Act requires an annual report from management on internal control over financial reporting, including an assessment of its effectiveness. For many issuers, the external auditor then attests to that assessment. Smaller issuers that are neither large accelerated nor accelerated filers are exempt from the auditor attestation, and emerging growth companies are also excluded from it, but management's own assessment still applies.
Section 302 separately requires the principal officers to certify the reports, which is why executives care about control failures.
SOX does not name technical controls. Auditors and management build them from frameworks, and the IT portion is usually called IT general controls (ITGCs): access, change management and operations. This is common audit practice rather than statutory text, so confirm the scope with your auditors.
Which product decisions become audit questions?
A constructed example: your billing feature calculates revenue recognition schedules. An auditor will want to know three things. Who can change the calculation logic, and how is each change approved and tested? Who can edit a schedule by hand, and is that logged? How do you know the report is complete?
Those map to three product-facing themes:
- Change management. Code changes to in-scope systems need a ticket, a review by someone other than the author, test evidence and an approval before release. Emergency changes need a documented after-the-fact review.
- Access. Production and admin access should be granted by a named approver, reviewed periodically and removed when people leave. Shared admin accounts are a classic finding.
- Data integrity. Interfaces and reports need reconciliation or validation so that totals match between systems.
What should you ask for before building?
Ask engineering whether the feature is in scope for financial reporting at all. Many features are not, and scoping them out saves real cost. For those in scope, ask for audit logs on privileged actions, separation between who writes code and who deploys it, and a way to export evidence without a screenshot hunt.
Also watch vendors. If a third-party service performs part of a financial process, auditors may ask for that provider's assurance report. A SOC 1 report is the usual type for services that affect financial reporting, and it is distinct from SOC 2.
What do product managers get wrong?
The common mistake is treating SOX as a finance problem that arrives at year end. Auditors test a full period, so a missing approval in March cannot be fixed in December. Another is scoping too wide: if every internal tool is declared in scope, the evidence burden explodes and quality drops. A third is forgetting spreadsheets and scripts. A reconciliation macro that finance runs monthly is a control, and it needs the same change tracking as application code.
Ask for a short control narrative per in-scope feature: what it does, who can change it, how changes are approved and where evidence lives. One page is enough, and it saves a lot of auditor questions later.
How to check or apply this
- Ask finance or internal audit which systems are in scope for financial reporting.
- Mark in-scope features in your backlog so they carry the extra acceptance criteria.
- Add acceptance criteria: approval record, peer review, test evidence, logged privileged actions.
- Remove shared accounts and standing admin access from in-scope systems.
- Keep a list of vendors involved in financial processes and request their assurance reports yearly.
- Agree with engineering how evidence is exported for the auditor.
Policy gates in a CI pipeline can enforce review and approval rules automatically, and Safeguard supports policies and gates for that purpose. Your auditors still decide whether the control design is adequate.
Quick check
Does SOX apply to private companies?
Not directly. It governs issuers of securities under SEC rules. Private companies preparing to go public, or supplying services to issuers, often adopt similar controls early.
Is SOC 2 enough for SOX?
No. They answer different questions. SOX concerns financial reporting controls at the issuer. SOC 2 describes a service provider's security and related controls.
Sources
- 15 U.S. Code 7262, Management assessment of internal controls
- 15 U.S. Code 7241, Corporate responsibility for financial reports
- ITGC categories and SOC 1 usage reflect common audit practice and were not taken from a fetched page; confirm with your auditor.
Last reviewed: 18 October 2026.
