SOX is the federal law that requires publicly traded companies — and some private ones — to maintain strict internal controls over financial reporting, with specific IT requirements that go deeper than most people expect.
Filed under the NerdSquad IT Dictionary — compliance frameworks explained for the people who have to actually implement them.
SOX was born from scandal. After the Enron and WorldCom accounting frauds wiped out billions in shareholder value in the early 2000s, Congress passed the Sarbanes-Oxley Act in 2002 with one goal: make it much harder for companies to cook their books without detection. The law added sweeping requirements around financial controls, audit independence, and executive accountability. What most people don't realize is how much of SOX compliance lives in the IT department.
Sarbanes-Oxley Act.
Named after Senator Paul Sarbanes and Representative Michael Oxley, who co-sponsored the legislation. Signed into law by President George W. Bush on July 30, 2002. It's enforced by the Securities and Exchange Commission (SEC) and overseen by the Public Company Accounting Oversight Board (PCAOB), a nonprofit created by the law itself to oversee public company audits.
SOX is financial integrity enforcement with teeth. Before SOX, executives could plausibly claim ignorance when financial statements turned out to be fraudulent. After SOX, the CEO and CFO must personally certify the accuracy of financial reports — and face criminal liability if those certifications turn out to be false.
From an IT standpoint, SOX is fundamentally about one question: can you prove that the financial data in your systems is accurate, complete, and protected from unauthorized changes? Answering that question requires audit trails, access controls, change management processes, and data integrity protections — all of which are IT problems.
SOX primarily applies to:
Private companies are generally exempt — unless they're a subsidiary of a public company, or they're planning to go public. That said, many private companies voluntarily implement SOX-style controls because their lenders, investors, or enterprise clients require it, or because they're building toward an acquisition or IPO.
SOX has eleven titles, but two sections drive the vast majority of IT compliance work:
Section 302 — Corporate Responsibility for Financial Reports: The CEO and CFO must personally certify that financial statements are accurate and that they've evaluated the effectiveness of internal controls within the past 90 days. They also must disclose any significant deficiencies or material weaknesses in controls to auditors and the audit committee. This creates a direct line of accountability from the executive suite to the IT systems that generate and store financial data.
Section 404 — Management Assessment of Internal Controls: This is the big one. Management must annually assess and report on the effectiveness of internal controls over financial reporting (ICFR). External auditors must independently attest to that assessment. In practice, Section 404 audits often become comprehensive reviews of IT general controls — the technical infrastructure that supports financial systems.
When SOX auditors examine IT, they focus on IT General Controls (ITGCs) — the foundational controls that ensure financial systems operate reliably and their data can be trusted. ITGCs typically cover four domains:
Access controls: Who can access financial systems, what they can do, and how access is granted, modified, and revoked. Auditors look for least-privilege provisioning, segregation of duties (the person who enters transactions shouldn't also be able to approve them), MFA, and regular access reviews.
Change management: How changes to financial systems and applications are requested, tested, approved, and deployed. Unauthorized or untested changes to financial software are a significant red flag. Auditors want to see formal change control processes with documented approvals.
Computer operations: How financial systems are monitored, backed up, and recovered. Job scheduling, batch processing, and data integrity checks fall here.
Program development: How new financial applications and significant system changes are developed and implemented. Auditors want evidence that development and production environments are separated and that new systems are tested before going live.
SOX distinguishes between three levels of control weakness, and the consequences escalate accordingly:
Control deficiency: A weakness that could, under some circumstances, result in a misstatement. Usually addressed internally without public disclosure.
Significant deficiency: A more serious weakness that's less than a material weakness but important enough to merit attention by those responsible for financial oversight. Disclosed to the audit committee.
Material weakness: A deficiency (or combination of deficiencies) where there's a reasonable possibility that a material misstatement in financial statements won't be prevented or detected. Material weaknesses must be publicly disclosed and can devastate a company's stock price, trigger shareholder lawsuits, and result in SEC enforcement action.
For individuals, SOX carries real criminal penalties: fines up to $5 million and imprisonment up to 20 years for executives who knowingly certify false financial statements.
Most small and mid-size public companies — and divisions of larger ones — don't have a dedicated IT compliance function. That work often falls to the MSP, the internal IT team, or both. SOX-relevant services an MSP typically supports include:
One thing worth flagging: if your MSP makes changes to financial system infrastructure, they may need to be included in your SOX change management process. Auditors increasingly ask about third-party access to financial systems and whether those access points are controlled and logged.
SOX doesn't operate in a vacuum, especially for financial services companies:
SOX IT compliance is one of those areas where the audit findings are often surprises — gaps in access controls or change management that nobody flagged as a problem until an auditor showed up. If you're a public company (or headed there) and want to pressure-test your IT controls before your auditors do, let's talk.