SOC 2 and penetration testing: is it required, and how it fits
SOC 2 does not explicitly mandate a penetration test, yet auditors and customers widely expect one. Here is why, how it differs from vulnerability scanning, and what auditors want to see in the report and remediation trail.
Required, or just expected?
The honest answer is that the AICPA Trust Services Criteria never use the phrase "penetration test" or set a mandatory cadence, so on a strict reading it is not required. In practice that distinction rarely matters. The vast majority of auditors treat an annual penetration test as a de facto expectation for SaaS, fintech, healthcare, and cloud companies, because it is one of the cleanest ways to demonstrate the controls the criteria do require. Enterprise customers reinforce this from the demand side, routinely asking to see a recent pen test as part of vendor due diligence regardless of what SOC 2 technically compels. So while you could argue your way out of one, doing so usually creates more friction with both your auditor and your prospects than the test itself would cost.
Where it fits in the criteria
Penetration testing maps most directly to CC7.1, which requires the entity to use detection and monitoring procedures to identify changes that introduce new vulnerabilities and susceptibilities to newly discovered ones. It also supports CC4.1's call for ongoing or separate evaluations of whether controls are present and functioning, since a pen test is a periodic, independent evaluation of exactly that. Because a test exercises detective and response controls rather than merely cataloguing weaknesses, its findings can also touch incident-response and monitoring criteria elsewhere in CC7. The point is that no single criterion says "do a pen test," but several of them are most convincingly satisfied when you have one. Auditors recognize this pattern, which is why the test has become standard practice.
Pen testing versus vulnerability scanning
These are complementary, not interchangeable, and conflating them is a frequent source of audit friction. A vulnerability scan is an automated check that compares your systems against databases of known issues; it provides breadth, runs frequently, and is well suited to the continuous-monitoring side of CC7.1, which expects periodic scanning and rescanning after significant changes. A penetration test provides depth: a skilled tester behaves like a real attacker, chaining findings together to determine whether vulnerabilities are actually exploitable and whether your detective and response controls fire as designed. A scan tells you a door is unlocked; a pen test walks through it to see what an intruder could reach. Most mature programs run frequent automated scans and layer at least one manual penetration test on top of them each year.
Cadence and scope
The prevailing expectation is at least one full penetration test per year, with additional tests triggered by major events such as a significant product release, an architecture change, or a cloud migration that materially alters your attack surface. Scope should reflect what the SOC 2 examination actually covers, typically your production application, external network perimeter, and APIs, and sometimes internal network or cloud configuration depending on the system boundary. Aligning the test timing with your Type 2 observation window is sensible, because it lets findings be remediated and revalidated within the period the auditor reviews. Using an independent, qualified third party rather than the team that built the system strengthens the evidence considerably, since independence is part of what gives the result weight.
What auditors want in the evidence
A pen test report alone does not satisfy an auditor; the remediation story does. Reviewers typically want the full report including methodology, scope, findings, and severity ratings, plus a remediation log showing how each finding was triaged and addressed, and ideally a retest or validation confirming the fixes held. What they are really evaluating is the loop: can you identify a weakness, prioritize it, fix it, and verify the fix within a reasonable timeframe? An open critical finding with no remediation plan is far more damaging than a finding that was promptly closed and revalidated. Treat the test as the start of a documented process rather than a box-ticking certificate, and it becomes one of the strongest sections of your control narrative rather than a liability.