SOC 2 Penetration Testing Requirements Explained

The honest status of pentest under SOC 2

SOC 2 does not name "penetration testing" in a single mandatory line item. The Trust Services Criteria are written at the principle level, and auditors interpret what evidence reasonably supports each criterion. In practice, every SOC 2 Type II audit we have seen treats a current third-party penetration test as expected evidence — explicitly under Common Criteria CC4 (Monitoring Activities) and CC7 (System Operations).

If you ask three different auditors how they expect pentest evidence to be presented, you will get three slightly different answers. What does not vary is that they expect it.

Which criteria pentest evidence supports

Criterion	What pentest contributes
CC4 — Monitoring Activities	Periodic third-party assessment of control effectiveness. The pentest is itself the assessment.
CC6 — Logical and Physical Access	Authorization, role boundary, and tenant isolation findings demonstrate effectiveness of access controls.
CC7 — System Operations	Vulnerability identification, remediation tracking, and retest evidence support the operations criterion.
CC8 — Change Management	Pentests after significant changes show that change management includes security validation.
A1 — Availability (if in scope)	Findings around DDoS resilience, rate limiting, and abuse resistance.
C1 — Confidentiality (if in scope)	Findings around data protection, encryption, and access boundaries on confidential data.

Cadence — what auditors expect

Annual is the standard cadence. Larger or higher-risk environments often go semi-annual. Pentests are also expected after material changes to in-scope systems — new authentication, new tenant model, new data class, major infrastructure migration. The "after material change" trigger is the part most teams underestimate; running an annual pentest in March does not satisfy a question about a major system you launched in September.

Two practical anchors:

• Have the report dated within twelve months at the time of audit field work. Older reports get questions and follow-up requests for evidence of intermediate testing.
• Have the retest landed before audit field work begins. Auditors care about post-fix state. If your report shows critical findings as "open" with no retest evidence, expect follow-up.

How to scope a SOC 2-aligned engagement

Three principles keep the engagement audit-friendly without inflating cost:

Test the in-scope systems

SOC 2 scope is defined by your scope statement. If your customer-facing product is in scope but an internal HR tool is not, the pentest should reflect the same boundary. Auditors care about the system that is in the SOC 2 boundary, not adjacent infrastructure.

Cover the criteria that map cleanly

Web application and API testing covers CC6 (access) and parts of CC7 (operations). Network and cloud testing covers infrastructure layer of CC6 and CC7. Authenticated testing strengthens CC6 evidence specifically. For a small SaaS in scope under Security only, web + API + authenticated is usually enough.

Map every finding

Reports should explicitly tie each finding to the SOC 2 Common Criterion it relates to. This is a five-percent additional effort that saves your team from doing the cross-walk during audit field work.

What the report should contain

1. Executive summary. One page. What was tested, what was found at high severity, what was fixed.
2. Scope statement. Explicit list of in-scope systems and exclusions, matched to the SOC 2 scope statement.
3. Methodology. Reference to the framework used (OWASP Testing Guide, NIST SP 800-115, PTES). Auditors look for this.
4. Findings. Each with severity, evidence, reproduction steps, remediation, and SOC 2 criterion mapping.
5. Retest status. Each finding marked closed (with verification details), open (with planned remediation), or accepted (with documented risk acceptance).
6. Methodology and scope assumptions. Test accounts, environment used, time-box, any constraints.

Three common mistakes that extend audit field work

• Pentest dated more than twelve months before audit. The auditor will ask for evidence of intervening testing. If you do not have it, the audit slows.
• Open critical findings with no retest evidence. Even if the fix shipped, an undocumented retest reads as "not yet remediated".
• Scope mismatch with the SOC 2 boundary. A pentest that excludes systems your SOC 2 includes (or vice versa) raises questions. Match them.