What is SOX control testing?

SOX control testing is the work of checking whether a public company's internal controls over financial reporting actually work — both on paper and in practice. It's how a company backs up the claim it's legally required to make every year: that its controls are reliable enough to produce accurate financial statements.

The requirement comes from Section 404 of the Sarbanes-Oxley Act of 2002, passed after Enron and WorldCom to hold companies accountable for their financial reporting. Section 404 forces management to assess its internal control over financial reporting (ICFR) annually, and testing is the evidence behind that assessment. Without testing, the assessment is just an assertion. With it, there's proof.

Below is what gets tested, the two things every control is judged on, the procedures testers use, how problems get rated, who's responsible, and how AI is reshaping the whole exercise in 2026.

The regulatory backbone, briefly

Two subsections of SOX 404 set the stakes. 404(a) requires company management to assess and report annually on whether ICFR is effective — that report goes into the 10-K, names the framework used (almost always COSO), and discloses any shortcomings. 404(b) requires an independent external auditor to attest to management's assessment, but only for accelerated and large accelerated filers. The exemption attaches to non-accelerated filer status — a different test from the separate "smaller reporting company" definition, and the one that actually controls here. Under the SEC's 2020 amendments, a company qualifies as non-accelerated — and so skips the 404(b) attestation — if its public float is under $75 million, or under $250 million paired with annual revenue under $100 million. Emerging growth companies under the JOBS Act get the same exemption automatically for up to five years after their IPO. All of them still have to complete management's own assessment under 404(a).

Two things raise the stakes further. The CEO and CFO personally certify the financial reports and face fines and prison time for knowingly certifying false ones. And under PCAOB AS 2201 (formerly Auditing Standard No. 5), the external auditor's work is an integrated audit — the financial-statement audit and the controls evaluation are done together, not separately.

The sections that drive day-to-day behavior

For control testing specifically, 302, 404, and 802 are the ones that drive the work: certification on every periodic report, annual control assessment, and a defensible evidence trail behind both.

Who is responsible for SOX compliance?

SOX deliberately puts accountability at the top, then spreads the work across a governance structure best read as four lines of defense — each more independent than the one before.

That structure maps onto five concrete roles:

As AI starts performing controls, this map gets more complicated — someone still has to own a control that an algorithm executes.

What actually gets tested

You don't test everything. The scope comes from a top-down risk assessment: start with the financial statements, identify the accounts and disclosures that could be materially misstated, trace them to the processes that feed them, and pick the key controls that address those risks.

The volume is the problem. Per KPMG's 2025 SOX survey, the average number of key controls grew to 546, and the average program now runs about $2.3 million and over 15,000 hours a year.

The two questions: design vs. operating effectiveness

Every key control gets judged on two separate things, and the order matters.

If design fails, testing whether it operates is pointless — operating a broken control well doesn't help. The classic example is a journal-entry control where one person prepares and a second independently reviews: design asks whether the segregation is set up correctly; operating effectiveness asks whether the reviewer genuinely reviewed each entry in the sample, every time, all year.

The four testing procedures

Testers gather evidence using four procedures, usually in combination — listed here from weakest to strongest as evidence.

The risk level of the control drives the mix. Low-risk routine controls might be covered by observation and inquiry; moderate-risk ones add inspection; high-risk controls warrant reperformance.

A walkthrough traces a single transaction from start to financial-statement impact using all four procedures. It's typically how design is evaluated, and it's the early-warning system — do it near the start of the year, catch design gaps while there's still time to fix them, then move to full-sample testing once the design holds.

For manual controls, you test a sample scaled to how often the control runs and how risky it is. Automated controls can sometimes be validated with a sample of one, provided the supporting ITGCs are sound, because a computer performs the control the same way every time. Most programs test in two passes: interim (partway through the year, so deficiencies surface early) and year-end (a roll-forward confirming the control kept operating).

When a control fails: deficiency severity

When testing turns up an exception, the team first decides whether it's a design failure or an operating failure, then rates how bad it is — based on the likelihood and magnitude of a potential misstatement.

Two things soften the blow: compensating controls that operate effectively can mitigate a deficiency, and related deficiencies get aggregated, because several small gaps in the same area can add up to something severe.

A worked example: a 404(b) testing run

