SOC 2 Penetration Testing: Scope, Frequency and Report Format

What SOC 2 actually requires (and doesn't)

SOC 2's Trust Services Criteria don't mandate a named pentest methodology or a specific frequency in the text itself - but the Common Criteria expect evidence that vulnerabilities are identified and addressed, and in practice, auditors consistently expect an annual third-party penetration test as baseline evidence for a Type II report.

Scope: what needs to be covered

• The production environment your SOC 2 report covers - not a staging environment that doesn't represent what customers actually use.
• External-facing applications and APIs, at minimum.
• Internal network testing if your Trust Services Criteria selection includes it - common for Confidentiality or broader Security-plus-Availability scopes.
• Cloud infrastructure configuration, where relevant to your architecture.

Frequency: annual is the floor, not the ceiling

Annual third-party testing is the common minimum auditors look for, timed to land within your audit period. A significant architecture change mid-period - a new product line, a cloud migration - is a reasonable trigger for an additional test rather than waiting for the next annual cycle.

What the report needs to include to satisfy an auditor

• A clear scope statement - what was and wasn't tested
• The methodology referenced, such as OWASP WSTG or PTES
• Risk-rated findings, not just a raw vulnerability list
• Evidence of remediation, or a documented risk-acceptance decision for each finding
• A letter or summary an auditor can reference directly, not just a raw technical report

A gap we see often: unaddressed findings

A pentest report with unremediated critical or high findings and no documented response is often a bigger problem for a SOC 2 audit than not having tested at all - it shows you know about a gap and haven't acted on it. Build remediation time into your audit-prep schedule, not just the test itself.