The AICPA never wrote the words penetration test required into SOC 2. Yet a service organization that walks into a Type II audit without one is almost guaranteed to leave with findings, follow-up questions, or a delayed report. That gap, between what the standard technically demands and what auditors operationally expect, is where most companies trip.
This article breaks down the real SOC 2 penetration testing requirements: where they sit in the Trust Services Criteria, what auditors look for during Type I and Type II engagements, how often you should test, and what a good pen test report needs to contain to satisfy your auditor without inflating your budget.
Understanding SOC 2 and Its Security Expectations
What Is SOC 2?
SOC 2 is an attestation framework developed by the American Institute of Certified Public Accountants (AICPA) for service organizations that handle customer data. Unlike a certification, SOC 2 is an opinion: a licensed CPA firm reviews your security controls and issues a report stating whether those controls are designed (Type I) or operating (Type II) effectively. SOC 2 reports are read by enterprise procurement teams, security reviewers, and risk officers. Most B2B SaaS contracts in 2026 require one before signing.
What Controls Does SOC 2 Require?
Rather than dictating specific technologies, SOC 2 requires that you design and operate controls that demonstrably meet each criterion under the Trust Services Criteria (TSC). That gives you flexibility, and it also gives auditors latitude to ask hard questions.
Does SOC 2 Require Penetration Testing?
The Official SOC 2 Position on Penetration Testing
The phrase penetration test appears in the AICPA’s 2017 Trust Services Criteria publication (with 2022 revisions) inside a single Point of Focus under CC7.1, the Common Criterion that requires entities to use detection and monitoring procedures to identify changes to configurations that introduce new vulnerabilities and susceptibilities to newly discovered vulnerabilities. The Point of Focus suggests management uses a variety of ongoing and separate risk and control evaluations to determine whether controls function. Penetration testing is named as one option.
That is the entire textual basis. There is no clause that mandates an annual external pentest, no specification of scope, no required methodology.
Short Answer: There Are No Mandatory SOC 2 Pen Test Requirements
You can technically obtain a SOC 2 report without a penetration test, provided you can show your auditor that you use alternative evaluations to satisfy CC4.1 (ongoing monitoring) and CC7.1 (vulnerability identification). In practice, almost nobody does this successfully.
Long Answer: You Still Need SOC 2 Penetration Testing
Auditors view penetration testing as the strongest available evidence that your controls work against a determined adversary, not just on paper. CC4.1 asks the entity to perform ongoing monitoring to ascertain whether internal controls are present and functioning; a pen test is the most direct way to evaluate that. CC6.1 asks whether logical access controls can be bypassed; a pen test answers that question directly. CC7.1 ties this together by requiring you to detect newly introduced vulnerabilities.
If you skip pen testing, you carry the burden of proving your alternative evidence is at least as good. That is a steeper hill than most organizations realize.
What Auditors Expect During Type I and Type II Engagements
A SOC 2 Type I report assesses control design at a single point in time. A Type II report assesses operating effectiveness over a defined audit period, typically six to twelve months. Both increasingly assume a recent penetration test exists. For Type II especially, auditors expect the test to fall within the audit window, with documented remediation of any critical or high findings before the period closes.
Auditors rarely refuse a Type II report over a missing pentest outright, but they will issue a finding or qualified opinion if they cannot validate CC4.1 evidence. That qualification will be read by every customer reviewing your report. Most CISOs would rather budget $15,000 for a pentest than try to explain a qualified opinion to a procurement team.
What Are the Actual SOC 2 Penetration Testing Requirements?
Alignment with Trust Services Criteria
A pen test that supports a SOC 2 audit must map its findings to specific criteria. Most reputable pentest firms now produce a Trust Services Criteria mapping appendix that ties identified vulnerabilities back to CC4.1, CC6.1, CC7.1, and where relevant CC7.2 through CC7.4. Without that mapping, your auditor has to do the interpretive work themselves, which typically means a follow-up request and a slower report.
Scope Definition Requirements
Scope should match your SOC 2 system boundary, not your entire infrastructure. If your audit covers a single SaaS product, its API, and its AWS account, that is what should be tested. Auditors look for evidence that the pen test scope was derived from the system description in your SOC 2 report. A mismatch between the two is one of the most common causes of fieldwork delays.
Testing Frequency and Timing Requirements
SOC 2 does not specify a frequency. Annual testing has become the de facto standard, with additional testing after material changes to architecture, authentication, or hosting. For organizations on continuous deployment, some auditors now accept a combination of annual deep-dive testing and continuous automated assessment as sufficient coverage, but this should be confirmed with your auditor before you rely on it.
Remediation Evidence Requirements
Findings without remediation are findings against you. Auditors expect documented remediation plans for every critical and high-severity issue, with closed tickets, retest results, or compensating controls recorded before the audit period ends. A finding sitting open in a backlog at audit time is treated almost identically to a finding that was never addressed.
Penetration Testing vs. Vulnerability Scans for SOC 2
Both belong in your control set, but they answer fundamentally different questions. Vulnerability scanning is automated and broad, it identifies known CVEs and misconfigurations across your environment quickly and consistently. Penetration testing is manual and adversarial, it simulates what a real attacker would do with the access and information they can obtain. CC7.1 explicitly references both, and your auditor will want to see evidence of each.
Why Automated Scans Are Not Sufficient for SOC 2 Compliance
Scanners cannot reason about business logic. They will not find a privilege escalation chain through a multi-tenant API, an authorization flaw that lets one customer view another customer’s data, or an authentication bypass via a forgotten admin endpoint. SOC 2 cares about whether your controls actually protect customer data, and those classes of failure only surface under manual penetration testing. Submitting scanner output as your primary evidence under CC4.1 is one of the fastest ways to generate a finding.
When to Use Vulnerability Scanning vs. Penetration Testing
Use scanning continuously as ongoing evidence of monitoring. Use penetration testing periodically as deep validation. They are complements, not substitutes, and your SOC 2 control narrative should describe them as such.
Required Types of Penetration Testing for SOC 2
In-scope assets generally fall into five categories, each requiring a distinct testing approach. External network testing simulates an attacker on the public internet probing your perimeter, open ports, exposed services, and edge device vulnerabilities. Internal network testing assumes a foothold has already been gained and evaluates lateral movement paths, network segmentation, and privilege escalation opportunities. Web application testing typically follows the OWASP Web Security Testing Guide and targets injection, authentication, and session management flaws. API testing has become its own discipline as most SaaS products now expose core business logic through REST and GraphQL endpoints, making it a critical surface area for SOC 2 evidence. Cloud infrastructure testing for AWS, Azure, and GCP focuses on misconfigured IAM policies, exposed storage buckets, and overly permissive network controls, the most common source of material findings in modern SaaS environments.
What Makes a Good SOC 2 Penetration Test?
A good test pursues specific goals tied to your actual threat model: Can a customer access another customer’s data? Can an unauthenticated user reach administrative endpoints? Can an attacker pivot from a compromised application tier to the underlying cloud account? Generic test-everything engagements rarely produce findings that map cleanly to TSC controls, and they are harder for auditors to evaluate. Specificity is an asset, not a limitation.
The test must also match your SOC 2 audit scope precisely. If your system description names three products and the pentest covered only one, your auditor will issue a finding. Results must be actionable, CVSS scores alone are not enough. Each finding should include reproduction steps, business impact, and prioritized remediation guidance. Anything less wastes engineering time and adds friction at audit fieldwork.
Pro Tip: Avoiding Failed Audits
Auditors will reject a pentest report that consists only of automated scanner output rebadged as a penetration test. This pattern has become common with low-cost pentest-as-a-service providers, and major audit firms have started calling it out as insufficient evidence for CC4.1.
When Should You Perform Penetration Tests for SOC 2 Compliance?
Four scenarios drive timing decisions. The first is the audit deadline itself, a pentest performed too early in the audit window leaves stale findings; too late, and there is no time to remediate before the period closes. The second is a trigger event, such as a security incident or a newly disclosed CVE affecting your stack. The third is a material architecture change, a major deployment, a new authentication system, or a cloud migration that changes your attack surface significantly. The fourth is the basic annual cadence that maintains posture between audits regardless of whether anything has changed.
Worth Knowing: Scheduling a Pentest
Schedule your pentest 90 to 120 days before your audit period closes. That gives engineering time to remediate critical findings, your testing firm time to retest, and your auditor time to validate evidence before the report is drafted. Anything tighter is a recipe for a qualified opinion or a delayed close.
How to Prepare for and Perform Effective SOC 2 Penetration Testing
Preparation starts with scope definition aligned to your SOC 2 system boundary. Document every in-scope application, API, and cloud account. Confirm authentication paths and provision tester accounts before the engagement starts. Brief your testing firm on your threat model and share prior findings so they are not duplicating work.
Choose a testing team with explicit SOC 2 experience. Certifications worth verifying include OSCP, OSWE, CREST, and CISSP. Ask specifically whether the firm produces TSC-mapped reports and whether retests are included in scope, both are non-negotiable for audit-quality evidence. For a full walkthrough of what to look for, the SOC 2 guide covers vendor selection in detail.
Remediate every critical and high finding before the audit period closes. Document medium and low findings with risk acceptance memos or remediation timelines. Then present everything to your auditor as a structured package: pentest report, remediation evidence, retest results, and a control-mapping summary. Auditors appreciate a clean folder, it signals operational maturity.
SOC 2 Penetration Testing Checklist for 2026
Use the SOC 2 checklist as your master reference, and layer in the following for penetration testing specifically. Confirm scope matches your system description. Schedule the engagement 90 to 120 days before the audit window closes. Require Trust Services Criteria mapping in the final report. Ensure manual testing of authorization flows and business logic, not just infrastructure. Remediate all criticals and highs before the period ends. Retain retest evidence alongside the original findings. Store the complete package, report, remediation tickets, retest results, and control mapping, in a single audit folder before fieldwork begins.
What Are the Benefits of SOC 2 Penetration Testing?
Beyond audit evidence, a properly scoped pentest delivers compounding value. It reduces breach risk by surfacing exploitable vulnerabilities before an attacker does. It validates your engineering investment in security controls, giving your team actionable signal rather than theoretical risk scores. It supplies ready-made evidence for customer security reviews and third-party questionnaires that would otherwise require custom responses. And it provides a legally defensible position if a breach later occurs, demonstrating reasonable due diligence is increasingly relevant in regulatory and litigation contexts.
How Much Does a SOC 2 Penetration Test Cost?
For a standard SaaS scope covering one product, its API, and one cloud account, expect to budget $1,000 to $20,000 in 2026. Scope size is the largest cost driver, additional applications, multiple cloud environments, complex authentication flows, and Active Directory all push costs higher. Boutique specialist firms typically deliver better evidence-to-cost ratios than large consultancies, which often charge two to three times the boutique rate for comparable depth of work.
The hidden cost is retesting. Many providers quote a low headline price that excludes retest fees. A finding without retest evidence does not satisfy your auditor, so retests are not optional, they are part of the deliverable. Ask explicitly whether retesting is included before signing an engagement letter.
Closing Note
SOC 2 will not technically fail you for skipping a penetration test. But the operational reality of modern audits, enterprise procurement requirements, and customer security reviews makes one effectively mandatory. Treat the pentest as the most efficient piece of evidence you can produce for CC4.1, CC6.1, and CC7.1, scope it tightly to your system boundary, remediate findings before the audit window closes, and make sure the report can be read by an auditor without translation. Done well, it is the lightest-weight way to satisfy three of the most scrutinized criteria in SOC 2, and one of the few security investments that pays dividends both inside and outside the audit room.
Frequently Asked Questions About SOC 2 Penetration Testing Requirements
Is penetration testing required for SOC 2 Type I?
Not strictly, but most auditors expect one as evidence of control design. A Type I report without a recent pentest is harder to defend and more likely to generate follow-up requests during fieldwork.
Is penetration testing required for SOC 2 Type II?
Same answer, more emphatically. Type II tests operating effectiveness over time, and a pentest is the strongest available evidence that controls operate as designed across the audit period.
How often should penetration testing be performed for SOC 2?
Annually at minimum, plus additional tests after material changes to architecture, authentication systems, or cloud infrastructure. Some high-velocity engineering organizations supplement annual testing with continuous automated assessment, though this should be discussed with your auditor before relying on it as a substitute.
What does a SOC 2 penetration test report need to include?
An executive summary, defined scope and methodology, severity-rated findings with reproduction steps, CVSS scores, Trust Services Criteria control mapping, and prioritized remediation guidance. Retest evidence should be appended or submitted as a follow-on document before the audit period closes.
Can I use a vulnerability scan instead of a penetration test for SOC 2?
No. Vulnerability scans support CC7.1 as evidence of ongoing monitoring but do not substitute for the manual evaluation evidence auditors expect under CC4.1 and CC6.1. The two serve different evidentiary purposes and both should appear in your control set.
Who can perform a SOC 2 penetration test?
Any qualified third-party firm with a documented testing methodology and credentialed testers. SOC 2 does not specify required accreditations, but auditors look for evidence of tester independence, a recognized methodology, often referencing NIST SP 800-115, and verifiable tester qualifications such as OSCP or CREST membership.