Introduction
SOC 2 Type 2 sampling is how auditors select a subset of control instances from a full period population and test whether those instances operated as described. This guide is a practical operating playbook for teams that prepare populations, expect sample requests, and want fewer last-minute scrambles during fieldwork.
Sampling is not a party trick and it is not a fixed public formula you can game. Firms apply professional judgment. Population completeness, clear control wording, and durable evidence usually matter more than guessing a sample count in advance.
Related glossary reading: What Is an Audit Sample?, What Is an Audit Population?, and Test of Design vs Test of Operating Effectiveness.
What Type 2 Sampling Is Trying to Prove
A SOC 2 Type 2 report covers whether controls operated effectively throughout an audit period, not only whether they looked good on one day.
When a control operates many times (access grants, production changes, alerts, vendor reviews), auditors rarely test every instance. They:
- Define the control and what "operated" means
- Obtain the population of relevant instances for the period
- Select a sample
- Request evidence for each sampled item
- Record control deviations when an item fails the criteria
Design testing still happens, but sampling is the heart of many operating effectiveness tests.
Why Population Quality Beats Sample-Size Guessing
Teams often ask, "What sample size will they pick?" That question is understandable and usually the wrong first question.
Better first questions:
- Can we produce a complete population for this control and period?
- Does every population row map to retrievable evidence?
- Are dates, owners, and system sources trustworthy?
- Did we exclude out-of-scope noise without hiding in-scope activity?
If the population is incomplete, late, or manually rebuilt after failures are removed, sample testing becomes contentious no matter what count the auditor chose. Practices vary by firm. Do not treat blog posts or prior-year counts as guaranteed rules.
How Auditors Commonly Pick Samples
Exact methods differ, but common patterns include:
| Approach | What it looks like in practice |
|---|---|
| Random or haphazard selection | Auditor picks items across the period without management steering |
| Stratified selection | Separate buckets (for example, prod vs admin changes) then sample within buckets |
| Judgmental selection | Extra focus on higher-risk items, month ends, or known problem areas |
| Attribute sampling mindset | Enough items to evaluate whether the control attribute operated |
Your auditor decides the method for the engagement. Your job is to provide a clean population and evidence, not to pre-select friendly samples.
A Practical Prep Workflow for Your Team
1. Freeze control wording early
Write what the control requires in plain language. Example: "Production changes require ticket approval and peer review before deploy." If wording is vague, sample criteria will be argued during fieldwork.
2. Identify the system of record
Pick the system that best represents the full set of instances: GitHub merges, Jira tickets, identity provider logs, pager alerts, vendor tracker exports. Prefer machine-generated lists over memory.
3. Build the period population
Export every in-scope instance between the period start and end dates. Include identifiers, timestamps, actors, and links to evidence. Keep the raw export.
4. Reconcile completeness
Ask hard questions:
- Are cancelled, failed, or reverted changes still listed when they were in scope?
- Did weekend and holiday activity get included?
- Are multiple tools involved (for example, GitHub plus a separate deploy system)?
- Does the total count look plausible compared with engineering volume?
5. Stage evidence retrieval paths
For each population type, know how you will pull:
- Approvals and reviewers
- Tickets and change records
- Screenshots or exports with timestamps
- Monitoring alerts and incident timelines
6. Respond to the sample list quickly
When the auditor sends selected IDs, retrieve evidence for those IDs only first. Do not rework the whole year unless asked. If an item cannot be supported, say so clearly and start exception management and remediation tracking.
Example Populations by Control Area
| Control area | Example population source | Typical sample evidence |
|---|---|---|
| Change management | Production deploys or merged PRs to protected branches | Ticket, peer review or pull request approval, deploy record |
| Access provisioning | New accounts or role grants in IdP | Approved request, grant timestamp, joiner ticket |
| Offboarding | Terminations in HRIS linked to access removal | Term date, access removal logs, ticket |
| Access reviews | Periodic review campaigns | Review export, reviewer decisions, completion date |
| Incidents | Sev-defining tickets in the period | Timeline, severity, containment and closure records |
| Vendors | In-scope vendor list with review dates | Review checklist, residual risk, owner sign-off |
These are examples. Your auditor defines what they will test based on your controls and environment.
Point-in-Time Screenshots vs Period Sampling
A screenshot from audit week does not prove a control operated in month two of a twelve-month period. For Type 2 sampling support, prefer:
- Exports retained during the period or regenerated consistently
- Tickets and pull requests with original timestamps
- Logs that can be filtered to the sample IDs
- Review records that show the scheduled cadence actually happened
If evidence only exists because someone rebuilt it after sample selection, expect follow-up questions.
What To Do When a Sampled Item Fails
A failed sample item is a control deviation candidate. Practical steps:
- Confirm the control criteria and the dates
- Gather whatever evidence exists without altering history
- Explain root cause honestly
- Fix the live risk if it is still open
- Improve the operating process
- Ask whether a compensating control left evidence
Do not delete the population row. Do not manufacture an approval after the fact and present it as original. Auditors care about integrity of the trail as much as the miss itself.
Common Mistakes
- Guessing sample sizes instead of preparing complete populations
- Hand-building a population from memory after removing awkward items
- Using different definitions of "production change" between teams
- Providing evidence for similar items instead of the exact sampled IDs
- Treating Type 1 design walkthroughs as substitutes for Type 2 sample support
- Waiting until the sample list arrives to discover that logs expired
- Assuming prior-year sample counts will repeat
Operating Checklist Before Fieldwork
- Confirm period start and end dates with the auditor
- Inventory controls that will likely be sample-tested
- Assign a population owner per control area
- Produce dry-run populations at least once before fieldwork
- Verify evidence retention windows cover the full period
- Align engineering, IT, and compliance on ID formats in sample replies
- Prepare a deviation log template in advance
- Keep branch protection and similar design evidence handy for context
How AuditFlo.co Helps
AuditFlo.co helps teams retain continuous evidence collection and audit-period history for operational artifacts when those records are stored or linked through connected systems and workflows your team already uses, such as GitHub and Jira.
That history can make population support and sample packages easier to assemble. AuditFlo.co does not select auditor samples, does not determine sample sizes, does not issue SOC 2 reports, does not certify compliance, and does not replace auditors.
To see the workflow for your stack, request a demo.
Final Thoughts
Type 2 sampling rewards teams that can produce complete populations and dated evidence on demand. You cannot control every sampling judgment your auditor makes, but you can control preparation quality. Focus on completeness, traceability, and honest handling of misses rather than trying to predict exact sample counts.
FAQ
Can we know the sample size before fieldwork?
Sometimes auditors share planning ranges. Often the final count depends on risk, population size, prior issues, and firm methodology. Ask your auditor for expectations, but prepare as if any in-scope instance could be selected.
Is there an official AICPA table that sets SOC 2 sample sizes for every control?
Teams should not rely on unofficial fixed tables as if they were universal requirements. Auditors use professional standards and firm methodology. Ask your engagement team what approach they will use for your controls.
What if our population is huge?
That is normal for high-volume controls. A complete population still helps the auditor select fairly. Discuss filters and definitions early so you are not exporting noise or missing in-scope activity.
What if logs were not retained for the full period?
Tell the auditor promptly. You may face deviations, alternative procedures, or scope discussions. Fix retention for the next period instead of hoping the gap goes unnoticed.
Should we pre-test our own samples?
Internal dry runs are useful. They are not a substitute for auditor independence. Keep internal test notes separate from the auditor's official sample list.
How is sampling different for Type 1?
SOC 2 Type 1 focuses on design and suitability at a point in time. Type 2 adds operating effectiveness over the period, which is where sampling usually becomes central. See also SOC 2 Type 1 vs Type 2.
What is the fastest way to answer a sample request?
Maintain populations with stable unique IDs and deep links to source records. When the list arrives, retrieve by ID, package evidence, and flag gaps immediately.