SOX Compliance: What It Is, Requirements, and How to Prepare

Your company just got an acquisition offer from a public buyer, or your board started talking seriously about an IPO, and someone in the room asked whether you're "SOX compliant." You've heard the term. You've probably never had to actually deal with it.

SOX compliance is the set of internal-control and financial-reporting requirements the Sarbanes-Oxley Act of 2002 imposes on U.S. public companies, built around two sections that do most of the work: Section 302, which makes your CEO and CFO personally certify the accuracy of financial statements, and Section 404, which requires management to assess and report on the internal controls behind those numbers. Get either wrong, and the consequences aren't a warning letter. They're personal liability for your executives.

Most guides to SOX compliance are written for a company that already has a compliance department, a controller, and a program that's been running for years. This one isn't. It's written for the more common situation: a growth-stage company that's never done this before and is trying to figure out what actually applies to them and when.

By the end of this, you'll know what SOX compliance requires, who it applies to, and specifically when a private company should start building toward it. Here's what's ahead:

• What SOX compliance actually means, in plain terms
• Who has to comply, and the increasingly common case of private companies preparing to
• Why the stakes here are personal, not just corporate
• The core requirements: Sections 302, 404, 409, 802, and 906
• SOX internal controls and the COSO framework, including what a real control looks like
• How a SOX compliance audit actually works, including a worked materiality example
• The mistakes that turn a manageable program into an expensive one
• Where ComplyJet fits into all of this, and where it honestly doesn't

What SOX Compliance Actually Means

SOX compliance is the ongoing practice of maintaining internal controls over financial reporting and having those controls tested and certified, as required by the Sarbanes-Oxley Act of 2002.

SOX itself was Congress's response to Enron and WorldCom, two companies whose executives manipulated financial statements badly enough to wipe out billions in shareholder value and, in Enron's case, an entire accounting firm along with it. Enron used off-balance-sheet entities to hide debt and inflate reported earnings; WorldCom capitalized billions of dollars in ordinary operating expenses to make the company look profitable when it wasn't.

Both frauds went undetected for years, in part because the same accounting firms auditing the books were also selling those companies lucrative consulting work, an incentive structure SOX later restricted directly. Investors in both companies lost their savings with essentially no warning, since the public financial statements they were relying on looked healthy right up until they didn't.

The law's core bet was simple: if executives have to personally sign their name to the accuracy of the numbers, and if someone independent has to test the controls behind those numbers every year, fraud gets a lot harder to hide.

That's the part most explanations skip. Being "SOX compliant" isn't a certificate you earn once and file away. It's a standing program: controls you design, evidence you collect continuously, and a certification your executives sign every single reporting period. A company doesn't become SOX compliant the way it becomes ISO 27001 certified. It stays SOX compliant, or it doesn't, one quarter at a time.

Sarbanes-Oxley Compliance and SOX: Same Law, Different Name

"Sarbanes-Oxley compliance" and "SOX compliance" refer to the exact same requirement. SOX is just the acronym, named for the law's two Senate sponsors, Paul Sarbanes and Michael Oxley, and the full text of the Act is publicly available through Congress.gov.

You'll see the name written a few different ways across audit reports, vendor documentation, and SEC filings: "Sarbanes-Oxley compliance" with the hyphen, "sarbanes oxley compliance" without it, or just "SOX compliance." None of these imply a different or lighter version of the requirement. If someone asks what is SOX compliance, or what is sarbanes oxley compliance, they're asking the identical question, just with different phrasing.

Who Has to Comply With SOX Compliance Rules

SOX applies to any company required to file reports with the SEC under the Securities Exchange Act of 1934. In practice, that means:

• U.S. public companies listed on a national exchange like the NYSE or Nasdaq
• Wholly-owned subsidiaries of a public parent, which inherit the parent's SOX scope, so a private subsidiary that was never itself planning to go public can still end up with a full SOX program simply because its parent company is publicly traded
• Foreign private issuers that register securities with the SEC, even if headquartered outside the U.S.
• The public accounting firms that audit any of the above

That last group carries its own restrictions worth knowing about. SOX bars a company's external auditor from also providing certain non-audit services to the same client, including bookkeeping, financial system design, and investment advisory work.

