If you're pursuing SOC 2, one question comes up almost immediately: do we have to run a penetration test?
The short answer is that SOC 2 never uses the words "you must perform a penetration test." The more useful answer is that in practice, auditors routinely expect one, and skipping it tends to create friction you'd rather avoid.
Here's what the requirement really looks like, and how to scope a test that holds up under audit.
What SOC 2 Is
SOC 2 is a reporting framework governed by the AICPA. It evaluates whether the controls protecting your systems and customer data are designed well and, in the case of a Type II report, whether they actually operate over time.
There are two report types worth distinguishing.
-
SOC Type I report assesses your controls at a single point in time.
-
SOC Type II report evaluates how those controls perform across a review period, typically three to twelve months.
The Five Trust Services Criteria
SOC 2 is built on five Trust Services Criteria. Every organization must address Security (the "common criteria," and the only mandatory category). The other four are included based on what you promise customers: Availability (your systems stay operational), Processing Integrity (data is handled accurately and on time), Confidentiality (sensitive information is protected), and Privacy (personal data is governed appropriately).
Security is where penetration testing earns its place.
Where Testing Fits In
Two points in the Common Criteria are the reason pentests keep showing up in audits:
- CC4.1 directs organizations to evaluate whether controls are functioning, and explicitly names penetration testing as an accepted method of doing so.
- CC7.1 points to vulnerability scanning as a way to monitor systems for new configuration weaknesses.
Neither clause hard-mandates a test. But both make it the clearest, most defensible evidence you can hand an auditor. When CC4.1 asks "how do you know your controls work?" a current third-party penetration test is a far stronger answer than a policy document.
Penetration Testing vs. Vulnerability Scanning
These get conflated constantly, and the distinction matters for SOC 2.
A vulnerability scan answers "what weaknesses might exist?" It's largely automated, flagging outdated software, missing patches, misconfigurations, and exposed services. It's broad, fast, and cheap, but it produces false positives and doesn't prove anything is truly exploitable.
A penetration test answers "what can an attacker actually do?" It validates findings through realistic attack scenarios, chains vulnerabilities together, and demonstrates genuine business impact. Scanning tells you the door might be unlocked; a pentest walks through it and shows you what's in the room.
For SOC 2, they're complementary. Scanning supports ongoing monitoring (CC7.1); penetration testing provides the point-in-time control validation auditors want (CC4.1).
Scoping a SOC 2 Penetration Test
A defensible scope generally covers anything that touches customer data or sits in the trust boundary: customer-facing web and mobile applications, administrative interfaces, APIs, external network perimeter, and cloud infrastructure. If internal systems process customer data, they belong in scope too.
On effort, most engagements land somewhere in the range of 5 to 25 person-days depending on the size and complexity of your environment, larger application footprints and more integrations push it upward.
Common Questions
Does a bug bounty program count? It can supplement a formal test, but auditors generally don't accept it as a replacement. A bounty is continuous and unstructured; SOC 2 wants a scoped, documented assessment.
Can we test ourselves? Internal testing has value, but a third-party test carries more evidentiary weight. Independence is part of what makes the finding credible.
How often? Annually is the working standard, plus an additional test after any significant change to your infrastructure or applications, a major release, a cloud migration, a new customer-facing product.
The Takeaway
SOC 2 won't technically force you to run a penetration test. But between CC4.1 and CC7.1, and the expectations of both auditors and the enterprise customers reading your report, a well-scoped annual test is the path of least resistance, and the one that actually strengthens your security rather than just checking a box.
Preparing for SOC 2? Ramparts delivers risk-driven, evidence-based penetration testing built around real-world attack paths, not generic checklists.
Our attack/fault-tree methodology (co-authored with NIST, SP 1800-1) prioritizes your most critical assets and produces the kind of clear, actionable findings auditors and executives both understand. Get in touch to scope an assessment that maps to your SOC 2 goals.
