Menu
Quick Answer: SOC 2 sample size is the number of individual control instances an auditor tests out of the full population that occurred during the observation period. Neither SSAE 18/AT-C 205 (the standard governing SOC 2 examinations) nor the general audit-sampling concept in AU-C 530 sets a required number; both require only that the sample be reasonably expected to represent the population. The AICPA publishes a non-authoritative Audit Sampling Guide with illustrative reference tables, but the final number is always the auditor’s judgment call, driven by control frequency, population size, tolerable deviation rate, and risk. In practice, ranges of roughly 25 to 60 samples are commonly observed for higher-frequency controls tested over a 6 to 12 month period, but that is observed practice, not a rule.
What “Sample Size” Means in a SOC 2 Audit
In a SOC 2 Type 2 audit, the auditor identifies the full population of times a control operated during the observation period, every access-provisioning event, every production deployment, every access-review cycle, and tests a subset of that population rather than every instance. The auditor then draws a conclusion about whether the control operated effectively across the entire period based on how that subset performed.
A Type 2 report doesn’t ask whether a control was designed well on a single day; it asks whether the control actually operated, consistently, across the whole window under examination. For a control that fires constantly, checking every single instance would be impractical for most organizations and most audit budgets. So the auditor defines the population (say, every access change logged in the identity provider during the 12-month period), pulls a subset of it, and tests each item in that subset against the control’s stated design.
If the sample holds up, the auditor has reasonable assurance the population did too. If it doesn’t, that’s where deviations and exceptions come in, covered further down. Either way, the sample is a proxy for the whole population, and how that proxy gets sized is the part most people outside the audit world get wrong.
How Auditors Actually Decide the Sample Size
There is no single number or formula that every SOC 2 auditor is required to use. SSAE 18 and AT-C 205 require only that a sample be “reasonably expected to be representative of the population.” The actual number is a professional judgment call shaped by four factors: how often the control operates, how large the population is, how much deviation the auditor is willing to tolerate, and the auditor’s overall risk assessment of that control area.
This is the part of SOC 2 sampling that generates the most confusion, so it’s worth being precise about what the standards actually say.
The authoritative attestation standards, SSAE 18 and its codification in AT-C 205 (Examination Engagements), govern how CPA firms conduct SOC 2 examinations. They require that the auditor’s testing approach, including sampling, produce sufficient appropriate evidence and that any sample be reasonably expected to represent the population it’s drawn from. What they do not do is prescribe a specific sample size, a minimum count, or a formula tied to population size. The general concept of audit sampling, laid out in AU-C 530 for financial statement audits, informs how attestation practitioners think about the same problem, but it’s a framework for judgment, not a lookup table.
Given that latitude, auditors size a sample based on four things:
- Control frequency. How often does the control actually operate: annually, quarterly, monthly, weekly, or daily/continuously? A control that runs once a quarter produces a tiny population by definition. A control tied to every login or every deployment can produce thousands of instances over a 12-month window.
- Population size. How many total instances exist in the observation window once frequency is accounted for? A quarterly review over a 12-month period might yield 4 instances total; a daily automated job might yield 250-plus.
- Expected and tolerable deviation rate. How much failure does the auditor anticipate finding, and how much would they tolerate before concluding the control isn’t operating effectively? A control the auditor has no reason to distrust, based on prior testing or a strong control environment, can support a smaller sample than one with a history of problems.
- Risk assessment. How much does a failure in this specific control area matter? Auditors weight higher-risk areas (access provisioning, change management, encryption) more heavily than lower-risk, lower-impact controls, and size samples accordingly.
Here’s the nuance that matters most for anyone trying to sanity-check a number they’ve been quoted: the AICPA does publish a non-authoritative practice aid, an Audit Sampling Guide, that includes illustrative reference tables. Some of those tables are frequency-based and sized for the smaller populations typical of SOC 1 and SOC 2 engagements (a control that runs quarterly, monthly, semimonthly, or weekly gets a correspondingly small illustrative count). Separately, the guide includes confidence-level tables intended for larger populations, generally in the range of 250 or more items, where a frequency-based lookup stops being a useful shortcut and a statistical, confidence-level approach takes over.
That guide is explicitly non-authoritative. It’s a resource auditors may reference, not a rule they’re bound to, and applying it still requires judgment, especially once a population grows large enough that the frequency tables no longer apply cleanly. This is why two audit firms can look at the same-sized population and land on different sample sizes: both are making a defensible judgment call, not one of them following a rule the other is ignoring. That divergence is expected, not a red flag, and it’s not evidence that either firm cut corners.
Illustrative Sample-Size Ranges Commonly Observed in Practice
For a control that only operates a small number of times a year (for example, quarterly), auditors commonly test nearly the entire population, illustratively two or so instances. For higher-frequency controls (weekly or daily) tested over a 6 to 12 month observation period, a range of roughly 25 to 60 samples is commonly observed in practice, depending on population size, risk, and the specific auditor’s judgment.
The table below is illustrative of what shows up in practice, not a rule. Treat it as a sense check, not a target to hit.
| Control frequency | Typical population over the observation period | Sample size commonly observed in practice |
|---|---|---|
| Annual or semiannual (e.g., a risk assessment, a DR test) | 1 to 2 instances | Often the full population; there isn’t enough to meaningfully sample |
| Quarterly (e.g., a board-level review, a vendor risk review) | Roughly 2 to 4 instances | Auditors commonly test nearly all of them, illustratively two or so |
| Monthly (e.g., a monthly reconciliation or report) | Roughly 6 to 12 instances | Commonly a small handful, well under 10 |
| Weekly or continuous (e.g., access changes, deployments) | Dozens to several hundred instances | Commonly observed in the 25 to 60 range, depending on population and risk |
That last row is the one most people are actually asking about when they ask “what’s the standard SOC 2 sample size.” There isn’t a standard number, but 25 to 60 is a real, frequently observed range for the kind of high-frequency, high-population controls (user provisioning, deployments, access reviews) that dominate a typical Type 2 engagement. Our SOC 2 audit checklist walks through what auditors actually test per control area during fieldwork, including how this plays out for access-control populations specifically.
Population size also matters independent of frequency. Two companies both running a “weekly” control can still get different sample sizes if one has ten times the headcount, and therefore ten times the population, of the other. Once you know what auditors will actually sample, our guide to what to pull by evidence source covers how to have that population ready and organized before the auditor asks for it.
What Happens When a Deviation Turns Up in the Sample
A deviation is a single sampled item that fails the auditor’s test procedure, one instance where the evidence doesn’t match the control as described. An exception is the auditor’s documented write-up describing the control tested and the deviation or deviations found; a single deviation can be enough to produce an exception, or an exception can describe a pattern across several. Finding deviations can lead an auditor to pull additional sample items and extend testing rather than stop at the originally planned size.
These two words get used interchangeably by people outside the audit world, but auditors treat them as distinct. A deviation is the raw fact: this one sampled item failed. An exception is the narrative the auditor builds around it for the report, what control was tested, what was found, and how many times.
This distinction matters for a practical reason: it’s also why “sample size” isn’t actually fixed, even within a single engagement. If an auditor pulls an initial sample and finds one or more deviations, a common response is to extend testing, pulling additional items from the same population to determine whether the failure was isolated or systemic. That extended sample is still part of the same test, and the final reported sample size can end up larger than what was originally planned. Our guide to SOC 2 exceptions and qualified opinions covers how auditors weigh a deviation’s severity and pervasiveness once it’s found, and when a pattern of exceptions becomes material enough to affect the auditor’s opinion. For broader context on what a Type 2 observation window covers and why it drives so much of this, see our SOC 2 observation period guide.
The Complete-Population Alternative
For most SOC 2 Type 2 engagements today, sampling is still how testing gets done, for the reasons above: pulling and manually reviewing every single instance of a high-frequency control has historically cost far more than it returns in additional assurance. But that cost calculation is shifting for some organizations as more control evidence becomes fully machine-readable: logs, tickets, and records pulled directly through APIs rather than gathered by hand.
When evidence is already structured and automated, pulling the complete population of a control’s instances can cost little more than pulling a sample, since the retrieval itself is automated either way. That has made testing 100% of a population, rather than drawing a subset, technically feasible in some cases, and it’s a concept that shows up in broader audit-technology commentary as tooling matures. It’s worth knowing about as an emerging idea, but it’s still uncommon, and it is not how sampling works for most SOC 2 engagements today. Traditional sampling, sized to the judgment factors covered above, remains the norm.
FAQ
What is sample size in a SOC 2 audit?
Sample size is the number of individual instances of a control’s operation, a specific access change, a specific deployment, a specific access review, that the auditor actually tests out of the full population of instances that occurred during the observation period. The auditor tests a subset and draws a conclusion about whether the control operated effectively across the whole period.
Does the AICPA require a specific SOC 2 sample size?
No. SSAE 18 and AT-C 205, the standards governing SOC 2 examinations, require only that a sample be reasonably expected to represent the population; they set no mandatory number or formula. The AICPA does publish a non-authoritative Audit Sampling Guide with illustrative reference tables, but it is guidance auditors may consult, not a rule every firm must follow, and applying it still requires professional judgment.
What is a typical SOC 2 sample size range?
It depends heavily on control frequency and population size. A control that only runs a handful of times a year often gets tested almost in full. For higher-frequency controls tested over a 6 to 12 month population, a range of roughly 25 to 60 samples is commonly observed in practice, though this varies by firm, risk assessment, and the specific population.
What happens if a sample shows a deviation?
A single sampled item that fails the test is a deviation. The auditor’s documented write-up describing the control tested and the deviation or deviations found is an exception. Finding deviations can also lead the auditor to pull additional sample items and extend testing beyond the originally planned size, rather than stopping and simply reporting the finding.
Can auditors test 100% of a population instead of sampling?
In some cases, yes. When a control’s evidence is fully machine-readable, logs, tickets, API-pulled records, pulling every instance can cost little more than pulling a sample, since the retrieval is automated either way. This complete-population approach is discussed as an emerging alternative in audit-technology commentary, but it remains uncommon; most SOC 2 Type 2 engagements today still rely on sampling.
Why do different auditors test different sample sizes for the same size population?
Because sample size is a judgment call, not a formula. Two firms can reasonably land on different numbers for a same-sized population depending on how each weighs the control’s risk, its prior-year testing history, and the tolerable deviation rate they set going in. A difference in sample size between firms is not, on its own, a sign that either firm is doing it wrong.
Sample size is one small piece of what actually differs between audit firms; scope, methodology rigor, and how conservative an auditor is about deviations all vary too, which is exactly why picking the right firm matters more than any single number. SOC2Auditors compares verified SOC 2 audit firms on real pricing, timelines, and testing approach, so you can shortlist firms without sitting through a round of sales calls first. Visit SOC2Auditors to get matched with auditors suited to your size and stack.