SOC 2 penetration testing requirements
No — and this surprises people. The Trust Services Criteria never use the words "penetration test". SOC 2 is not a checklist of controls; it is an audit of whether the controls you claim are designed properly and, for Type II, operating effectively. Penetration testing is how most organisations satisfy the criteria on vulnerability detection and control monitoring, which is why nearly every SOC 2 report contains one.
Determined by your own stated control, not by the standard. Most organisations commit to annual testing; if your control description says quarterly, the auditor will test you against quarterly.
Whatever your system description defines as the system boundary. Scope mismatch between the system description and the test is one of the more common findings.
Clause by clause.
What the standard says, rather than what a vendor says it says. Quote these references directly when you are asked to justify a testing programme internally.
| Reference | Requirement |
|---|---|
| CC4.1 Monitoring of controls | The entity selects, develops and performs ongoing and separate evaluations to ascertain whether the components of internal control are present and functioning. A penetration test is a separate evaluation in exactly this sense — an independent check that controls work, rather than an assertion that they exist. |
| CC7.1 Detection and monitoring | The entity uses detection and monitoring procedures to identify changes to configurations that introduce new vulnerabilities, and susceptibilities to newly discovered vulnerabilities. This is the criterion most directly satisfied by regular testing. |
| CC7.2 Monitoring for anomalies | The entity monitors system components for anomalies indicative of malicious acts, natural disasters and errors. Penetration test activity is frequently used as a live check that this monitoring actually fires. |
| CC3.2 Risk identification | The entity identifies risks to the achievement of its objectives and analyses them as a basis for determining how they should be managed. Test findings are a primary input to that analysis. |
What the assessor wants to see.
Work through it here. Progress is kept in your browser, and copy or print drops it straight into an audit folder.
Tick what you already hold. Progress is saved in this browser only — nothing is sent anywhere — and copy or print puts it into your audit folder.
Where people lose the point
- Testing once and reusing the report across multiple audit periods. For Type II, the evidence must fall inside the observation window.
- Writing a control that promises more than you deliver — "quarterly penetration testing" in the system description and one test in the file is a clean exception.
- Scoping the test more narrowly than the system description, so the audit covers systems the test never touched.
- Treating a vulnerability scan as satisfying CC7.1 when your own control description says penetration test.
- Leaving high findings open at period end with no documented risk acceptance.
SOC 2 and penetration testing
Does SOC 2 Type I require a penetration test?
How recent does the penetration test have to be for SOC 2?
Can we use an automated penetration testing platform for SOC 2?
For the longer narrative treatment — worked examples, cost and timing — read SOC 2 Type I vs Type II pentesting: the full guide.
The other frameworks
PCI DSS v4.0
Yes. PCI DSS is the one framework on this page that names penetration testing outright and tells you how oft…
HIPAA Security Rule
Not explicitly, as the rule stands. The HIPAA Security Rule requires a periodic technical and non-technical …
Cyber insurance
There is no standard to comply with, which makes this the most misunderstood item on the list. Whether a pen…
Or compare all four side by side in the penetration testing compliance requirements guide.
Testing that produces evidence, not just findings.
Reports mapped to the control they satisfy, with a replayable record behind every finding — which is what an assessor asks for when they push back.