SOC 2 doesn't explicitly require a penetration test, but almost every credible Type II is supported by one. SOC 2 is built on the AICPA Trust Services Criteria, and pentesting is the standard evidence for the risk-assessment and monitoring criteria (and it supports logical access/operations). Auditors expect it; enterprise customers reading your report ask for it by name. It matters most for Type II (effectiveness over a window) - the test should fall within the observation window with criticals remediated. Book it 6–10 weeks before the window closes so you can fix and retest. The platform won't run it — see Vanta/Drata/Secureframe. Detail below.
// 01 The honest answer
Search “does SOC 2 require a penetration test” and you'll get contradictory answers, because the true one has two halves. Technically: no. SOC 2 doesn't contain a control that says “perform a penetration test.” It's a principles-based framework built on the AICPA Trust Services Criteria, which describe outcomes to achieve, not specific activities. Practically: yes, effectively. A penetration test is the standard, recognised evidence that you meet the criteria around identifying and managing vulnerabilities and monitoring your controls - and auditors routinely expect to see one. So the accurate framing is: not named, but expected. Treating it as optional because it isn't spelled out is the misread that leads to awkward questions from both your auditor and your prospects.
// 02 The criteria that drive it
Risk assessment
You must identify and assess risks - including from vulnerabilities. A pentest supplies the objective input.
Monitoring controls
You must monitor the effectiveness of controls. Testing evidences that they actually work.
Logical access
Testing validates that access controls resist attack - a core common-criteria concern.
System operations
Demonstrates you detect and respond to security events and weaknesses.
No single criterion mandates a test - but the risk and monitoring criteria are hard to evidence convincingly without one, which is why testing appears in virtually every mature SOC 2 programme. It's the same “outcome, not activity” logic as ISO 27001.
// 03 What auditors and customers actually want
Two audiences make the pentest effectively mandatory. First, your auditor: they're looking for evidence that you actively identify and address vulnerabilities, and a recent, competent penetration test is the cleanest way to show it. Its absence prompts questions about how you meet the risk and monitoring criteria. Second - and often more decisive commercially - your customers: the enterprise prospects who read your SOC 2 report frequently ask for the penetration test specifically, sometimes via a security questionnaire. A SOC 2 with no pentest evidence can stall a deal even if the auditor accepted it. So the test isn't just about passing the audit - it's about the report doing its real job: unlocking sales. That dual purpose is why skipping it is false economy.
// 04 Type I vs Type II & timing
The requirement bites hardest for Type II. A Type I report assesses whether controls are suitably designed at a point in time; a Type II assesses whether they operated effectively over a period (commonly 3–12 months). Because a penetration test demonstrates the ongoing effectiveness of security controls, it's most relevant to Type II, and the test should fall within the observation window with critical findings remediated - open criticals at window-close are themselves an audit concern. For Type I, a recent test still strengthens the report and reassures customers, but the window-timing pressure is a Type II thing. The practical rule for Type II: book 6–10 weeks before the window closes, leaving room to fix and retest - the same discipline as preparing for any test. And remember your compliance platform (Vanta, Drata, Secureframe) flags the gap but doesn't run the test.
// 05 Making one test serve the audit (and more)
The efficient move is to scope a single engagement that does multiple jobs. Scope it to your in-audit-scope systems so it evidences SOC 2; ask for a report that maps to the Trust Services Criteria; keep an attestation letter ready for the customers who ask; and - if you're a GCC organisation - scope it so the same test also covers your local regulator (CBB, NCA) or the PDPL. Done well, one well-scoped, human-led test satisfies the auditor, arms your sales team, and can serve regional compliance at once. Choose the provider on the right questions, not lowest price - a cheap scan-in-disguise that your auditor or a sharp customer rejects is the costliest option. For the full picture across regimes, see requirements by framework.
// 06 Frequently asked questions
Does SOC 2 require a penetration test?
Not as an explicit, mandatory control, but almost every SOC 2 Type II report is supported by one. SOC 2 is based on the AICPA Trust Services Criteria, and pentesting is the standard evidence for the risk-assessment and monitoring criteria. Auditors expect a recent test and enterprise customers reading your report ask for it by name. It's effectively expected for a credible SOC 2.
Which criteria relate to penetration testing?
Most directly the common criteria around risk assessment and monitoring of controls - identifying and assessing risks including from vulnerabilities, and monitoring control effectiveness. It also supports logical access and system operations criteria. Being principles-based, no single criterion says 'perform a pentest', but testing is the recognised way to evidence the risk and monitoring criteria.
Type I or Type II?
It matters most for Type II. Type I assesses control design at a point in time; Type II assesses operating effectiveness over a period (3–12 months). Because a pentest demonstrates ongoing effectiveness, it's most relevant to Type II, and should fall within the observation window with criticals remediated. For Type I a recent test still helps, but the window-timing pressure is specific to Type II.
When should I run it?
Early enough to remediate and retest before your Type II window closes - a practical rule is 6–10 weeks before window-end. Uploading a report full of open criticals just before the deadline is the most common avoidable problem, since open criticals at window-close are an audit concern. Time the test to your window, not the last minute.
// 07 Related reading
- Pentest for Vanta / Drata / Secureframe users — the platform won't run it.
- We failed our SOC 2 audit — what next and how to prepare.
- Requirements by framework and vendor security questionnaires.