Testing in SOC 2
Where the duty to run a pen test or a restore test comes from.
Founders often ask whether SOC 2 forces a penetration test or a disaster recovery test. The criteria describe results, not activities, so the short answer is no. The obligation arrives by three other routes: the controls you write into your description, the commitments you make to customers, and what the buyers reading your report expect to see.
Back to SOC 2 services01 · Three routes
Three ways a test becomes compulsory
None of them is a sentence in the criteria naming the test.
- Your control textOnce the description says a test happens, the auditor checks that it happened, as often and as fully as written.
- Your service commitmentsAn uptime promise or a recovery-time clause in a contract is a commitment your controls must support. Recovery testing is the usual way to show they can.
- Your buyers' expectationsEnterprise security reviewers commonly expect a yearly independent penetration test whatever your report says. That is market pressure, not an audit rule.
Only the first route is enforced by the examination itself. The second decides which criteria matter most and how hard they bite. The third decides whether a clean report still leaves your sales team fielding follow-up questions.
02 · The criteria map
Where testing touches the Trust Services Criteria
The outcome each criterion wants, and the test that commonly serves as evidence for it.
| Criterion | The outcome it asks for | Test that often supports it |
|---|---|---|
| CC4.1 | Management evaluates whether the parts of internal control are present and working | A penetration test, one of several separate evaluations listed as points of focus |
| CC7.1 | Monitoring picks up configuration changes and newly found vulnerabilities | Scheduled vulnerability scanning, with a pen test adding depth |
| CC7.5 | The entity recovers from security incidents it has identified | Restore exercises built around incident scenarios |
| CC9.1 | Risks from business disruption are identified and mitigated | Continuity and recovery testing |
| A1.2 | Backup and recovery infrastructure is in place and kept up | Backup job monitoring and restore checks |
| A1.3 | The recovery plan is put to the test | A recovery exercise with recorded results |
A point of focus is a prompt for applying a criterion, not a requirement. The auditor judges your controls against the criterion, so leaving out a pen test is not an automatic failure if other evaluations satisfy CC4.1. A1.2 and A1.3 apply only when Availability is in scope.
03 · Control wording
Writing the control you will be held to
Every number and trigger in a control sentence is a separate thing to prove.
Hard to evidence
Illustrative wording
- “Systems are tested regularly for weaknesses and recovery.”
- “Critical findings are fixed promptly.”
- “Backups are tested.”
Testable
Illustrative wording
- “An independent firm tests the production application and its APIs once a year and after major architecture changes.”
- “Critical and high findings are fixed, or formally risk-accepted, within the windows in the vulnerability policy.”
- “Each quarter, engineering restores a production database backup to an isolated environment and records the time taken and the data recovered.”
Vague text does not lower the bar. It leaves the auditor to decide what “regularly” means, and their reading may be stricter than yours.
- A frequency the window cannot hold. A quarterly restore inside a short period leaves one occurrence to sample. Miss it and there is nothing.
- Frequencies copied from a template. A template that says monthly creates a monthly duty, even where your risk supports twice a year.
- A trigger no one tracks. “After significant change” means showing which changes qualified and that each one led to a test.
- Restore promised, conversation delivered. If the control says data is restored, minutes from a walkthrough meeting are not evidence of it.
04 · Leaving a test out
What happens if your description names neither test
Silence is allowed. It moves the burden to other controls.
- The auditor has no pen-test control to sample, but still has to conclude that CC4.1 and CC7.1 are met by something you do describe.
- With Availability in scope, some form of recovery testing is hard to avoid, because A1.3 is about exactly that.
- A test you run but never describe still helps: it can support other controls, and buyers can request it separately.
- Buyers who expect a pen test will ask for its summary regardless, so the cost of the test rarely disappears.
Describe what you will sustain
The right control is the one you can repeat without heroics for the whole period. Ambition belongs in the roadmap, not in the system description.
05 · The calendar
Fitting both tests inside the observation period
In a Type 2, the auditor can only sample what happened inside the window.
- Mark the period's first and last day before booking either test.
- Place the penetration test early enough that findings, fixes and the retest all fall within the window.
- Place the recovery exercise where its results can be set against your stated RTO (time to recover) and RPO (data you can afford to lose) before the period closes.
- If a test lands just before the period starts, expect questions on whether its findings were closed during it.
- For a Type 1 there is no window: the auditor looks at whether the control is designed and in place on the report date.
Once the duty is settled, two other pages take over: what an auditor looks for inside a penetration test report, and how to design a restore test that can be sampled.
- Penetration testing for SOC 2What auditors look for in a test report, and what they ignore.
- Backup and recovery tests that satisfy SOC 2Designing a test an auditor can sample and trust.
Sources: AICPA, TSP section 100, 2017 Trust Services Criteria for Security, Availability, Processing Integrity, Confidentiality, and Privacy (with revised points of focus, 2022); AICPA guide, SOC 2 Reporting on an Examination of Controls at a Service Organization; AT-C section 205.
06 · Go deeper
Go deeper
Dedicated pages on topics this guide only touches.
Questions about testing duties
Our description never mentions a pen test. Will the auditor flag it?
Not as a missing control, if other controls cover the criteria.
The examination tests what you describe against the criteria. If your monitoring and evaluation controls meet CC4.1 and CC7.1, the absence of a pen test is not an exception. Your buyers may still ask for one.
Can our own engineers run the penetration test?
The criteria allow it. Buyers may not be satisfied.
Nothing in the criteria demands an outside tester. The auditor checks that the control was performed as written, including any claim about the tester's independence. Many buyers still prefer a report from a separate firm.
Does our cloud provider's resilience count as our recovery test?
Only for the layers the provider runs.
The provider's own report covers its infrastructure. Restoring your databases, configuration and application remains your control, and needs your own evidence.
Without Availability in scope, do we still need a recovery test?
Not under A1.3. Recovery still matters elsewhere.
A Security-only report does not include A1.3, but CC7.5 and CC9.1 still ask how you recover from incidents and disruption. A modest, well-documented restore exercise is a common way to answer them.
Write test controls you can keep.
A SOC 2 readiness assessment from Auditify checks that each testing control says what you really do, and that your calendar lets you prove it.