SOX 404 testing: how control design and operating effectiveness are actually tested

The short answer: SOX 404 testing has two parts run in a fixed order. Design effectiveness asks whether a control, if it operated exactly as written by someone competent, would actually prevent or detect a material misstatement. Operating effectiveness asks whether it did operate that way, all period, on real transactions. Design is tested first, usually through a walkthrough, because a control that is badly designed cannot be saved by testing more samples of it. Both tests are then evaluated for severity, and the answer to that severity question is what decides whether you disclose a material weakness.

That is the whole shape of it. What follows is how each test is run in practice, what PCAOB AS 2201 actually says versus what everyone repeats about it, and the one number in SOX testing that appears in every checklist online and in no standard anywhere. References checked August 2026.

What is SOX 404 testing?

SOX 404 testing is the evidence work behind the internal control assertion a public company files each year. Section 404(a) of the Sarbanes-Oxley Act requires management to assess and report on the effectiveness of internal control over financial reporting. Section 404(b) requires the company's external auditor to attest to that control effectiveness separately. Testing is how both parties get from a list of controls to a defensible conclusion about whether those controls work.

A distinction worth getting right, because a lot of published guidance blurs it: PCAOB AS 2201 governs the auditor's work under 404(b). Management's own assessment under 404(a) follows the SEC's interpretive guidance for management, Release 33-8810, not the PCAOB standard. In practice most internal SOX programs run their testing to AS 2201 conventions anyway, because the external auditor wants to rely on that work and will apply its own standard when deciding whether it can. But management is not legally bound by an auditing standard written for auditors.

What is the difference between design effectiveness and operating effectiveness?

Design effectiveness is a question about the control itself. AS 2201 frames it as whether the control, if operated as prescribed by a person with the necessary authority and competence, satisfies the control objective and would effectively prevent or detect a material misstatement. It is a judgment about the control on paper and in configuration, before anyone asks whether it ran.

Operating effectiveness is a question about the period. It asks whether the control actually functioned as designed throughout the period being covered, and whether the person performing it had the authority and competence to perform it effectively. This is where samples, evidence and dates come in.

The order is not a matter of preference. Testing operating effectiveness before you have concluded on design produces work you have to throw away, because a control that was never designed to detect the risk it is mapped to will fail on design regardless of how faithfully it ran. Design failures are also the more severe finding in practice: an operating failure can sometimes be explained by a single breakdown, while a design failure means the control was never capable of doing the job for the whole period.

What is SOX 404 internal controls testing?

SOX 404 internal controls testing is the work of proving that the specific controls in scope for financial reporting were designed properly and operated as designed across the period. Scope is the part that decides how much work it is, and scope is set by risk to the financial statements, not by how many controls exist in the business.

The scoping chain runs in one direction and it is worth knowing, because most arguments about testing effort are really arguments about a step further up. You start from the financial statements, identify material accounts and disclosures, identify the relevant assertions for each, trace those to the processes and systems that produce them, and only then pick the controls that address a real risk of material misstatement. Anything that survives that chain is a key control and gets tested. Anything that does not survive it is a good business practice you may still want, but it is not in the SOX population.

Controls in scope fall into three groups, and the effort is not distributed evenly. Entity level controls cover the environment: tone, governance, the risk assessment process, board oversight. Process level controls are the transactional ones such as reconciliations, approvals and reviews, and they consume most of the testing hours. IT general controls cover access, change management and operations for the systems the process controls run on. That last group is the one that damages programs disproportionately, because an ITGC failure can invalidate reliance on every automated control and every system-generated report that sat on top of it, converting one finding into a re-test of dozens of controls you had already signed off. Scoping that third group is its own discipline, and we cover it in detail on ITGC controls software. The access half of that layer, where one person holds two duties that should never sit together, is covered on segregation of duties software.

What is a walkthrough in SOX testing?

A walkthrough follows one transaction from its origination all the way through the company's processes and systems until it is reflected in the financial records, using the same documents and information technology the company's own people use. AS 2201 describes it as combining inquiry, observation, inspection of relevant documentation, and reperformance of controls. It is the standard way design effectiveness gets tested, and it does double duty by confirming that your process documentation still matches reality.