The idea is straightforward: the firm testing your controls shouldn't also be the firm that built them, because that's not independence, it's grading your own homework. This is a direct response to the Enron-era practice mentioned above, where the same firm signing off on the audit was also collecting consulting fees from the client.

Today, any non-audit work an auditor does perform for a client has to be pre-approved by the audit committee, not just cleared informally with management, and the audit committee itself has to be made up of independent directors, not company executives. That structure exists specifically so the people approving an auditor's scope of work have no personal financial stake in what that audit finds.

Not every public company faces the identical scope, either. The SEC splits filers into tiers based on market capitalization and public float, and where a company lands changes what it actually owes.

A company crossing from one tier into another, usually by growing its public float past a threshold, can find its SOX scope expanding significantly without a single new law having been passed, which is worth watching for on its own, not just assumed to be someone else's problem to track. The next section covers what Section 404(a) and 404(b) actually require in practice.

SOX Compliance for Private Companies (and When Pre-IPO Startups Should Start)

Here's the part almost every SOX guide skips entirely, and it's the part that matters most if you're not already public: SOX doesn't legally apply to a private company. But waiting until it does is one of the more expensive mistakes a growth-stage company can make.

Three real events pull a private company into SOX scope, usually faster than founders expect:

1. An anticipated IPO. The realistic planning window is 12 to 18 months before your S-1 filing, not the few months before it. Section 404 compliance isn't something you retrofit in a quarter.
2. An acquisition by a public company. If a public acquirer buys you, your financial systems and controls become part of their SOX scope on day one of the deal closing, whether or not you've ever thought about SOX before.
3. A reverse merger or SPAC transaction. These paths to going public compress the usual runway dramatically, sometimes to months instead of years, because the private operating company effectively steps into an already-public shell's reporting obligations on a timeline set by the deal structure, not by how prepared its controls actually are.

The data on this is worse than most founders assume. According to KPMG's IPO material weakness study, between 40% and 58% of companies going through a traditional IPO disclosed at least one material weakness in their internal controls during the process, with 44% of 2023's IPO cohort affected.

That gap exists because most of these companies treated SOX compliance for private companies as a checkbox to clear during the S-1 process, not a program to build ahead of it.

An acquisition compresses the timeline even further. If a public company acquires you, your financial systems and controls become part of their SOX scope from the day the deal closes, not from some future grace period. There's typically no 12-month runway in that scenario, because the acquirer's own auditors are already on the clock for their next reporting period.

What a phased build-out actually looks like, instead of a scramble in the months before filing:

• Early groundwork (12-18+ months out): document your existing financial processes, run a first risk assessment to identify which accounts and processes are material, and start tracking evidence for controls you're probably already doing informally, like who approves journal entries.
• Mid-stage (6-12 months out): formalize your control documentation into an actual risk-control matrix, close obvious gaps like unsegregated duties over cash or revenue recognition, and start testing controls the way an auditor eventually will.
• Final stretch (0-6 months out): run a full readiness assessment, remediate anything that surfaces, and lock in the evidence trail an external auditor will actually request.

On cost: every competitor guide on this topic cites the same figure, $1 million to $2 million and up to 10,000 audit hours annually. That's a real number, but it's an established public company's steady-state cost, not what a first-time, smaller filer should expect walking in.

A smaller program, scoped to fewer significant accounts and a leaner control environment, costs proportionally less. Nobody publishes a clean number for that smaller case, so treat any specific figure you're quoted for a first-year program as the one to actually compare against, not an industry average built for a much bigger company.

Why SOX Compliance Carries Real Stakes

SOX's penalties are personal, not just corporate, and that's deliberate. Congress wanted executives to feel individually exposed, not shielded behind a corporate entity.

Section 304 is worth sitting with for a moment, because it's the one provision that reaches back in time. If a company has to restate its financials because of misconduct, its CEO and CFO can be required to give back any bonus, incentive pay, or stock sale profit they received in the 12 months following the original, now-incorrect filing.

It doesn't matter whether the executive personally committed the misconduct; the clawback attaches to the role, not just the individual who caused the problem. A CFO who genuinely had no knowledge of a fraudulent entry made two levels below them can still be required to return compensation tied to the misstated period.

