SOX Compliance

What is SOX Compliance?

SOX stands for the Sarbanes-Oxley Act, a US federal law enacted in 2002 following the Enron and WorldCom accounting scandals. It requires public companies listed on US stock exchanges to maintain accurate financial reporting through documented, tested internal controls. The law applies to all US-listed public companies, their subsidiaries, and foreign private issuers listed on US exchanges.

SOX is a financial regulation. That's the starting point most security teams miss. It doesn't directly govern data privacy, cybersecurity, or information classification in the way GDPR or HIPAA do. What it does is require controls over financial data integrity, and in modern enterprises those controls are IT controls. Access controls. Change management. Audit logging. The line between "financial compliance" and "data security" blurs quickly once the auditors arrive.

The sections security teams actually deal with

SOX has over a dozen sections. Three drive the operational work for IT and security teams.

Section 302 requires the CEO and CFO to personally certify, quarterly, that financial statements are accurate and that they've evaluated the effectiveness of disclosure controls. They're signing off on whether the controls protecting financial data work. That certification creates personal liability. If controls fail and the executives signed off anyway, the consequences are serious: fines up to $1 million and up to 10 years imprisonment for knowing violations.

Section 404 is where IT teams feel SOX most directly. It requires management to assess and report on the effectiveness of internal controls over financial reporting (ICFR) annually. The external auditor must then attest to that assessment. Section 404 is the reason IT general controls (ITGCs) exist as a formal audit category, and why access reviews, change management logs, and system monitoring suddenly become audit evidence rather than operational hygiene.

Section 409 requires real-time disclosure of material changes to financial condition. Not directly an IT control requirement, but it creates urgency around incident detection: if a breach affects financial systems, the disclosure clock starts immediately.

What IT general controls actually cover

ITGCs are the backbone of SOX IT compliance. They're not exotic security capabilities. They're the same controls a mature security programme would build anyway, evaluated specifically for their role in protecting financial reporting integrity.

Access controls

Who can access financial systems, at what privilege level, and with what segregation of duties. Segregation of duties is the SOX-specific principle that prevents the same person from authorising a transaction, executing it, and recording it. In IT terms: the developer who writes code for financial applications shouldn't have production deployment rights. The finance analyst who submits journal entries shouldn't be able to approve them.

Auditors sample access configurations, access request approvals, and access reviews. They look for terminated employees whose access wasn't revoked. They test whether privileged accounts are adequately controlled. Over-permissioned access to financial systems is the most common ITGC finding.

Change management

Any change to systems that process or report financial data must go through a documented approval process. Code changes, configuration changes, infrastructure changes. The auditor wants to see that changes were requested, reviewed, approved, tested, and deployed through a controlled process, not pushed directly to production by whoever had the access to do it.

Computer operations

Monitoring of financial systems for availability, error conditions, and operational issues. Backup and recovery procedures. Incident management for issues affecting financial processing.

System development and acquisition

Controls over how new financial systems and applications are built or acquired, ensuring they're tested before production deployment and that security requirements are incorporated.

Why data access logging is a SOX control

SOX doesn't prescribe specific technical implementations. It requires effective controls, and the auditor judges what "effective" means in the context of each company's systems and risk profile. But one thing is consistent across virtually every SOX IT audit: auditors expect evidence that access to financial data is logged, that logs are retained, and that access anomalies are detected.

An auditor testing access controls needs to verify that only authorised individuals accessed financial systems during the period. That requires logs. Not just logs that exist but logs that are retained for the audit period, are tamper-resistant, and are actually reviewed. A log that nobody looks at doesn't demonstrate an effective control.

That's the operational requirement. Immutable, retained logs of who accessed what financial data and when, plus evidence that someone reviewed those logs for anomalies. Both parts matter. Logging without review is a control gap. Review without tamper-resistant logs is a documentation gap.

The evidence problem in SOX audits

SOX Type II-style evidence collection is where most companies experience compliance pain. It's not that the controls don't exist. It's that proving they operated effectively over the full audit period requires evidence that wasn't being collected continuously.

An auditor selects a sample of access reviews. They want to see the review was performed, who performed it, what was reviewed, and what action was taken on exceptions. If the access reviews were done informally, in a spreadsheet that wasn't retained, or if the process varied across quarters, the auditor has exceptions.

An auditor selects a sample of change management records. They want to see the change request, the approval, the test results, and the deployment record. If those records exist in four different systems and have to be assembled manually under audit time pressure, the process has a gap.

That's the real cost of SOX compliance programmes that rely on manual evidence assembly: the sprint before audit deadlines, the scramble to reconstruct records, the risk that something can't be found or doesn't match. Controls that produce evidence continuously as a byproduct of normal operations reduce that sprint to near-zero.

SOX and financial data security

SOX doesn't mandate specific data security controls. But it creates indirect pressure on data security in two ways.

Access to financial systems must be least-privilege and regularly reviewed. That's a data access governance requirement by another name. An employee who transfers to a different department retains their old financial system access until someone revokes it. That's both a SOX finding and a data security gap.

Financial data integrity must be protected. Unauthorised modification of financial records is the failure mode SOX is designed to prevent. Whether that modification comes from an external attacker who gained access, an insider with over-broad privileges, or a developer who made a direct production change without approval, the control failure looks the same to an auditor.

So organisations building SOX compliance programmes and organisations building data security programmes are largely building the same controls. Access management, change management, audit logging, monitoring. The difference is the audit frame applied to those controls.

Frequently asked questions

What is SOX compliance?

SOX compliance refers to adherence to the Sarbanes-Oxley Act, a US federal law requiring public companies to maintain accurate financial reporting through documented, tested internal controls. For IT and security teams, SOX compliance primarily means implementing and evidencing IT general controls covering access management, change management, audit logging, and system monitoring for financial systems.

Who does SOX apply to?

SOX applies to all US-listed public companies and their wholly owned subsidiaries, foreign private issuers listed on US exchanges, and accounting firms that audit public companies. Private companies are not directly subject to SOX, though many voluntarily adopt SOX-aligned controls in preparation for an IPO or because enterprise customers require it.

What is Section 404 of SOX?

Section 404 requires management to assess and report annually on the effectiveness of internal controls over financial reporting. External auditors must then attest to that assessment. Section 404 compliance drives the majority of SOX IT control work, including access control reviews, change management documentation, and audit logging requirements.

What are IT general controls in SOX?

IT general controls (ITGCs) are the foundational controls over IT systems that support financial reporting accuracy. They cover access controls including user provisioning, access reviews, and privileged access management; change management for financial systems and applications; computer operations monitoring; and system development controls. ITGC failures can invalidate application-level controls and create material weaknesses in financial reporting.

What is a SOX material weakness?

A material weakness is a deficiency, or combination of deficiencies, in internal controls such that there's a reasonable possibility that a material misstatement of financial statements won't be prevented or detected. Material weaknesses must be disclosed publicly, creating reputational and market consequences. ITGC failures, particularly in access controls and change management, are a common source of material weakness findings.