SOC 2 Penetration Testing Requirements (What Auditors Actually Expect)

SOC 2 does not explicitly require penetration testing, but it does require that you demonstrate your security controls are working in practice. In most environments, that expectation is met through a penetration test.

SOC 2 penetration testing requirements refer to how organizations validate security controls through simulated attacks, even though the framework itself does not mandate testing by name.

This page covers which controls pentesting maps to, what auditors expect to see, and what a valid engagement needs to include.

Is a Pentest Required for SOC 2?

SOC 2 does not mandate penetration testing. There is no clause in the Trust Services Criteria that says “you must conduct a penetration test.” Auditors cannot technically require it.

In practice, that distinction matters less than most teams expect.

SOC 2 is built around the AICPA Trust Services Criteria. The security category, CC6 through CC9, requires organizations to demonstrate that they identify, monitor, and respond to security threats. CC4.1 specifically requires ongoing and separate evaluations to determine whether controls are present and functioning.

A penetration test is one of the most direct ways to satisfy CC4.1. It demonstrates that controls were evaluated by an independent party using real-world attack techniques, not just reviewed on paper.

Auditors who recommend penetration testing are not inventing a requirement. They’re pointing to the most credible way to produce the evidence CC4.1 calls for.

Which SOC 2 Controls Does Penetration Testing Map To?

The primary control is CC4.1: ongoing evaluation of whether internal controls are present and functioning. A penetration test satisfies this by demonstrating independent, technical validation of security controls rather than self-attestation.

Secondary controls where pentest evidence is commonly used:

CC6.1 requires logical access controls to be implemented. Penetration testing validates whether those controls actually hold under adversarial conditions, not just whether they’re documented.
CC6.6 addresses threats from outside the system boundary. External penetration testing directly addresses this control by simulating external attack paths.
CC7.1 covers detection and monitoring of anomalies. Findings from a penetration test can inform detection gaps and support evidence that the organization is actively identifying threats.
CC9.2 addresses vendor and third-party risk management, which can be relevant when the application under test integrates with external services or data processors.

Not every engagement will touch all of these. Scope determines which controls are most directly addressed, which is one reason scoping conversations with your tester matter before the engagement starts.

What Auditors Actually Expect to See

Auditors reviewing SOC 2 evidence for penetration testing are looking for a few specific things.

Independence: the test was conducted by a third party, not internally.
Scope documentation: what was tested, what was excluded, and why.
Methodology: how the testing was conducted, not just what was found.
Risk-ranked findings: vulnerabilities categorized by severity with enough context to understand the real-world impact.
Remediation evidence: documentation that findings were addressed, which typically requires a retest.
Timing: for SOC 2 Type II, the test should fall within the audit period. A pentest conducted two years ago is unlikely to satisfy current audit requirements.

What auditors will push back on:

A scanner-generated report with no methodology documentation
A report that lists findings without remediation evidence
A test with scope so narrow it doesn’t credibly cover the application in question

SOC 2 Penetration Testing Requirements Checklist (Audit-Ready Baseline)

If you’re evaluating whether a pentest will satisfy your SOC 2 audit, use this as a baseline. A valid engagement should include all of the following:

Third-party independent testing. The test must be conducted by an external firm, not internal staff.
Defined and documented scope. What was tested, what was excluded, and the rationale for both.
Recognized methodology. Testing aligned to a documented standard such as OWASP ASVS gives auditors a framework to reference and makes coverage credible rather than implied.
Risk-rated findings. Vulnerabilities categorized by severity with enough context to understand business impact, not just a CVSS score.
Proof of exploitation. Reproduction steps, screenshots, session tokens, demonstrated impact. Auditors want to see that findings reflect real attack paths, not theoretical conditions a scanner flagged and a human never verified.
Remediation and retest evidence. Documentation that findings were addressed and independently verified. This is what closes the loop for auditors.
Test conducted within the audit period. For SOC 2 Type II, timing matters. A test outside the observation window may not satisfy audit requirements regardless of quality.

Auditors want to see that findings reflect real attack paths, not theoretical conditions a scanner flagged and no one verified. If you want a deeper breakdown of how to evaluate each of these in a real vendor conversation, the guide at the end covers this in detail.

When Should You Schedule a Pentest for SOC 2?

Timing is one of the most common sources of avoidable audit risk, and one of the least discussed.

For SOC 2 Type II, the audit covers a defined observation period, typically six to twelve months. The penetration test generally needs to fall within that window. A test conducted before the period started or long before the audit closes may not satisfy your auditor, even if the report is otherwise excellent.

Retest timing compounds this. Once findings are remediated, the retest that confirms fixes needs to happen before the audit closes as well. If your original test runs late in the observation period, there may not be enough time to remediate findings and complete a retest before the window closes.

The practical implication:

Schedule the test early enough that remediation and retest can both complete within the observation period. For most teams, that means initiating the engagement at least two to three months before the audit closes, not two weeks before.

Last-minute tests create a specific kind of audit risk. Not because the testing is worse, but because there is no time to fix anything before the auditor asks for remediation evidence. A finding list with no remediation documentation is harder to explain than a test that simply hasn’t happened yet.

What a Valid SOC 2 Penetration Test Includes

For a penetration test to hold up under SOC 2 scrutiny, it needs to include several things beyond a findings list.

A documented scope that reflects the actual application and identifies what was and wasn’t tested. For web application testing, this typically means authentication, authorization, session management, API security, and business logic, not just a surface scan for known CVEs.
A methodology section that explains how the test was conducted. Testing aligned to OWASP ASVS gives auditors a recognized framework to reference and makes the coverage credible rather than implied.
Findings with real proof of exploitation: reproduction steps, screenshots, demonstrated impact. Not theoretical conditions under which something could be exploited.
Remediation guidance specific to the application and stack, not boilerplate from a vulnerability database.
A retest confirming that findings were addressed. This is the evidence that closes the loop for auditors and maps directly to CC4.1’s requirement for ongoing evaluation.
A report structured for multiple audiences: the auditor who needs methodology documentation, the engineer who needs actionable remediation steps, and the executive who needs to understand business risk without a translation layer.

The Audience Beyond the Auditor

One thing worth understanding before you scope a SOC 2 pentest: the auditor is usually the most forgiving audience the report will ever face.

Enterprise customers, procurement teams, and investors increasingly request pentest reports as part of vendor review. They read them more carefully than most auditors do. A report that cleared a SOC 2 audit but lacks methodology documentation or detailed findings will not survive a serious procurement review.

The report you produce for your SOC 2 audit is the same report you’ll share when a prospective customer asks for it. Scoping it with that audience in mind from the start produces better outcomes on both fronts.

Working With a SOC 2 Penetration Testing Firm

If you’re at the stage where you need to scope a test that will hold up under both audit and procurement review, the way the engagement is run matters more than the label on it. Two vendors can both call it a “SOC 2 pentest” and deliver completely different levels of assurance.

See how we run SOC 2 penetration testing engagements.

If you want a practical checklist for evaluating vendors before you sign, our guide, Audit-Proof Your Pentest: 17 Mistakes That Will Blow Your Audit, walks through exactly what to verify and where most teams get burned.