The Sarbanes-Oxley Act was signed into law in July 2002 after accounting scandals at Enron, WorldCom, and Tyco International destroyed billions in shareholder value and wiped out retirement savings for large numbers of employees. Congress moved quickly, and the law was designed to be punitive and highly prescriptive. CEOs and CFOs can face criminal liability for false certifications. Audit committees were given direct responsibility for overseeing external auditors. Auditor independence rules were tightened significantly.
Two decades later, SOX is part of the operating baseline for public-company finance, legal, audit, and security teams. What has changed is the technical environment that SOX controls now have to cover. When the law was enacted, financial reporting systems were more centralized, and infrastructure was more static. Today, financial data moves through cloud platforms, SaaS applications, APIs, identity systems, and third-party integrations. The controls that protect the integrity of financial reporting now often sit inside the same technical stack used for cybersecurity, access governance, and incident response.
This guide explains what SOX compliance requires in practice, how Sections 302 and 404 work, what auditors review in IT general controls, and why cybersecurity and financial reporting have become more tightly connected.
What SOX compliance requires
SOX primarily applies to issuers that are subject to U.S. securities reporting requirements, including public companies listed on U.S. exchanges and certain other SEC reporting issuers, including some foreign private issuers. In practice, SOX-related control obligations often extend across the systems, processes, and subsidiaries that support consolidated financial reporting.
Private companies are generally outside the core SOX framework unless they become subject to SEC reporting obligations, such as in connection with going public or issuing registered securities. For companies preparing for an IPO, building SOX-ready controls well before listing is standard practice. Retrofitting controls after the registration process is underway is much more expensive and much harder to defend.
The law contains eleven titles, but the provisions that drive the most operational work are concentrated in Sections 302, 404, 409, 802, and 906. Section 409 addresses rapid disclosure of material changes in financial condition. Sections 802 and 906 create criminal exposure for document destruction and false certifications. In practice, however, Sections 302 and 404 generate most of the recurring work for finance, internal audit, IT, and security teams because they depend heavily on control design, operation, and evidence.
The SEC and the Public Company Accounting Oversight Board are central to the implementation environment. The SEC sets disclosure and reporting requirements. The PCAOB’s Auditing Standard No. 2201 governs how external auditors evaluate internal control over financial reporting, including under Section 404.
SOX Sections 302 and 404: the controls that define the audit
Section 302: executive certification
Section 302 requires the CEO and CFO to certify quarterly and annual reports filed with the SEC. Those certifications cover, among other things, whether they have reviewed the report, whether the report fairly presents the company’s financial condition and results, and whether they are responsible for establishing and maintaining disclosure controls and procedures and internal control over financial reporting.
They must also evaluate the effectiveness of those controls within the required period before the filing and disclose significant deficiencies, material weaknesses, and certain control changes as required. The point is not to claim that controls are perfect. The point is to certify that management has established, evaluated, and disclosed controls with enough rigor to provide reasonable assurance.
False certifications can create serious criminal exposure. Under Section 906, knowingly certifying a noncompliant report can carry criminal penalties, and willful violations can carry even more severe penalties.
Section 404: the annual assessment
Section 404 is the part of SOX that creates the most sustained audit work. It requires management to assess the effectiveness of internal control over financial reporting as of fiscal year-end and include that assessment in the annual report.
For certain issuers, including accelerated filers and large accelerated filers, the company’s external auditor must also attest to and report on management’s assessment under Section 404(b). That requirement does not apply to all public companies. Non-accelerated filers and certain other categories, such as emerging growth companies, are not subject to the same external attestation requirement.
The distinction between control issues matters. A material weakness is a deficiency, or combination of deficiencies, in internal control over financial reporting such that there is a reasonable possibility that a material misstatement would not be prevented or detected on a timely basis. A significant deficiency is less severe than a material weakness, but still important enough to merit communication to those charged with governance.
For IT and security teams, the implication is straightforward: access controls, change controls, logging, evidence retention, and segregation of duties are not just operational safeguards. They can become audit evidence and, in a failure scenario, support a conclusion that internal control over financial reporting was ineffective.
IT general controls: the technical backbone of SOX
IT general controls, or ITGCs, are the foundational controls over the technology environment that supports financial reporting. They are not limited to one application. They apply to the systems, infrastructure, identities, and operational processes that financial applications depend on.
When ITGCs are weak, auditors may conclude that application controls are not reliable because the underlying environment cannot be trusted. While organizations may categorize them differently, auditors and practitioners generally focus on a few recurring domains:
Access management
Provisioning, deprovisioning, periodic access reviews, privileged access governance, and segregation of duties.
Change management
Formal approval processes, separation of development, testing, and production, and documented handling of emergency changes.
Computer operations
Job scheduling, batch processing, monitoring, incident handling, and operational controls over financial systems.
System and software development controls
Controls over how code and configuration changes are designed, tested, approved, and promoted.
Backup and recovery
Backup integrity, retention, restoration testing, and recovery planning for systems relevant to financial reporting.
Access management is one of the most common sources of ITGC findings because it is easy to grant access and harder to remove or continuously validate it. Employees change roles, contractors retain legacy permissions, service accounts accumulate privileges, and manual ticket-based provisioning often leaves gaps between job responsibilities and actual entitlements.
Segregation of duties increases the stakes. If one person can create a vendor, approve a transaction, and post payment without a compensating control, the control objective has failed regardless of what the policy says.
Change management has similar pressure points. Auditors want to see that production changes are authorized, tested, appropriately segregated, and documented. In cloud and DevOps environments, that means the control cannot live only in policy language. It has to be enforced in the technical workflow. If engineers can push unapproved changes directly into production, the control is weak even if the written process says otherwise.
How cybersecurity incidents became a financial reporting risk
Cybersecurity incidents now have a clearer connection to public-company disclosure obligations than they did a few years ago. In 2023, the SEC adopted rules requiring public companies to disclose material cybersecurity incidents on Form 8-K within four business days after the company determines that an incident is material. The rules also require annual disclosure about cybersecurity risk management, strategy, and governance.
That matters for SOX because these disclosures appear in SEC filings and become part of the company’s broader disclosure control environment. The issue is no longer limited to whether a cyber incident is technically serious. The issue is whether it is material, whether the organization can determine that promptly, and whether the company can support its disclosures with reliable facts.
A ransomware event that disrupts billing, a breach that affects financial data, or a compromise that undermines the integrity of transaction processing may all raise financial reporting and disclosure questions. The four-business-day clock starts after the materiality determination, not when the incident first occurs. That puts pressure on incident response, forensics, legal review, and executive decision-making.
The Section 404 connection is practical rather than theoretical. If a cyber incident exposes a failure in access controls, change controls, logging, or monitoring in a system relevant to financial reporting, auditors may evaluate whether the underlying control failure rises to the level of a significant deficiency or material weakness.
Automation, monitoring, and AI in SOX compliance
One of the clearest shifts in the current SOX environment is the increasing use of automation and continuous monitoring. Traditional control testing often relied on sample-based review because reviewing the entire population of access changes, tickets, or system events was not practical. That is changing.
Many organizations now use tools that monitor a larger share of the population of events, transactions, or control activities on an ongoing basis. Access governance tools can identify exceptions much faster than quarterly manual review cycles. Automated workflow controls can block unauthorized combinations of actions before they occur. Evidence collection can be built directly into the process rather than assembled manually during audit season.
That does not eliminate sampling entirely, and it does not remove auditor judgment. But it does change what a mature control environment can look like. For many companies, the trend is toward broader monitoring coverage, faster exception handling, and more durable evidence.
AI adds a separate layer of control design questions. Organizations are starting to use AI-assisted workflows in finance, operations, and security, but the control expectations are still developing. The key issues are familiar even if the technology is new: who can change the model or workflow, how those changes are documented, how inputs and outputs are traced, what validation is performed, and where human review is required for decisions that could materially affect reporting.
The NIST AI Risk Management Framework is useful here as guidance, not as a binding legal requirement. It provides a way to think about governance, accountability, traceability, and oversight for AI systems used in high-stakes contexts.
Where AI intersects with SOX, the central question is usually not whether AI is allowed. It is whether the organization has designed controls strong enough to show that the output is reliable, changes are governed, exceptions are handled, and evidence exists for review. In many cases, especially for material judgments or entries, human review remains a prudent and often necessary part of a defensible control design. But the exact control model depends on the use case, risk level, and surrounding evidence.
What to look for in a SOX compliance program
Security and IT leaders evaluating a SOX program should focus on the areas that most often produce control failures and audit friction.
Continuous access governance
Quarterly access reviews alone are often too slow. Stronger programs use more frequent or continuous monitoring to identify excessive access, orphaned accounts, and segregation-of-duties conflicts earlier.
Technically enforced change controls
A policy is not enough if the workflow allows bypass. Approval gates, separation of responsibilities, deployment evidence, and post-implementation review all need to be enforceable and testable.
Log integrity and retention
Logs must be complete, retained for the required period, and protected against inappropriate modification. If administrators can alter them, or if relevant systems do not log key events, their value as audit evidence is weakened.
Evidence generation built into the process
Controls that automatically create dated, attributable, reviewable evidence are easier to test and less burdensome during audits than controls that depend on ad hoc screenshots and manual follow-up.
Clear ownership between finance, IT, security, and internal audit
SOX failures often occur at the seams. Control operation may sit in IT, ownership may sit in finance, evidence may sit in security tooling, and deficiency remediation may sit nowhere clearly enough. Mature programs define ownership early and document it.
How an AI SOC can support SOX compliance
Security operations is not the entirety of the SOX control environment, but it can play an important supporting role. SOC teams often detect anomalous access, system misuse, changes outside expected workflows, and evidence preservation issues before anyone else does. In that sense, they can become part of the monitoring and investigative fabric around ITGCs.
An AI SOC may help by improving triage speed, correlating evidence across systems, and surfacing suspicious behavior faster than manual workflows alone. That can be valuable in areas like privileged-access misuse, unusual access patterns in financial systems, and investigative reconstruction after an incident.
But this should be framed carefully. An AI SOC does not itself make a company SOX compliant. It supports specific control objectives when integrated into a broader governance, logging, escalation, and evidence framework. Its usefulness depends on how well the system is governed, how human reviewers validate significant outputs, and how reliably the workflow produces auditable records.
The strongest position is to treat the SOC as a supporting detection and investigation layer, not as a substitute for control design, management review, or financial governance.
What SOX compliance means for your security program
SOX compliance has always depended on information technology. What has changed is how much financial reporting now depends on distributed systems, identity infrastructure, cloud platforms, third-party services, and cybersecurity operations.
For security leaders, the practical priorities are clear. Controls relevant to financial reporting need to extend across cloud and SaaS environments, not just legacy ERP systems. Access governance and segregation-of-duties monitoring need to be timely enough to reduce real exposure rather than just document it after the fact. Logging, retention, and evidence integrity need to be technically enforced. And when a security incident occurs, the organization needs to be able to investigate it quickly enough to support both remediation and disclosure analysis.
The security function is not separate from this work. It often provides the logging, monitoring, access governance, and incident response capabilities that make key SOX controls operationally credible. A company can have well-written control language and still have a weak control environment if the underlying technical systems cannot reliably detect misuse, preserve evidence, or support timely review.
In that sense, SOX compliance is not just a finance exercise. For SEC reporting companies, it is also a technology, security, and governance discipline.