Beyond the criminal exposure, there's a quieter, more common failure mode: the material weakness. Roughly 15% of U.S. public companies disclosed at least one material weakness in 2024, per Baker Tilly's analysis of SEC EDGAR data. A material weakness doesn't mean fraud happened. It means there's a real chance a material misstatement could happen and not get caught, and it has to be disclosed publicly in your 10-K.

That public disclosure is its own consequence, separate from any fine or prison term. A material weakness in a 10-K is a signal to every analyst, institutional investor, and short seller reading it that the company's own numbers can't be fully trusted yet, and stock prices have historically reacted to that kind of disclosure even without any accompanying restatement.

It can also complicate a pending financing round or, for a company mid-way through an acquisition, give the other side leverage to renegotiate terms. None of that requires proving fraud. It just requires the weakness existing and getting disclosed on schedule, which is exactly why treating disclosure as a compliance-team formality rather than a genuine business risk tends to backfire.

Most companies don't get into SOX trouble because someone committed fraud. They get into trouble because a control that looked fine on paper was never actually tested under real conditions, and nobody found out until the auditor did. — Editor's Note

Regulatory scrutiny is also tightening, not loosening. In March 2026, the SEC's Division of Enforcement stood up a dedicated SOX Group, staffed specifically to investigate and litigate auditor conduct and SOX violations, a function historically shared with the PCAOB.

Separately, the PCAOB adopted amendments to AS 1105, Audit Evidence, tightening what counts as sufficient, reliable evidence when auditors rely on company-produced or electronic information. Building a program that treats "good enough" evidence as good enough is building toward a standard that's actively moving up, not staying still.

The Core SOX Compliance Requirements

SOX is a long law, running across eleven titles and dozens of individual sections, but a compliance program in practice organizes itself around a much shorter list. Five sections do almost all of the practical work, and a first-time program can safely treat everything else in the Act as background context rather than a separate workstream to build.

Section 302: Executive Certification of Financial Reports

Every quarterly and annual report has to include a signed certification from the CEO and CFO stating that they've reviewed the report, it doesn't contain material misstatements, and it fairly presents the company's financial condition.

They're also certifying something easy to overlook: that they've personally evaluated the company's disclosure controls and procedures within the prior 90 days, and reported any significant deficiencies or fraud involving management to the auditors and audit committee. That personal, time-boxed evaluation is what makes "I didn't know" a much weaker defense than it used to be. It's not enough to trust that finance ran a process somewhere downstream; the certifying officers have to have actually looked.

Section 404: Management's Assessment of Internal Controls

This is the section that actually generates most of a SOX program's workload. Management has to document its internal controls over financial reporting, assess whether they're designed and operating effectively, and report the conclusion, typically as part of the annual 10-K.

That assessment splits into two halves. Section 404(a) applies to every public company: management documents its controls and states its own conclusion. Section 404(b) adds an external auditor's independent attestation on top of management's assessment, but only accelerated and large accelerated filers have to get one, per the filer-tier breakdown above. A smaller reporting company still has real work to do under 404(a); it just doesn't have to pay for an auditor to separately verify it.

In practice, the 404(a) documentation itself usually takes one of two forms: a written process narrative describing how a transaction flows from initiation to the general ledger, or a flowchart showing the same thing visually with control points marked at each handoff. Most mature programs use both, a narrative for detail and a flowchart for a quick walkthrough with an auditor.

A first-time program can start with whichever format the team actually finds easier to keep current, since documentation nobody updates is worse than no documentation at all. The specific format matters far less than whether it gets revisited every time the underlying process actually changes.

Other Federal SOX Requirements to Know: Sections 409, 802, and 906

Section 409 requires real-time disclosure of material changes to a company's financial condition or operations, generally within four business days, rather than held back for the next scheduled quarterly filing. A significant unannounced restatement, a major asset impairment, or an unplanned executive departure tied to a financial issue can all trigger this.

Section 802 requires financial records and audit-related documents, including emails and workpapers, to be retained, with criminal penalties for knowingly destroying or falsifying them to obstruct an investigation.

