In a SOC 2 Type 2 audit, the auditor asks for a full list of events in the period, such as every change, hire or incident, then selects a sample and tests each item. You prepare by keeping complete, accurate lists and one evidence trail per item. Sample sizes are the auditor's call.
What is a population and why does it come first?
A population is the complete list of times a control operated during the period. For change management it is every production change. For access removal it is every leaver. For incident response it is every ticket classified as a security incident.
The auditor does not trust a population you hand over blindly. They check it for completeness, for example by comparing your change list with the commit history or deployment log. If the list is short because someone filtered out the awkward items, the test fails before sampling starts.
How big is the sample?
The Trust Services Criteria do not set sample sizes. Each audit firm applies its own methodology, often scaling with how frequently a control runs and how long the period is. Ask your auditor for their approach in writing before fieldwork. We could not confirm a single published number that applies across firms, so treat any figure you read in a blog as that firm's practice.
What you can predict is the shape. A control that runs once a year, such as the annual risk assessment, is often tested on its single instance. A control that runs thousands of times, such as deployments, is tested on a subset.
What gets sampled in practice?
These are the items that most often come with sample requests, tied to criteria:
- Production changes with approvals and test evidence (CC8.1).
- New hires and leavers (CC6.2, CC6.3).
- Security incidents and their follow up (CC7.3, CC7.4).
- Vulnerability findings and fix timing (CC7.1).
- Vendor reviews (CC9.2).
- Access reviews, one per quarter or whatever frequency you set (CC6.3).
- Backups, restores or recovery tests where Availability is in scope (A1.2, A1.3).
Why do small teams get hurt by sampling?
One missed approval on one change is an exception. Because the auditor chose at random, you cannot pre-select the clean ones. If your process has 5 percent leakage, a sample of 25 will probably find it.
The second hurt is inconsistent evidence format. Three of a sample have a ticket, two have a chat message, one has nothing. The auditor then asks for the one thing you do not have.
How should you prepare populations?
Make the system produce the list. A pull request report from your source control tool, an export of the identity provider's user events, and a ticket filter for incidents are all better than a hand built spreadsheet. Note the query or filter you used and the date you ran it, so the auditor can reproduce it.
For each item in the list, the evidence should be reachable in two clicks: ticket to pull request to approval to test result.
What to do
- List every control that operates repeatedly and name its population source system.
- For each, run the population report now and look for blanks in approver, date and linked evidence.
- Fix process gaps first, for example block merges without review in source control settings.
- Agree an evidence folder naming scheme: control ID, period, item ID.
- Ask the auditor for their sampling method and the date they will request populations.
- Do a dry run: pick 10 items per control yourself and walk the evidence.
- Document any known exception before the auditor finds it, with cause and fix.
Quick check
Can I choose which items the auditor samples?
No. The auditor selects. If you pick the items, the test is not independent, and the report would be less useful to readers.
Is one exception in a sample a failed audit?
Not automatically. It is reported as a deviation, and the auditor assesses its effect on the opinion. See our guide on handling control exceptions.
How Safeguard helps automate this
Safeguard's compliance suite keeps controls, evidence and automated tests in one place, so populations can come from connected systems rather than a hand built list. Continuous monitoring flags a control that stops operating between audits, before it shows up as a sampled exception. Technical evidence such as scans and SBOMs comes from your real code and dependencies. Autonomous remediation can open tested fix pull requests for vulnerable dependencies, but it is off by default, every category starts on Manual, and you decide which categories run automatically and at what approval level. Safeguard helps prepare and keep evidence ready. The auditor selects samples and forms the opinion. Book a call to see it.
Sources
- AICPA, Trust Services Criteria (2017, with 2022 points of focus): criteria IDs cited above, paraphrased. The criteria text does not specify sample sizes.
Last reviewed: 18 October 2026.
