No SOC 2 criterion contains the words "penetration test." If you read the AICPA Trust Services Criteria looking for a clause that mandates one, you will not find it. Yet almost every SOC 2 Type II report you will ever see includes a pentest, and most auditors will flag its absence. That gap between the letter of the standard and audit reality is what trips up first-time SOC 2 teams.
This post explains exactly where a pentest fits into SOC 2, which Trust Services Criteria it maps to, how Type I and Type II differ, what cadence and scope auditors actually expect, and how to avoid paying for testing you do not need. We will be precise about "required" versus "expected."
No, SOC 2 does not strictly require a penetration test. SOC 2 is an attestation against the AICPA Trust Services Criteria (TSC), and none of those criteria name penetration testing as a mandatory control.
What SOC 2 requires is that you define controls meeting the relevant criteria and then show they operate effectively. A pentest is the most common and most credible piece of evidence for several of those criteria, which is why auditors expect to see one. The distinction matters: you choose your controls, and you choose how to satisfy each criterion. A pentest is a strong choice, not a checkbox the AICPA ticks for you. If you skip it, expect your auditor to ask how else you detect exploitable vulnerabilities, and to be skeptical of the answer.
Penetration testing most directly supports the monitoring criterion CC4.1 and the security operations criteria in the CC7 series. These are the points where an auditor reasonably expects independent technical validation.
You are not testing for a clause called "pentest." You are producing evidence that the controls you claimed under CC4.1 and CC7.x actually work. For how this evidence flows into an audit, see how Strobes penetration testing supports compliance audits.
A SOC 2 Type I report attests to whether your controls are suitably designed at a single point in time, while a Type II report attests to whether they operated effectively over a review period, typically three to twelve months. Pentesting carries far more weight in a Type II.
For a Type I, you can sometimes pass on control design alone, with a pentest as supporting evidence rather than a hard expectation. For a Type II, the auditor samples your operating effectiveness across the whole window, so a pentest performed during that period is close to non-negotiable in practice. The pentest report, dated inside the review period, becomes a concrete artifact showing your vulnerability detection control ran and produced action. Most organizations going for Type II schedule the pentest early in the window so they have time to remediate and, ideally, retest before the audit closes.
The practical cadence is at least once per audit period, which usually means annually, plus a fresh test after any significant change to the in-scope system. SOC 2 itself sets no fixed interval, so this is convention, not a clause.
Scope follows your defined system boundary, the same boundary your SOC 2 report describes. That typically includes the production application, its APIs, the supporting cloud infrastructure, and authentication and authorization paths. It usually excludes corporate IT that sits outside the system description. Get the scope wrong and you either overpay for out-of-scope testing or leave an in-scope component untested, which the auditor will catch. If you are deciding how frequently to test beyond the minimum, our guide on penetration testing frequency walks through the risk-based math, and how to prepare for a penetration test covers scoping the engagement cleanly.
Auditors want an independent, methodology-driven test with a dated report, named scope, severity-rated findings, and evidence of remediation. A raw vulnerability scan export does not count, and auditors increasingly know the difference.
Use a recognized methodology so the report is defensible: OWASP WSTG and ASVS for web applications, the OWASP API Security Top 10 for APIs, and PTES or NIST SP 800-115 for the overall engagement structure. Findings should carry CVSS scores so the auditor can see severity and prioritization. Critically, the auditor cares as much about what you did after the test as the test itself: a report full of highs with no remediation evidence reads worse than a clean follow-up. Continuous approaches such as agentic pentesting help here, because you keep producing dated, in-period evidence across the whole review window instead of relying on a single annual snapshot. For the difference between a real pentest and a scan, see what penetration testing is.
