Short answer: no. SOC 2 does not explicitly require a penetration test.
Longer answer: try showing up to a SOC 2 Type II audit without one and see what happens. Or better yet, try sending your SOC 2 report to an enterprise security team without a pentest to accompany it and see how far you get.
The gap between what SOC 2 technically requires and what auditors and enterprise buyers actually expect is where most SaaS founders get tripped up. This post explains that gap clearly so you can make an informed decision rather than a surprised one.
What SOC 2 Actually Says
SOC 2 is built around the AICPA’s Trust Services Criteria. It is a principles-based framework, which means it defines what your security program should achieve rather than prescribing exactly how you achieve it. Nowhere in the Trust Services Criteria will you find the words “penetration test” listed as a mandatory requirement.
The criteria most directly relevant to this question are CC4.1 and CC7.1.
CC4.1 covers monitoring activities and specifically mentions that management should use “a variety of different types of ongoing and separate evaluations, including penetration testing” to ascertain whether controls are present and functioning. The word “including” is doing a lot of work here — it signals that penetration testing is one acceptable method, not the only acceptable method.
CC7.1 covers system monitoring and requires that you use detection and monitoring procedures to identify changes that introduce new vulnerabilities and susceptibilities to newly discovered vulnerabilities. This is most commonly satisfied through vulnerability scanning, but a pentest conducted during the observation period is strong supporting evidence.
Neither criterion makes a pentest mandatory on its own. The framework is flexible by design.
Why Auditors Expect It Anyway
The gap between what the framework says and what auditors expect has grown significantly over the past several years as enterprise SaaS breaches have multiplied and audit firms have updated their internal expectations accordingly.
By 2026, asking “do you do pen testing?” is as routine for a SOC 2 auditor as asking “do you have a change management policy?” It is simply expected.
The practical reality is this: for a SOC 2 Type II report, which evaluates whether your controls were effective over an observation period of six to twelve months, a penetration test conducted during that period is the strongest evidence you can provide that your security controls actually work under real conditions — not just that they are documented. An auditor reviewing CC4.1 can accept other forms of evidence, but a credible pentest report from a qualified firm is the cleanest, most direct way to satisfy the requirement.
Organizations that skip pentesting or fail to document their remediation efforts typically face significant challenges during Type II audits and may struggle to receive unqualified reports.
This does not mean a missing pentest automatically fails your audit. But it does mean your auditor will ask questions, potentially identify a weakness in your vulnerability management controls, and leave it to you to demonstrate through other means that your security posture is sound. That is a harder conversation than simply having the report.
Why Enterprise Buyers Make It Mandatory Regardless
Even if your auditor were willing to accept alternative evidence, your enterprise customers will not be. SOC 2 auditors do not require a penetration test, but your customers effectively do. For B2B SaaS companies pursuing enterprise deals, pentests are effectively mandatory because buyers expect and often require them.
Here is how this typically plays out. A founder spends six months and significant money getting their SOC 2 Type II report. They send it to a prospective enterprise customer. The customer’s security team reviews it, nods at the audit opinion, and then asks: “Can you share your most recent penetration test report?”
If the answer is no, the deal slows down. The security team escalates for a risk exception. You get asked to complete a more detailed security questionnaire. The sales cycle extends by weeks or months. In some cases the customer requires you to get a pentest done before they will proceed, which means you are now doing it under time pressure rather than on your own timeline.
The SOC 2 report opens the door. The pentest closes the deal.
Which Trust Services Criteria Does a Pentest Support
Understanding this mapping is useful both for scoping your pentest correctly and for presenting results to your auditor.
CC4.1 is the primary criterion. A pentest directly satisfies the requirement for separate evaluations to verify that controls are present and functioning. When auditors review your CC4.1 evidence, a pentest report with documented findings, severity ratings, and remediation evidence is the most direct and convincing thing you can provide.
CC6.6 requires security measures against threats from outside the system boundaries. An external network penetration test and web application test are direct evidence that you have evaluated your external attack surface.
CC7.1 supports the monitoring activities criterion. A pentest conducted during the observation period demonstrates that your vulnerability management program goes beyond automated scanning to include human-led validation.
For SaaS companies pursuing the Confidentiality or Availability criteria in addition to Security, a pentest also supports C1.1 and A1.2 by demonstrating that you have evaluated whether customer data could be accessed or systems disrupted by an attacker.
What Good Looks Like for a SOC 2 Pentest
Auditors are not just looking for evidence that a pentest was performed. They are looking for evidence that a credible pentest was performed, that findings were tracked, and that critical and high-severity issues were remediated before the audit window closed.
The report should be from a qualified firm with credentialed testers — OSCP, OSWE, or similar. It should document the scope clearly, showing that in-scope systems are the same systems covered by your SOC 2 report boundary. It should include methodology, findings with severity ratings, proof-of-concept evidence for exploitable vulnerabilities, and remediation recommendations.
Crucially, your auditor wants to see what you did with the findings. A pentest report full of critical vulnerabilities with no documented remediation is worse than no pentest at all — it proves you knew about significant security gaps and did not address them. The remediation documentation and retest evidence are as important as the initial findings report.
Timing matters for Type II. The pentest should be conducted during the observation period, not in the weeks immediately before the audit window opens. An auditor reviewing a 12-month observation period wants to see testing that falls within that period. Best practice is to conduct the test in the early-to-middle portion of the observation window so you have time to remediate findings and document the retest before the audit fieldwork begins.
The Honest Bottom Line
If you are pursuing SOC 2 to close enterprise deals and you are asking whether you can skip the pentest to save money or time, the answer for most SaaS companies is no — not because the framework requires it, but because your buyers do, and because showing up to an enterprise security review with a SOC 2 report but no pentest puts you in an uncomfortable position that the report was designed to avoid.
The right time to get a pentest done is before your observation period begins, not after an enterprise customer asks for one. A proactive pentest lets you remediate findings quietly, present clean evidence to your auditor, and share a current report with prospects from a position of confidence rather than scrambling.
Packet33 conducts web application, API, and external network penetration tests for SaaS companies, with reports scoped and documented for SOC 2 Trust Services Criteria. We can help you time your test to the observation window and present findings in a format your auditor will recognize.
Talk to us about scoping a pentest aligned to your SOC 2 timeline.