What this looks like end to end: a SOX 404(b) control test for an accelerated filer — 42 in-scope controls across 7 cycles, identified top-down per PCAOB AS 2201.

Results are aggregated by cycle. Most cycles pass clean; the failures concentrate where the risk is — here, revenue, procure-to-pay, and especially IT general controls.

Then each deficiency is scored on likelihood × magnitude — the combination, not either alone, drives the classification from deficiency up to material-weakness candidate.

See the full interactive example: SOX Control Testing — Peabody Properties FY2024 ↗

Why it's so heavy, and where the time goes

The hours don't go into judgment. They go into assembling and tying out evidence. For every key control in scope, someone has to pull the right documents, confirm the population is complete, match each sample item to its support, check the configuration was in effect during the test period, and document all of it consistently enough to survive external-auditor review. Multiply that across 500-plus controls, two testing passes, and IT, process, and entity levels, and you have where the $2.3 million and 15,000 hours go. The 2025 survey points to the same two fixes: rationalize the control set, and automate the evidence.

How SOX is changing in 2026 with AI

2026 is a transition year for SOX, and AI is the reason. The shift runs in two directions at once.

First, AI is changing how the testing gets done — drafting test procedures, taking walkthrough notes, selecting samples, and accelerating the evidence pull-and-tie-out that eats most of a cycle. The direction of travel is from periodic sampling toward continuous control monitoring: instead of testing 25 to 40 transactions once a year, analytics can review the full population as transactions happen.

Second, and more consequential, AI is becoming the control itself. If a company uses an AI system to flag unusual journal entries or run anomaly detection, that system isn't a tool that supports a control — under SOX it is a control over financial reporting, with all the testing and governance obligations that come with it. Section 404 has no AI carve-out.

The regulatory picture is catching up, unevenly. A few markers as of 2026:

• PCAOB AS 2201 and AS 2101 were amended and take effect for audits of fiscal years beginning on or after December 15, 2026. The top-down, risk-based approach itself isn't new — start with financial-statement risk, work down to the controls, test the ITGCs first because everything above them depends on them holding — that's been in the standard since 2007. What the amendments update is the guidance on identifying and testing those ITGCs, which matters more every year as a growing share of them sit over AI-driven processes.
• COSO published Achieving Effective Internal Control Over Generative AI in February 2026, warning that set-and-forget assurance doesn't work for probabilistic models and calling for an audit trail that captures inputs, outputs, model and configuration versions, and evidence of human review.
• The SEC treats AI used in financial reporting as squarely within management's ICFR responsibility, and has pursued enforcement against overstated AI claims ("AI washing").

The evidence standard is getting stricter, not looser. "The AI said so" is not documentation. A generative model's output is a claim that needs validation — which is why deterministic, explainable, fully traceable systems are far better suited to control work that has to survive an audit than free-form generative output is.

This is the bar any AI you bring into SOX work has to clear: every step traceable, every figure tied to a source, a human reviewing and signing off. If you run SOX control testing, you can do it with the SOX Control Testing agent using MacrosLM. Drop in the control population along with the supporting evidence — reconciliations, approvals, system reports, change tickets, access listings — and the agent works each control through its design and operating-effectiveness procedures, selects and ties out samples, flags exceptions and missing evidence, and links every conclusion back to the source document through an evidence layer. Click any result and see the underlying support. The manual pull-and-tie-out that consumes most of a testing cycle becomes a reviewed exception list instead of a stack you build by hand.

The judgment stays with the tester: is this exception a design failure or an operating one, does it rise to a significant deficiency, is there a compensating control, does it need to go to the audit committee. The agent clears the mechanical evidence work so the qualified reviewer spends time on severity calls and conclusions, and signs off.

Bottom line

SOX control testing is how a public company proves its financial-reporting controls are both designed well and operating effectively, as Section 404 requires. Each key control is tested on design first, then operation, using inquiry, observation, inspection, and reperformance scaled to its risk. Failures get rated from control deficiency up to material weakness, with the worst requiring public disclosure. The concept is well-defined and the standards are clear. The cost is in the evidence — and that's the part worth automating.

---

This article is for general information and is not accounting, audit, tax, or legal advice. SOX scoping, testing, and deficiency evaluation should be performed or reviewed by qualified professionals and depend on your facts, your filer status, and applicable PCAOB and SEC requirements.