Section 906 layers a criminal certification requirement on top of Section 302's civil one, and it's the source of SOX's most-cited penalty figures. Between the two of them, Sections 409, 802, and 906 make up the SOX requirements most often overlooked by a first-time program, since 302 and 404 tend to absorb all the early planning attention.

SOX Internal Controls and the COSO Framework

"Internal controls" is doing a lot of work in this law, and most guides name the framework behind it without ever explaining what it actually means in practice.

SOX itself doesn't mandate a specific control framework by name. What it requires is that management use a "suitable, recognized" framework to evaluate internal control effectiveness, and in practice that's almost always meant one framework in particular. The sections below walk through what that framework actually contains, how it relates to the more IT-specific framework most programs pair it with, and what a genuine control built on top of it looks like in practice, not just in theory.

SOX Controls: The COSO Five Components

The vast majority of U.S. public companies build their SOX controls around COSO's Internal Control-Integrated Framework, issued by the Committee of Sponsoring Organizations of the Treadway Commission. It breaks internal control into five components:

1. Control environment: the tone set by leadership, including ethics policies and how seriously the organization actually treats internal control, not just on paper
2. Risk assessment: identifying which accounts, processes, and locations carry a real risk of material misstatement
3. Control activities: the actual policies and procedures, approvals, reconciliations, segregation of duties, that prevent or catch errors
4. Information and communication: making sure the right financial information reaches the right people in time to act on it
5. Monitoring activities: ongoing or periodic evaluations confirming the other four components are actually working, not just designed well

Choosing a SOX Compliance Framework: COSO vs. COBIT

Most SOX guides name both COSO and COBIT and leave it there. They're not competing options, so there's no real "choosing" between them in the sense of picking one over the other.

COSO governs the overall internal-control environment, the five components above, and is the framework nearly every SOX compliance framework decision starts from. COBIT (Control Objectives for Information and Related Technologies) is narrower and IT-specific: it's the framework most commonly layered on top of COSO to govern IT general controls specifically, things like access management, change management, and system operations. A typical SOX program uses COSO as its foundation and pulls in COBIT's IT-governance structure for the technology layer underneath it.

SOX ITGCs and IT Security Controls

IT general controls, ITGCs, are the technology-layer controls that make every other financial control trustworthy. If access to the general ledger system isn't properly restricted, it doesn't matter how well-designed your journal-entry approval control is on paper, because someone with the wrong access could bypass it entirely. Auditors test ITGCs separately from the financial-process controls they support, precisely because a strong-looking control built on a weak technology foundation isn't actually a strong control.

A SOX program typically groups ITGCs into four areas:

• Access management: who can view, edit, or approve transactions in financial systems, reviewed on a regular cadence, not granted once and forgotten
• Change management: how changes to financial systems and applications get requested, tested, and approved before deployment
• System operations: whether backups, job scheduling, and incident handling for financial systems are documented and monitored
• Third-party and vendor risk: whether vendors and subservice organizations that touch financial data or systems have their own controls validated, typically through a SOC 1 or SOC 2 report, not just taken on faith

That last point is easy to underweight. If a payroll processor or a cloud hosting provider touches data that feeds your financial statements, their control environment is effectively part of yours, and an auditor will expect to see evidence that you've reviewed it, not just that you signed a contract with them.

For most growth-stage companies today, that means at minimum reviewing the SOC 1 or SOC 2 report of the cloud provider hosting the financial system itself, plus any payroll, billing, or revenue-recognition tooling that writes data directly into the general ledger. A vendor review that stops at "they say they're compliant" isn't a control. Pulling and actually reading their report, and documenting what it does and doesn't cover, is.

A Worked Example: What a Real SOX Control Looks Like

Naming "segregation of duties" as a control isn't the same as showing what one looks like. Here's a real, specific example:

A second example shows the same shape applied to an IT general control instead of a financial-process one:

A real SOX program has dozens of these mapped across every material account, process, and system, but the shape is always the same: a defined objective, a specific activity that enforces it, a set frequency, and evidence an auditor can actually pull and test.

How a SOX Compliance Audit Actually Works

A SOX audit isn't one event. It's a sequence that runs across most of the fiscal year, and skipping ahead to testing without doing the earlier steps properly is one of the most common ways a program ends up scrambling near year-end.

