SOX applies to public companies, and section 404 requires management to assess the effectiveness of internal control over financial reporting. IT enters because financial systems depend on code, access and data pipelines. A DevOps lead's job is to make change approval, access control and evidence repeatable for the systems auditors designate as in scope.
What does the law actually say?
15 U.S. Code section 7262 requires annual reports to include an internal control report that states management's responsibility for adequate internal control over financial reporting and assesses its effectiveness. The registered auditor then attests to management's assessment, except for emerging growth companies, per the same section.
Nothing in the statute names a deployment pipeline. IT controls come from how auditors and management interpret risk to the financial statements.
Which systems are in scope?
Scope follows the financial reporting path: the general ledger, billing and revenue systems, payroll, and anything that feeds or transforms those numbers. Supporting infrastructure, databases, identity systems and the CI/CD that deploys those applications are pulled in because they could change results. Your company's finance and audit leads decide the list. Ask for it in writing and confirm it covers pipelines.
What do auditors typically test?
Auditors commonly group IT general controls into access, change management and operations, a convention rather than a statutory list. In engineering terms:
- Access: how production and financial systems grant, review and remove access, including privileged and service accounts.
- Change: that changes are requested, reviewed, tested and approved by someone other than the author before production.
- Operations: backups, job scheduling and incident handling for in-scope systems.
The classic test is separation of duties: the person who writes a change should not be the only person who approves its release.
What do you decide, and what is not yours?
You decide how controls are enforced technically. Branch protection that requires a second reviewer is evidence that exists by default, while a policy PDF is not. Pipeline logs with immutable retention beat spreadsheets. Break-glass access with automatic expiry and logging beats shared admin passwords.
You do not decide scope, control deficiency ratings, or what is disclosed. Those belong to finance, internal audit and the audit committee.
Where do teams fail?
Emergency changes are the usual finding. If hotfixes bypass review, the process must record who approved after the fact and when. Another is service accounts with no owner. A third is evidence that cannot be shown for the whole period, because logs were deleted at 30 days while the audit year is twelve months.
Third-party code adds a quieter issue. A dependency update that changes behavior in a financial application is a change; treat it with the same gate as your own code.
How to check or apply this
- Get the in-scope system list and confirm the pipelines are included.
- Enforce second-person approval in the repository and block self-merge for in-scope repos.
- Keep deployment and approval logs for at least the audit period.
- Run quarterly access reviews for production and financial systems and keep the sign-offs.
- Document the emergency path, with after-the-fact review.
- Track dependency and base image updates as changes with approval.
Quick check
Does SOX require a specific CI/CD setup?
No. It requires effective internal control over financial reporting. Your pipeline is evidence that the controls operate.
Is a SOC 2 report a SOX control report?
No. They are separate. SOX is a legal duty for issuers, while a SOC 2 report is an attestation by a service provider about its own controls.
Sources
- 15 U.S. Code section 7262, management assessment of internal controls
- COSO internal control guidance
Last reviewed: 18 October 2026.
