Safeguard
Compliance•

SOX IT controls for VPs of engineering: what to own

SOX does not list IT controls, but sections 302 and 404 make officers answer for internal controls over financial reporting. Here is what engineering owns.

Safeguard Security Team
4 min read

The Sarbanes-Oxley Act does not contain a list of IT controls. Sections 302 and 404 make executives certify and assess internal control over financial reporting, and auditors then look at the systems that feed the numbers. A VP of engineering owns the access, change and operations evidence behind those systems.

What does the statute say?

Section 302, codified at 15 U.S.C. 7241, requires the principal executive and financial officers to certify in each periodic report that they are responsible for establishing and maintaining internal controls, have designed them so material information reaches them, have evaluated their effectiveness within 90 days before the report, and have presented conclusions about that effectiveness. They must also disclose significant deficiencies and material weaknesses to the auditors and audit committee.

Section 404, codified at 15 U.S.C. 7262, requires an annual internal control report that states management's responsibility for an adequate internal control structure for financial reporting and assesses its effectiveness at fiscal year end. Registered auditors attest to management's assessment, except for emerging growth companies, and the attestation requirement does not apply to issuers that are neither large accelerated nor accelerated filers.

Where do IT controls come in?

The statute speaks about internal control over financial reporting, not about servers. IT becomes relevant because financial data lives in systems. If the ledger, billing platform or revenue reporting database can be changed by someone without authorization, the numbers cannot be trusted. Auditors therefore test the systems that matter to those reports. Common groupings in practice are access management, change management and IT operations, but check your auditor's framework, since the grouping is practice and not statute.

Which systems are in scope?

Those that produce, store or transform data used in financial statements, plus the infrastructure and identity systems that protect them. Constructed example: a company recognizes revenue from a usage billing service. An engineer can edit the pricing table directly in production without a pull request. The revenue number depends on that table. This is a control gap that an auditor would raise, even though no financial system was "hacked".

What evidence do auditors usually ask for?

Expect requests for lists of people with access to in scope systems and proof of periodic review, records that each production change was approved and tested, evidence that developers cannot push untracked changes, and logs showing backups and job runs. The more your pipeline records by default, the less manual work you do per request.

How should engineering organize for this?

Name the in scope applications early with finance. Separate duties so that the person who writes a change is not the only one who approves it and ships it. Make emergency access explicit and logged. Keep one place for change records. Tell teams outside the scope boundary what they can ignore, which keeps goodwill.

What does a failed control look like in practice?

Most findings are mundane. A shared administrator account with no owner. A hotfix pushed on a Friday with the approval added afterward. A contractor account that outlived the contract by eight months. None of these needs an attacker to matter, because the question is whether the control worked as designed over the whole period. A short, boring list of fixes closed before year end is a better position than a long policy document.

How to check or apply this

  1. Ask finance and the controller for the list of systems behind financial reporting.
  2. For each system, list who can change code, config and data in production.
  3. Enforce pull request approval and protected branches on in scope repositories.
  4. Run quarterly access reviews with documented sign off, and remove stale accounts.
  5. Log break glass access and review every use.
  6. Practice a mock evidence request, then fix what took more than an hour to produce.

Quick check

Does SOX require specific IT controls?

The statute requires internal control over financial reporting. It does not list IT controls. Auditors test relevant systems using their own frameworks.

Do smaller companies need the auditor attestation?

Section 404(c) says the attestation requirement does not apply to issuers that are neither large accelerated filers nor accelerated filers, and section 404(b) excludes emerging growth companies. Management duties remain.

Sources

Last reviewed: 18 October 2026.

Never miss an update

Weekly insights on software supply chain security, delivered to your inbox.

Self-healing security runs on Safeguard.

Your first fix PR is minutes away.

No sales call required, even your agent can complete the purchase over MCP.