If your organization is pursuing SOC 2 compliance, you’ve probably heard the phrase “control testing” repeated more times than you can count. Auditors demand it. Procurement teams check for it. And yet, many companies stumble through the process without a clear picture of what control testing actually involves — and what separates organizations that sail through audits from those that hit unexpected roadblocks.
This guide cuts through the noise. Whether you’re preparing for your first SOC 2 Type II audit or looking to tighten up an existing compliance program, here’s what you need to know about control testing: what it covers, how it works, and what auditors are really looking for.
What Is Control Testing in a SOC 2 Context?
Control testing is the process of verifying that the controls your organization has put in place are not just documented on paper, but actually functioning as intended — consistently, over time.
The distinction matters enormously. Under a SOC 2 Type I audit, an auditor evaluates whether your controls are suitably designed at a single point in time. Under a SOC 2 Type II audit, the bar is higher: the auditor examines whether those controls operated effectively across an observation period, typically six to twelve months. That’s where control testing becomes the centerpiece of the entire compliance effort.
At its core, control testing answers three questions:
- Is the control designed correctly? A control that’s poorly scoped or logically flawed will fail before it’s even put into practice.
- Was the control actually executed? Good intentions don’t count. The control needs to have run — on schedule, by the right people, with the right outputs.
- Is there evidence to prove it? No evidence means no credit. Auditors cannot take your word for it.
The Five Trust Services Criteria and What They Mean for Testing
SOC 2 is built on the AICPA’s Trust Services Criteria (TSC): Security, Availability, Processing Integrity, Confidentiality, and Privacy. Security is mandatory for every SOC 2 audit; the remaining criteria are included based on the nature of your services and what you’ve committed to your customers. Each criterion translates into specific control categories, and each control category comes with its own testing requirements. Here’s a practical breakdown:
Security (CC series — Common Criteria) This is the largest and most scrutinized category. Common Criteria controls span logical access, change management, risk assessment, incident response, vendor management, and more. When testing these controls, auditors look for evidence like access provisioning and de-provisioning records, change tickets with approval trails, and documentation of completed security risk assessments.
Availability If your contracts include uptime SLAs, availability controls are in scope. Testing here involves reviewing uptime logs, incident response documentation, and evidence that backup and disaster recovery procedures have been tested — not just written.
Processing Integrity This criterion covers whether your system processes data completely, accurately, and in a timely manner. Controls often include input validation procedures, reconciliation logs, and error-handling documentation.
Confidentiality Auditors will look for evidence that sensitive data is properly classified, that encryption is applied consistently, and that data sharing is governed by written agreements with appropriate safeguards.
Privacy If personal data is in scope, controls must align with the AICPA’s Generally Accepted Privacy Principles. Testing covers consent mechanisms, data retention schedules, and breach notification procedures.
How Auditors Actually Test Controls
There’s a popular misconception that control testing is just a paper exercise — a checklist you fill out before the audit. That couldn’t be further from the truth, especially for SOC 2 Type II.
Auditors use a combination of four testing techniques:
1. Inquiry The auditor asks questions of relevant personnel to understand how controls work and who is responsible for executing them. Inquiry alone is never sufficient to support a conclusion on operating effectiveness, but it shapes the entire testing approach.
2. Observation The auditor directly observes a control being performed. This is commonly used for physical security controls, change approval meetings, or security awareness training sessions.
3. Inspection The auditor reviews documentation, system screenshots, logs, tickets, and records to verify that a control was executed. This is the workhorse of SOC 2 testing. For a quarterly access review control, for example, the auditor would inspect completed review records, including who performed the review, what was reviewed, and what exceptions were identified and remediated.
4. Re-performance The auditor independently re-executes a procedure to confirm the control produces consistent results. This is typically used for automated controls or configuration-based controls, where the auditor might run a query against your system to verify that access rights match what’s documented.
For any given control, the auditor selects a sample of instances from the observation period and applies these techniques across that sample. The size of the sample depends on the frequency of the control. Daily controls require larger samples than quarterly ones, because there are simply more instances to pull from.
Common Control Testing Failures — and How to Avoid Them
Understanding what causes controls to fail during testing is arguably more valuable than knowing what “good” looks like in theory. These are the most common failure patterns.
- Gaps in evidence A control may have been executed correctly 95% of the time, but if there’s no evidence for that one missing quarter, auditors will flag it. Evidence collection needs to be systematic and continuous — not a last-minute scramble before the audit window closes.
- Inconsistent execution Controls that rely on manual human action are susceptible to inconsistency. If your quarterly access review is supposed to happen within the first two weeks of each quarter but slips to week six once, that’s a timing exception. Automated controls dramatically reduce this risk by removing the human execution variable.
- Ownership gaps If it’s unclear who owns a control, it often falls through the cracks during the audit period. Every control needs a designated owner who is accountable for both execution and evidence.
- Outdated documentation Control descriptions that don’t match what’s actually happening in the environment are a red flag. Auditors look for alignment between the system description (what you say you do) and the test results (what you actually did). Drift between the two raises questions about the integrity of the whole program.
- Inadequate scope A control that covers only production systems but misses a development environment that touches real customer data is a scope gap. Proper scoping is established early, but must be revisited whenever the environment changes.
Building a Control Testing Program That Holds Up Year-Round
The companies that consistently achieve clean SOC 2 reports aren’t doing anything magical — they’ve simply built control testing into their operational rhythm rather than treating it as an audit-season activity. A few principles that separate mature programs from reactive ones:
- Continuous evidence collection. Rather than gathering evidence in the weeks before an audit, effective programs collect and store evidence as controls execute. Compliance automation platforms can connect to your cloud infrastructure, identity providers, and ticketing systems to pull evidence automatically, timestamping records as they’re created.
- Defined testing cadence. Map every control to a testing frequency — daily, weekly, monthly, quarterly, or annually — and build that into a calendar. Testing shouldn’t be an ad hoc event.
- Control owner accountability. Assign every control to a named individual. That person is responsible for execution, evidence, and flagging exceptions when they occur. When an exception does arise, document it, assess its impact, and remediate promptly. Auditors expect exceptions; what they don’t tolerate is silence about them.
- Regular internal walkthroughs. Conduct internal control walkthroughs before the audit begins. These mock testing exercises surface gaps in evidence, identify stale documentation, and give control owners a rehearsal for the real thing. Many organizations treat this as a pre-audit readiness assessment — essentially an audit rehearsal that buys time to fix problems before they land in the official report.
- Remediation tracking. When testing reveals a deficiency, the path to resolution should be tracked and documented. An exception that is discovered, escalated, and remediated with evidence tells a much better story than one that’s discovered by the auditor for the first time.
What a Clean Control Testing Result Actually Looks Like in the Report
Section IV of a SOC 2 report contains the Tests of Controls — the section most scrutinized by clients and procurement teams. For each control, this section describes the auditor’s testing procedures and states whether the control passed or produced an exception.
A clean report doesn’t mean zero exceptions were ever found internally. It means the controls as a whole were suitably designed and operating effectively. Minor exceptions that were promptly remediated may still appear in the report with context. What damages a report — and your credibility with enterprise buyers — are patterns of exceptions, systemic gaps, or controls that auditors couldn’t test because evidence simply wasn’t available.
The Bottom Line
Control testing is the backbone of a credible SOC 2 program. A beautifully written set of policies means nothing if you can’t demonstrate that those policies drove real, consistent action across your organization throughout the audit period.
The organizations that navigate SOC 2 audits most smoothly are those that stopped thinking about control testing as something that happens before an audit and started treating it as something that happens every single day. Evidence is either collected continuously or scrambled for at the last minute — and the difference between those two approaches shows up clearly in the final report. Build the discipline into your operations now. The audit from Global Quality Services will take care of itself.