• Scoping. Identify which entities, accounts, and locations are actually in scope, based on a risk assessment, not a blanket "test everything" approach. A subsidiary that contributes 2% of revenue doesn't need the same scrutiny as the one generating 60% of it.
• Determining materiality. Set the threshold above which a misstatement would actually matter to a reasonable investor. This number anchors almost every judgment call that follows, including which deficiencies get escalated.
• Identifying key controls. Map both IT general controls (ITGCs) and entity-level controls that address the risks identified in scoping. "Key" here means a control genuinely relied on to prevent or catch a material misstatement, not every control that happens to exist.
• Testing. Walk through and test whether controls are both designed correctly and operating effectively over the full period, not just at a single point in time. A control that worked in January but wasn't followed in October is still a failed control for the year.
• Assessing deficiencies. Classify any control failure as a deficiency, a significant deficiency, or a material weakness, based on how likely it is to lead to a material misstatement that goes undetected.
• Reporting. Management issues its own assessment of internal control effectiveness; larger filers also get the external auditor's independent attestation alongside it, as required under Section 404(b).

Once a program is up and running, this sequence repeats on an annual cadence tied to your fiscal year. A typical pattern refreshes the risk assessment and scoping early in the year, runs control testing through the middle two quarters so there's time to remediate anything that fails, and finalizes management's assessment alongside the year-end 10-K.

Internal audit or a compliance team usually owns the testing itself; the external auditor, where one is required, tests independently and forms its own opinion rather than simply reviewing your team's work. That independence is the whole point of Section 404(b): an opinion that just rubber-stamped management's own conclusion wouldn't tell investors anything they didn't already know.

A Worked Materiality Example

Materiality doesn't have a single legal number attached to it, which is exactly why most guides skip explaining it with real figures. Auditors commonly use benchmarks like 5% of pre-tax income or 0.5% to 1% of total revenue or assets as a starting point, then adjust based on qualitative factors.

Those qualitative factors matter more than the raw dollar figure suggests. A $50,000 misstatement in routine office-supply expense probably stays immaterial. A $50,000 misstatement in a metric analysts specifically track, or one caused by intentional manipulation rather than an honest error, can get treated as material even well below the quantitative threshold. Auditors are trained to ask "would this change an investor's decision" alongside "is this bigger than our number," and the second question doesn't override the first.

That threshold matters because it determines the difference between a deficiency and something worse. A significant deficiency is a control failure important enough to report to the audit committee, but not severe enough that it needs to be disclosed publicly. A material weakness is a deficiency severe enough that there's a reasonable possibility a material misstatement wouldn't be prevented or detected in time, and it has to be disclosed in the company's public filings.

Common SOX Compliance Mistakes

Most SOX programs don't fail because of one dramatic error. They fail because of small, repeated ones that compound over a few audit cycles, and most of them are avoidable if someone's actually looking for them.

• Treating spreadsheet-based control tracking as sufficient once the company scales. A spreadsheet with no version control, no access log, and no audit trail is exactly the kind of evidence an auditor will reject, and it's a documented failure mode across nearly every enterprise SOX program. It works fine at ten controls; it falls apart well before a hundred.
• Waiting until the S-1 process starts to build controls. By then, you're retrofitting a year of evidence you don't have, under a deadline you don't control, and the material weakness data on IPO cohorts above is exactly what that looks like at scale.
• Skipping ITGC validation for third-party vendors and subservice organizations. If a vendor touches financial data or systems in scope, their controls are part of your risk, not a separate concern. A signed contract isn't evidence; a reviewed SOC 1 or SOC 2 report from that vendor is.
• Confusing a significant deficiency with a material weakness. The two trigger very different disclosure obligations, and getting the classification wrong either understates real risk to the audit committee or forces an unnecessary public disclosure that didn't need to happen.
• Under-scoping IT general controls. Access management, change management, and system operations controls get treated as an afterthought next to financial-process controls, even though weak ITGCs undermine every control that depends on the systems they protect. A perfectly designed approval workflow means nothing if anyone can edit the underlying data directly.
• Missing the whistleblower-protection requirement entirely. Section 806 protects employees who report suspected fraud from retaliation, and it needs an actual documented process, an anonymous reporting channel and a non-retaliation policy people have actually seen, not just a policy line nobody's read.
• Not documenting evidence at the level of detail an actual audit expects. "We reviewed it" isn't evidence. Who reviewed it, when, what they were looking for, and what they'd have done if they'd found a problem, is.
• Not revisiting the risk assessment after a significant business change. A new revenue stream, a system migration, or an acquisition can shift which accounts and processes are actually material, and a risk assessment built for last year's business doesn't automatically cover this year's.

