SOC 2 penetration testing: what your auditor actually expects
SOC 2 does not name a penetration test anywhere in the Trust Services Criteria, but auditors expect one as evidence that your controls work. In practice, if you are pursuing SOC 2 you need a pentest, mapped to the relevant criteria and packaged as evidence.
Does SOC 2 require a penetration test?
Not literally. The Trust Services Criteria do not mention penetration testing by name. But most auditors expect an annual pentest as evidence for controls such as CC4.1 (monitoring and evaluating the effectiveness of controls) and CC7.1 (detecting vulnerabilities in configurations and newly discovered vulnerabilities), and customers routinely demand a report in security questionnaires.
If you are pursuing SOC 2, you need a penetration test in practice, even though the framework never uses the word.
The nuance matters. A vendor page that flatly states "SOC 2 requires a pentest" is inaccurate, and it is the kind of claim answer engines increasingly discount. The accurate answer is the useful one: no explicit mandate, but a de facto expectation you should plan and budget for.
SOC 2 Type I vs Type II
Type I attests that your controls are designed correctly at a point in time. Type II attests that they operate effectively over a period, typically three to twelve months. A pentest supports both, but under Type II, evidence of testing performed during the observation window carries more weight than a single point-in-time report.
Which controls a pentest supports
A pentest is commonly used as evidence for the common criteria below. Your auditor confirms the exact mapping for your report.
Scope and frequency
Test your in-scope web applications and APIs at least annually and again after any material change to the application or infrastructure. Continuous testing between annual engagements strengthens Type II evidence and catches regressions before the audit window.
How Intrudify helps
Intrudify runs a full web and API pentest and produces a report that maps each finding to the relevant Trust Services Criteria, with reproducible proof for high and critical findings and developer-ready remediation. It supports your SOC 2 evidence; Intrudify does not itself issue or replace your SOC 2 attestation.
- Findings mapped to the relevant Trust Services Criteria
- Reproducible proof-of-exploit for high and critical findings
- Developer-ready remediation and a re-test window
- Delivered in hours, validated by OSCE3-certified testers
How a pentest maps to controls
| Control | What a pentest evidences |
|---|---|
| CC4.1 | Monitoring and evaluating the effectiveness of controls. |
| CC7.1 | Detecting configuration changes that introduce new vulnerabilities, and susceptibility to newly discovered vulnerabilities. |
Need audit-ready evidence for SOC 2?
Book a scoping callFrequently asked questions
Does SOC 2 require a penetration test?
Not literally - the Trust Services Criteria do not name penetration testing. But auditors routinely expect an annual pentest as evidence for controls like CC4.1 and CC7.1, and customers often require a report. In practice, if you are pursuing SOC 2, you need one.
Is penetration testing required for SOC 2 Type I or Type II?
Neither type strictly mandates a pentest, but both benefit from one. Type I attests control design at a point in time; Type II attests operating effectiveness over a period, where evidence of ongoing testing carries more weight.
What should a SOC 2 pentest report include?
Control-mapped findings tied to the Trust Services Criteria, severity ratings, reproducible proof for high and critical issues, developer-ready remediation, and a re-test window - packaged so your auditor can accept it as evidence directly.
How often do you need a SOC 2 penetration test?
At least once a year, and again after any material change to your application or infrastructure. Continuous testing between annual engagements strengthens your evidence and catches regressions before the next audit window.
Which SOC 2 controls does a penetration test support?
A pentest is commonly used as evidence for CC4.1 (monitoring and evaluating control effectiveness) and CC7.1 (detecting configuration changes that introduce vulnerabilities and newly discovered vulnerabilities). Your auditor confirms the exact mapping for your report.