Every SOX team ends up with a table that says how many items to test for a control that runs daily, weekly, monthly or quarterly. The numbers differ between firms and no regulator publishes one universal table. Understanding why the numbers rise and fall matters more than copying anyone's grid.
Last reviewed: 17 October 2026. Facts checked. We opened web search results on PCAOB AS 2201 (secondary summaries and the PCAOB page listing, not the full standard text). We did not find or open any official table of sample sizes, and none is quoted here, because the PCAOB standard does not, to our knowledge, prescribe one; teams usually take sample sizes from their own methodology or their external auditor's guidance. Confirm in the standard and your firm's policy. The example is invented, with no sizing figures.
What the standard does and does not say
PCAOB AS 2201 asks the auditor to test controls in proportion to risk: the greater the risk that a material weakness could exist in an area, the more audit attention it deserves. It does not hand over a lookup table of items per control. Management's own testing for the section 404 assessment is similar: the framework asks for enough evidence to support the conclusion, and teams translate "enough" into sample sizes.
So any table you see is a firm methodology, a convention or a decision. It is usually built from four inputs.
Input 1: how often the control operates
A control that runs once a year gives you one instance. You test that one instance, thoroughly. A control that runs many times a day gives you a large population, and you test a sample from it.
Teams normally group controls by frequency: annual, quarterly, monthly, weekly, daily and multiple times a day. The more often it operates, the larger the sample, though not in proportion. Doubling the frequency does not double the sample. After a point the extra items add little confidence.
For controls that are performed continuously by the system (an automated three-way match rule, for example), a different logic applies. Test one instance of the logic, then rely on IT general controls to show the logic did not change. See our guides on SOX IT general controls testing and change management controls.
Input 2: the risk of the control
Not all controls deserve the same effort. Teams usually lift the sample for controls that:
- address a higher-risk assertion or a fraud risk;
- are manual and judgement-heavy, such as management review controls;
- sit in a significant account with large exposure;
- have failed or been changed recently;
- are the only control covering a risk, with no backup.
A lower-risk, automated, well-established control can be tested at a smaller sample. The methodology should say how risk moves the number up or down and who decides.
Input 3: reliance on other work
If a control has been tested in earlier periods without exception, and nothing has changed, some methodologies allow a reduced sample or a rotation. The external auditor may reuse management's or internal audit's work to a limited extent, depending on competence, objectivity and the risk of the area. Controls with high risk generally do not get this relief. The detail of reliance rules is for the standard and the firm's policy.
Input 4: tolerance for exceptions
Most SOX sample designs assume a control either operates or it does not; the common planning convention is that any exception in a sample prompts investigation. That is why people say tests "tolerate zero deviations" in some methodologies. The better statement is that a deviation is a signal to find out why, not an automatic verdict.
When an exception appears:
- Establish whether it is a real control failure or a documentation gap (the control occurred, but the evidence is missing).
- Understand the cause: one-off human error, a misunderstanding, a system issue or a design flaw.
- Decide whether to extend the sample. Methodologies differ here. Some allow a defined extension if the first deviation has a clear isolated cause; others treat any deviation as a failure of the control for the period.
- Move to deficiency evaluation; see how to classify control deficiencies.
Whatever the rule, it should be fixed in the methodology before testing, not decided after seeing the results.
Selecting the items
A good sample size with a poor selection is still a poor test.
- Define the population from a complete source, then confirm its completeness. A population given by the control owner is a list the owner chose.
- Select across the period, not clustered. For a monthly control, test months spread across the year, including the quarter-end or year-end month where the risk is higher.
- Use random or systematic selection and record how. Judgemental selection should be explained and limited to targeted tests.
- Match the sample to the attribute, such as the approval, the evidence of review or the timeliness. Each attribute needs a conclusion.
- Test the whole control: not just that a sign-off exists, but that the reviewer examined the right information and followed up exceptions. Our post on management review controls covers that.
Design effectiveness vs operating effectiveness
Sample sizes belong to operating effectiveness. Design is established earlier, usually by walkthrough. Mixing the two leads to teams testing 25 instances of a control that is badly designed. See walkthroughs and design vs operating effectiveness.
Interim and roll-forward
If testing is done at an interim date, the team needs to cover the remaining period. This is usually done by inquiry, a short additional sample or both, with the extent depending on risk and on whether anything changed. The roll-forward is part of the plan, not an afterthought.
A worked example (invented)
A company has a monthly bank reconciliation control and a daily system-enforced credit limit block. The team reasons as follows, without quoting any table:
- The reconciliation is manual, operates twelve times a year, and covers a significant account. The sample covers several months across the year, including year-end, with at least one test of the reviewer's follow-up on reconciling items.
- The credit limit block is automated. The team tests the configuration once, tests that user access to change it is restricted, and checks the change log for the period. No daily sample is needed because the system performs it consistently.
The point of the example is the reasoning, not the counts, which are left to the team's methodology.
What to document
Keep the sample size rule in the methodology, the justification for any departure, the population source, the selection method and each exception with its resolution.
The takeaway
A sample size is a conclusion about how much evidence is enough for this control, in this risk, this year. Learn the four inputs, set the rule before testing and record the reasoning. The grid is the output, not the idea.
Statutory facts on this page are checked against their sources, and the page says where it relied on secondary reporting. How we verify · Report an error