An auditor testing a control that ran hundreds of times does not inspect every instance. They pick some, and test those. Which ones they pick, and how many, decides what evidence you need to have, and the answer surprises most first-time teams: you need evidence for all of them.
This article explains how sampling works in a SOC 2 Type II, what drives the sample size, how items get selected, and what happens when one fails. It ends with how ISO 27001 certification audits sample, which works on different principles.
Why auditors sample at all
Testing every instance of a frequent control is rarely practical and rarely necessary. Professional standards let the auditor test a portion of a population and draw a conclusion about the whole, provided the sample is selected so it could represent the whole.
For SOC 2, most firms use nonstatistical sampling. The sample size comes from the firm's own methodology rather than a probability calculation, and the AICPA does not publish a mandatory table. That is why two firms can test the same control with different sample sizes and both be right.
The conclusion the auditor draws is about the control, not the items. A clean sample supports an opinion that the control operated effectively across the period. A sample with a failure raises the question of how many other failures the population contains.
What sets the sample size
Firms vary, but the same factors drive the number almost everywhere.
How often the control runs. This is the largest factor. An annual control, such as the yearly risk assessment, usually has one instance in the period, and the auditor tests that one. A quarterly control has a handful, and the auditor may test some or all of them. A control that runs daily, or every time a change is deployed, has a large population and gets a larger fixed sample.
Whether the control is manual or automated. For an automated control, many firms test a single instance, on the reasoning that a system configured once behaves the same way every time. That reasoning holds only if the auditor is also satisfied with the general IT controls that stop the configuration changing unnoticed: change management and access to the system. If those are weak, expect a larger sample.
How much risk the control carries. A control that addresses a significant risk, or that other controls depend on, may get a larger sample.
Whether deviations are expected. If walkthroughs or prior years suggest the control is not always followed, the auditor may plan a larger sample from the start.
How the items get selected
The auditor selects the items, not you. You provide the population, a complete list of every instance of the control in the period, and the auditor chooses from it.
Selection methods vary by firm. Some generate random selections. Some use systematic selection, taking every nth item from a random starting point. Some use haphazard selection, picking without a pattern. All of them aim to give every item a chance of being chosen and to spread the sample across the whole period.
Two consequences follow.
The population has to be complete. If the list you provide leaves out instances, the sample cannot represent the period, and the conclusion fails. Auditors therefore test the population itself, asking how it was generated and checking it against another source. A population you assembled by hand will get more scrutiny than one exported from the system of record.
Every item needs its evidence. Because you do not know which items will be chosen, every instance of the control has to have produced its evidence when it ran. The types of audit evidence the auditor accepts for each item depend on the control, but they have to exist for all of them.
Some firms split testing into two visits. They sample the first part of the period during interim fieldwork, then sample the remainder after the period ends. The population request comes twice, and each list has to be complete for its part of the period.
What happens when a sample item fails
A sampled item that does not show the control operating is a deviation. A change merged without approval, a terminated user whose access was removed late under your own policy, a quarterly review completed after the quarter ended.
What follows depends on the firm and the control.
The auditor asks what happened. Your explanation does not erase the deviation, but it shows whether it was an isolated miss or a sign the control does not work.
The auditor may extend the sample. Some firms test additional items to see whether the deviation is isolated. Others note the deviation and move on.
The deviation is reported. In a SOC 2 Type II, the tests and results section of the report describes each deviation found. Readers of the report will see it.
The auditor evaluates the effect. A deviation does not automatically change the opinion. The auditor considers whether, with the deviation, the relevant criteria were still met, which can depend on other controls that cover the same risk.
You cannot swap a failed item for a clean one, and you should not try to produce evidence after the fact for an item that lacks it. Backfilled evidence is worse than a reported deviation, because it calls into question everything else you have provided.
How ISO 27001 certification audits sample
A certification audit samples too, but the logic is different.
An ISO 27001 auditor is not testing a defined population of control instances toward an opinion. They are gathering enough evidence to judge whether your ISMS conforms to the standard and is effective. The time available is fixed in advance: certification bodies calculate audit days from your organization's size and complexity using the rules in ISO/IEC 27006-1.
Within that time, the auditor samples by judgment. They choose records, processes, people, and Annex A controls to examine, and they follow trails that look weak. They might ask for three recent starters' onboarding records, pick two suppliers from your list, or select changes from the last few months. Organizations with several sites can have their sites sampled too, under accreditation rules for multi-site certification.
Over a three-year certification cycle, surveillance audits cover different parts of the ISMS each year, so not every control is examined every year. The ISO 27001 framework page covers the cycle in outline. The practical lesson is the same as for SOC 2: the auditor picks, so every record has to be in order.
Preparing for the sample
Know the population source for every control that runs more than once a year.
Keep each instance's evidence with the instance, not in a folder assembled later.
Check your own population against a second source before the auditor does.
Run a small sample yourself, picked at random, before fieldwork. If you would fail it, so would the auditor.
Treat a deviation you find early as a reason to fix the process, not to tidy the record.
Terms like population, deviation and sample are defined in the glossary if a colleague needs them.
How TrustLynce helps
The auditor portal holds the population, the auditor's selections and the evidence for each sampled item in one place, so nobody rebuilds the list from email. Evidence collected on a schedule means each instance has its record from the day it ran.