None of these require a large team or a large budget to avoid. They require someone treating the program as a living system that gets revisited, not a binder that gets built once and pulled off the shelf every year unchanged.

Where ComplyJet Fits In

SOX isn't an attestation framework the way SOC 2 or ISO 27001 are, it's a federal law with its own audit regime built around external auditors and the PCAOB.

How ComplyJet can help you is by providing the foundational support needed for SOX compliance. SOC 1 exists specifically to give a company's auditors and customers assurance over controls relevant to financial reporting, the same territory SOX's Section 404 covers, and we support SOC 1 alongside SOC 2 for growth-stage companies.

A lot of the access-control, change-management, and monitoring evidence a company builds for either report is the same evidence a future SOX ITGC program needs. Building it once, well, instead of twice under different deadlines, is the more efficient path.

FAQs

What is SOX compliance?

SOX compliance is the ongoing practice of maintaining and testing internal controls over financial reporting, as required by the Sarbanes-Oxley Act of 2002. It centers on Section 302, executive certification of financial reports, and Section 404, management's assessment of internal controls, and it applies to U.S. public companies and their subsidiaries.

What does SOX stand for?

SOX stands for the Sarbanes-Oxley Act, named after its two Senate sponsors, Paul Sarbanes and Michael Oxley. It was passed in 2002 in response to the Enron and WorldCom accounting scandals.

What is SOX in accounting?

In accounting specifically, SOX refers to the internal-control and financial-reporting requirements that determine how a company documents, tests, and certifies the controls behind its financial statements, most heavily under Section 404. It's why "SOX compliance" and "SOX 404 compliance" often get used almost interchangeably in accounting and audit conversations.

What is Sarbanes-Oxley compliance?

Sarbanes-Oxley compliance and SOX compliance are the same requirement. "SOX" is simply the acronym; both terms describe the same set of internal-control and certification obligations under the same law.

Who must comply with SOX?

U.S. public companies, their wholly-owned subsidiaries, foreign private issuers registered with the SEC, and the public accounting firms that audit them. Private companies aren't legally required to comply, but many start building toward it ahead of an anticipated IPO, acquisition, or reverse merger.

Are private companies ever required to be SOX compliant?

Not by law, as long as they stay private. But a private company heading toward an IPO, an acquisition by a public company, or a reverse merger will need SOX-aligned controls in place well before that transaction closes, which is why waiting until it's legally required tends to be the more expensive path. Wholly-owned subsidiaries of an already-public parent are the one exception: they inherit their parent's SOX scope immediately, regardless of the subsidiary's own plans.

How do you know if you're SOX compliant?

You're SOX compliant when your internal controls over financial reporting are documented, tested, and operating effectively, your executives have certified the financial reports under Section 302, and (for larger filers) an external auditor has issued an opinion on management's Section 404 assessment. It's confirmed each reporting period, not a one-time status, which is why a company can be SOX compliant one year and disclose a material weakness the next without anything dramatic having happened in between.

What's the difference between SOX and SOC 2?

SOX is a federal law focused on financial-reporting integrity for public companies, with legal and criminal consequences. SOC 2 is a voluntary attestation focused on security and data-handling controls, used commercially to earn customer trust rather than to satisfy a legal requirement. For a full breakdown, see our dedicated SOC 2 vs. SOX comparison.

Related Reading

• SOX Compliance Checklist, the actionable, step-by-step companion to this guide
• SOC 1 vs. SOC 2, for readers weighing SOC 1 vs. SOC 2 as the commercial-trust counterpart to SOX's legal obligations
• SOC 2 vs. SOX Compliance Guide, a direct, dedicated comparison, for readers specifically weighing the two frameworks against each other before deciding where to start