# SOC 2 Penetration Testing: Scope, Frequency and Report Format

> Updated 2026-10-25 - 9 min read

SOC 2 doesn't name a specific penetration-testing standard the way PCI DSS does - but "we ran a scan" doesn't satisfy most auditors either. Here's what scope, frequency and report format actually need to look like for a penetration test to hold up as SOC 2 evidence.

## 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.

## FAQ

**Does the pentest need to happen inside the audit period?**
Generally yes, or close enough to it that it reasonably represents the environment during the audit period - check with your specific auditor's expectations early.

**Can we use the same pentest for SOC 2 and our enterprise customers' security reviews?**
Often yes, if the scope and report format are broad enough - we scope engagements to serve both purposes where possible, saving a second engagement.