The most common weakness in a walkthrough is stopping at inquiry. Asking the accounts payable supervisor to describe the approval control and writing down the answer is not a walkthrough. Pulling an actual invoice, seeing the purchase order it matched to, observing the system enforce the approval limit, and confirming who could have overridden it, is. That difference is also why walkthroughs get easier as the underlying process gets more systematic: a team that has already automated invoice matching and approval routing can produce the entire transaction trail from one system rather than reassembling it from three inboxes and a shared drive.

How many samples do you need for SOX testing?

Here is the fact that most SOX content online gets wrong. Every checklist reproduces the same table: 25 samples for a daily control, 2 for a quarterly one, 1 for an annual one. That table is practice convention, drawn from audit sampling guidance and reinforced by decades of habit. It is not in PCAOB AS 2201. The standard prescribes no sample sizes at all. What it says is that the evidence necessary for a given control depends on the risk associated with that control, and that as the risk rises the evidence required rises with it.

This matters commercially, not just pedantically. If your sample sizes are set by a table rather than by risk, you are almost certainly over-testing your low-risk controls and under-testing the handful that could actually produce a material misstatement. The conventional counts are a reasonable starting point and no competent auditor will object to them. But a program that can explain why a particular control got 40 samples and another got 5, in terms of the risk of misstatement, is doing the thing the standard actually asks for, and tends to spend fewer total hours doing it.

The frequency-based counts in common use look like this. Treat them as a floor to be adjusted upward for risk, not as a requirement.

Automated controls behave differently and this is where real hours get saved. A configured system control that has not changed and sits behind tested change management and access controls can often be tested once, because the computer does not have a bad week. The evidence burden moves from sampling the control to proving that general IT controls kept the configuration stable all period.

What is roll-forward testing in SOX?

Most SOX testing happens at an interim date, commonly at the end of the third quarter, because nobody can test a full control population in the two weeks after year end. Roll-forward is the additional work that updates that interim conclusion to the balance sheet date. AS 2201 requires the auditor to obtain evidence about whether changes occurred in the remaining period that would affect the conclusion, and to consider how much additional evidence is needed based on the risk of the control, the sufficiency of the interim evidence, the length of the remaining period, and whether anything changed.

The standard also notes that testing performed closer to the assessment date, and over a longer period, provides stronger evidence. The practical read of that is a scheduling decision: interim testing buys you time, and pays for it with roll-forward work. Controls that changed during the remaining period, controls covering high-risk accounts, and anything with a prior exception generally need real roll-forward samples rather than an inquiry and a confirmation that nothing changed.

What is the difference between a significant deficiency and a material weakness?

Severity, and the two definitions in AS 2201 are worth quoting because the wording carries the whole test. A material weakness is "a deficiency, or a combination of deficiencies, in internal control over financial reporting, such that there is a reasonable possibility that a material misstatement of the company's annual or interim financial statements will not be prevented or detected on a timely basis." A significant deficiency is "a deficiency, or a combination of deficiencies, in internal control over financial reporting that is less severe than a material weakness, yet important enough to merit attention by those responsible for oversight of the company's financial reporting."

Three things follow from that wording. Severity turns on reasonable possibility of a material misstatement, not on whether a misstatement actually happened, so a control can fail with no error found and still be a material weakness. Deficiencies aggregate, so four unrelated small failures in the same process can combine into one material weakness even though none of them qualifies alone. And the audience differs: a material weakness is disclosed publicly in the annual report, while a significant deficiency goes to the audit committee.

What is the difference between SOX 302 and SOX 404?

Section 302 is a quarterly certification by the CEO and CFO covering disclosure controls and procedures, signed with every 10-Q and 10-K. Section 404 is the annual assessment of internal control over financial reporting specifically, with management's report under 404(a) and, where it applies, the auditor's separate attestation under 404(b). The scopes overlap but are not the same: disclosure controls are broader than ICFR and cover non-financial disclosures too. The testing programs are usually shared, because ICFR evidence supports both signatures.

