SOC 2 Penetration Testing: Requirements & What Auditors Expect
Search "is penetration testing required for SOC 2" and you'll get a technically correct but practically useless answer: no, it isn't named as a line item. Search "will I pass my SOC 2 audit without one" and the honest answer flips. Here's what's actually going on, which controls a pentest is evidence for, how often to run one, and what auditors want to see in the report.
Is penetration testing actually required for SOC 2?
Not literally. The AICPA's Trust Services Criteria, which SOC 2 is built on, don't contain a line that says "perform a penetration test." That's the technically accurate answer, and it's also the reason so much confusion exists — because in practice, auditors treat penetration testing as the expected form of evidence for two specific criteria, and its absence is one of the most common gaps flagged during readiness assessments.
- CC4.1 — Monitoring of controls. The organization must evaluate whether its controls are actually operating. A penetration test is direct evidence that security controls were tested under adversarial conditions, not just documented on paper.
- CC7.1 — Vulnerability detection. The organization must have a process to identify vulnerabilities in its systems. Auditors increasingly expect this to include exploitation-led testing, not just automated scanning.
The practical rule of thumb: treat it as required even though it isn't required on paper. A Type II report covering an observation period with no penetration test is a report your auditor will very likely push back on, and a gap your customers' security teams will notice during vendor review regardless of what the letter of the criteria says.
How often should you test?
Annually is the common baseline auditors expect, timed to align with your Type II observation period. But "annually" is a floor, not a target worth optimizing for. A penetration test run in month one of a twelve-month observation window says very little about your security posture in month eleven, after several releases and infrastructure changes. Organizations shipping frequently are increasingly testing more often — quarterly, or continuously through a PTaaS model — specifically because a single point-in-time snapshot ages out of relevance well before the audit period closes.
What auditors actually look for in the report
| Evidence auditors want | Why it matters for the audit |
|---|---|
| Scope matching your system description | Confirms the test actually covered the systems in your SOC 2 boundary |
| Genuine exploitation, not just scanning | A raw vulnerability scanner export is weak evidence for CC4.1/CC7.1 on its own |
| Findings with severity and clear status | Auditors need to see what was found, not just that testing "happened" |
| Remediation evidence for critical/high findings | An open critical finding with no remediation plan is a real audit risk |
| Retest confirmation | Proves fixes actually closed the gap rather than being marked done on trust |
| Tester independence | Some auditors expect testing performed by a party independent of the engineering team that built the system |
The scan-versus-pentest distinction is worth being explicit about, because it's the single most common shortcut that creates audit friction: an automated vulnerability scan identifies known issues without confirming they're exploitable, and carries a meaningfully higher false-positive rate. A genuine penetration test actively attempts exploitation to prove real-world impact. Auditors are increasingly able to tell the difference between the two kinds of report, and a scan presented as a pentest is a credibility problem waiting to surface during review.
"SOC 2 doesn't say the word 'penetration test.' Your auditor will still ask where it is."
Scoping a SOC 2 penetration test
Scope should match your SOC 2 system description — the production environment, applications and infrastructure actually in your audit boundary, not a broader or narrower set. Common scoping mistakes worth avoiding: testing only the marketing website while the actual product application sits outside scope; excluding APIs that process the same customer data as the tested web app; and treating a staging environment test as equivalent evidence for a production system. If your system description names specific components, your penetration test scope should be traceable back to that same list.
How ComplyArmor supports SOC 2 evidence
ComplyArmor's Smart PTaaS maps every validated finding to specific SOC 2 control clauses — including CC6.1, CC4.1 and CC7.1 — alongside OWASP Top 10, ASVS, PCI-DSS and ISO 27001, so a single engagement produces evidence auditors can trace directly to the criteria they're testing against. See our full compliance mapping page for how findings correlate across frameworks, and our PTaaS page for how continuous testing keeps that evidence current through the whole observation period rather than going stale after month one. If your AI agents or LLM features are in scope for your SOC 2 boundary specifically, see our dedicated piece on SOC 2 compliance for AI agents.
Frequently asked questions
Is penetration testing required for SOC 2?
Not literally — the SOC 2 Trust Services Criteria don't name "penetration test" as a mandatory line item. In practice, most auditors treat it as the expected evidence for CC4.1 (monitoring of controls) and CC7.1 (vulnerability detection), especially for Type II reports, and will flag its absence as a gap. Treat it as required in practice even though it isn't required on paper.
How often do you need a penetration test for SOC 2?
Annually is the common baseline auditors expect, aligned to the observation period of a Type II report. Organizations with frequent releases increasingly test more often than once a year, since a test from month one of a twelve-month observation period says little about security in month eleven.
What does a SOC 2 auditor look for in a penetration test report?
Evidence of genuine exploitation rather than an automated scan, a clearly defined scope matching your system description, findings with severity and remediation status, and proof that critical or high findings were actually remediated and retested — not just logged. A raw vulnerability scanner export is generally insufficient on its own.
What's the difference between a vulnerability scan and a penetration test for SOC 2?
A vulnerability scan identifies known issues automatically, without confirming they're exploitable, and produces a high false-positive rate. A penetration test actively attempts exploitation to prove real-world impact. Auditors increasingly distinguish between the two, and a scan alone is a weaker piece of evidence for CC4.1/CC7.1 than a genuine pentest.
How much does SOC 2 penetration testing cost?
Cost varies by scope, asset count and provider, and we won't quote an industry-wide number here since it depends heavily on what's being tested. Ask any provider for a scoped estimate based on your specific application, API and infrastructure footprint rather than relying on a generic published range.
If your audit window is approaching and you don't yet have testing scheduled, the scoping conversation is worth starting now — auditors notice when evidence is assembled at the last minute.