Section 409 is the third one people ask about in the same breath. It requires rapid and current disclosure of material changes in financial condition or operations, and it is what sits behind the four business day deadline on a Form 8-K. It is a disclosure timing obligation rather than a controls testing obligation, so it does not add a test to your 404 program, but it does mean your deficiency escalation path has to be fast enough to feed an 8-K decision.

What is on a SOX 404 controls list?

There is no official SOX 404 controls list. The statute names no control and no standard sets a required count, which is why two companies of the same size can carry 180 controls and 546. What exists instead is a set of areas that a top-down, risk-based scope almost always reaches, because that is where material misstatement risk concentrates. The table below is the shape most programs end up with, not a checklist to adopt.

The scoping test that keeps this list honest is the one in AS 2201: a control is in scope because it addresses a risk of material misstatement to a significant account or disclosure, not because it appeared on a template. The same test decides which systems come in on the IT side, covered in more depth on ITGC controls software. If you are choosing a platform to hold this population, the field and what each one costs is on SOX compliance software, and the rollout timeline is in compliance software implementation cost and timeline.

Does SOX 404(b) apply to my company?

Not to every filer. In March 2020 the SEC amended the accelerated filer definitions to exempt smaller reporting companies with annual revenues under $100 million from the 404(b) auditor attestation requirement. Emerging growth companies are separately exempt for up to five years after IPO under the JOBS Act. What none of those exemptions remove is 404(a): management's own assessment of ICFR still applies, and the certification still gets signed. Companies that read "no auditor attestation" as "no SOX testing" tend to discover the difference during their first year as an accelerated filer, which is the worst possible time to build a control population from scratch.

What actually makes SOX testing expensive

It is rarely the testing. It is the state of the control population when testing starts. Three patterns account for most of the overrun. Controls documented once at implementation and never updated, so the walkthrough becomes a documentation project. Evidence that exists but cannot be produced on request, scattered across email approvals and screenshots with no retention discipline. And a control matrix that has grown by accretion, where nobody has removed a control since 2019 and the program is testing 400 controls when 180 carry the risk.

The fourth pattern is the one this product exists for. Controls get written against a rule as it read on the day someone wrote them, and the rule moves. A control designed around a threshold that has since changed is a design failure waiting to be found by an auditor rather than by you, and no amount of sampling discipline surfaces it, because the samples all show the control operating exactly as designed. Watching the rulebook itself is a different job from testing the controls, which is why regulatory change management sits upstream of the testing calendar rather than inside it.

If you are scoping tooling for the 404 cycle specifically, our SOX compliance software page covers the risk and control matrix, walkthrough capture, design and operating effectiveness testing and deficiency tracking. The companion piece on SOX 404 compliance requirements covers what has to exist before any of it can be tested, and if you are budgeting the program, compliance software pricing sets out what the platforms in this category actually cost against recorded purchase data.

Two pages sit either side of the testing work itself. For the statute and how filer status decides whether your auditor attests at all, start with SOX compliance, which carries the filer thresholds, the section-by-section requirements and the PCAOB standard changes landing on 15 December 2026. For the judgment you have to make once a test fails, see material weakness vs significant deficiency, which works through the likelihood and magnitude tests with examples on both sides of the line.

Sources

• PCAOB AS 2201, An Audit of Internal Control Over Financial Reporting That Is Integrated with An Audit of Financial Statements. Definitions at paragraphs .A7 and .A11, design effectiveness at .42, operating effectiveness at .44, walkthroughs at .37, extent of testing at .46 and .47, timing at .52, roll-forward at .55 and .56.
• SEC Release 33-8810, Commission Guidance Regarding Management's Report on Internal Control Over Financial Reporting, which governs the 404(a) assessment rather than AS 2201.
• SEC amendments to the accelerated filer and large accelerated filer definitions, adopted 12 March 2020, exempting smaller reporting companies under $100 million in revenue from 404(b).

Last updated August 2026. General regulatory information, not legal or audit advice.