Introduction
Organizations preparing for SOC 2 consistently encounter conflicting information about whether penetration testing is actually required. Some vendors say it's mandatory, others call it optional, leaving compliance teams confused about how to proceed. The truth lies in understanding how auditors interpret the AICPA Trust Services Criteria in practice, not in the literal text of the standard.
While AICPA doesn't list penetration testing as an explicit checkbox requirement, it has become what auditors expect as evidence of functioning controls, especially for Type 2 reports. Organizations that skip it often face auditor scrutiny, qualified opinions, or enterprise sales friction when prospects review their SOC 2 documentation.
Understanding those stakes makes the path forward clearer. This guide covers the exact Trust Services Criteria that penetration testing satisfies, how it differs from vulnerability scanning, and how to time it correctly within your audit cycle so you're prepared when auditors review your security posture.
TLDR
- SOC 2 pentesting isn't explicitly required by AICPA, but CC4.1 names it as an accepted evaluation method, and auditor expectations are rising
- Pentesting primarily satisfies CC4.1 (Monitoring Activities), CC7.1 (System Operations), and supports A1.2 and C1.1 criteria
- Vulnerability scanning and penetration testing are complementary, not interchangeable: one monitors continuously, the other simulates real attacks
- Quality pentests must align with your SOC 2 audit boundary and include actionable remediation evidence
- Annual third-party penetration testing with documented remediation has become the industry standard for SOC 2 Type 2
Is SOC 2 Penetration Testing Mandatory?
The official AICPA position is clear: the Trust Services Criteria do not designate penetration testing as a hard requirement. Organizations have flexibility in how they design controls to meet each criterion.
The confusion stems from CC4.1 (COSO Principle 16), which states: "The entity selects, develops, and performs ongoing and/or separate evaluations to ascertain whether the components of internal control are present and functioning."
Under the points of focus, AICPA guidance notes that risk and control evaluations "may include...vulnerability scans, security assessment, penetration testing, and third-party assessments." The critical phrase is "may include"; penetration testing is listed as one option among several.
AICPA also explicitly states that "use of the trust services criteria does not require an assessment of whether each point of focus is addressed." Points of focus represent guidance that may assist management, not prescriptive requirements.
Why Auditors Treat It as Near-Mandatory
Despite the official flexibility, auditors consistently treat penetration testing as near-mandatory . Without pentest results, organizations must substitute other equally convincing evidence of control effectiveness, and auditors frequently find those alternatives insufficient for complex IT environments, particularly SaaS and cloud-hosted systems.
Moss Adams notes that auditors "frequently cite deficiencies" including "insufficient evidence of annual security testing" and "absence of documented methodology aligned with industry standards such as OWASP or NIST."
Real-World Consequences of Skipping Penetration Testing
Organizations that skip penetration testing face tangible consequences:
- Qualified opinions or exceptions noted in Type 2 reports
- Pointed questions from enterprise prospects who review the report before signing contracts
- Cyber insurance scrutiny when insurers assess risk profiles
- Longer sales cycles as prospects demand additional security assurances
When Alternative Evidence Works
Certain alternative evidence can sometimes satisfy CC4.1, though acceptance depends heavily on the auditor, scope complexity, and industry:
- Bug bounty programs with documented findings and remediation
- ISO 27001 certifications covering similar control objectives
- Internal security assessments by qualified security teams
That said, alternative evidence has limits. For organizations in financial services, healthcare, and SaaS, auditors apply a noticeably higher bar, and in those industries, penetration testing remains the most defensible way to demonstrate control effectiveness given the volume and sensitivity of data involved.
How Penetration Testing Satisfies the SOC 2 Trust Services Criteria
SOC 2 evaluates organizations against five Trust Services Criteria: Security, Availability, Processing Integrity, Confidentiality, and Privacy. Security is the only mandatory category; the others are optional based on service commitments.
Penetration testing most directly addresses three criteria:
CC4.1: Monitoring Activities (Security)
CC4.1 requires organizations to perform ongoing evaluations confirming internal controls are present and functioning. A penetration test satisfies this by actively attempting to exploit controls (firewalls, access controls, authentication mechanisms) rather than simply documenting that they exist.
This is the critical distinction between design testing (does the control exist on paper?) and operating effectiveness testing (does the control actually prevent attacks?). Policy reviews alone cannot demonstrate control effectiveness under adversarial conditions; a penetration test can.
CC7.1: System Operations (Vulnerability Detection)
CC7.1 requires detection and monitoring procedures to identify:
- Configuration changes that introduce new vulnerabilities
- Susceptibilities to newly discovered weaknesses
The Trust Services Criteria explicitly mention vulnerability scans in the points of focus under CC7.1. Penetration testing complements vulnerability scanning by testing whether identified vulnerabilities can actually be exploited in the context of your specific environment, rather than just flagging their existence.
A1.2 and C1.1: Availability and Confidentiality
A1.2 requires demonstrating that infrastructure and recovery processes protect system availability. C1.1 requires that confidential data is identified and protected.
Penetration testing addresses both by:
- Simulating attacks on availability-critical infrastructure (load balancers, database clusters, failover systems)
- Attempting to access confidential customer data through authentication bypass, privilege escalation, or data exfiltration techniques
The resulting report gives auditors concrete evidence (documented attack paths, confirmed or ruled-out data exposure, and tested failover behavior) rather than control design documentation alone.
Penetration Testing vs. Vulnerability Scanning for SOC 2
Vulnerability scanning is an automated process that identifies known weaknesses by matching against CVE databases and configuration benchmarks. Penetration testing is a manual, human-led simulated attack that attempts to exploit those weaknesses, including ones automated tools miss entirely, such as business logic flaws and misconfigured access policies.
What Vulnerability Scanning Does Well
In the SOC 2 context, vulnerability scanning:
- Satisfies CC7.1's continuous monitoring requirement
- Can be scheduled after every significant infrastructure change
- Provides a running record of remediation activity across the Type 2 period
- Delivers immediate feedback on known CVEs and misconfigurations
What Penetration Testing Delivers That Scanning Cannot
Penetration testing provides:
- Exploitation evidence: Proof that a vulnerability can actually be weaponized in your environment
- Combinations of low-severity findings that become critical when exploited in sequence
- Actual attempts to access and extract sensitive data, demonstrating real exfiltration risk, not hypothetical exposure
- Business logic vulnerabilities that don't follow known CVE patterns and require human judgment to identify
OWASP confirms that business logic vulnerabilities are "difficult to find automatically, since they typically involve legitimate use of the application's functionality."
The Exploitation Window Problem
That exploitability matters more than it used to. Verizon's 2025 DBIR reports a median of 5 days for mass exploitation of vulnerabilities, while organizations take 32-38 days to remediate CISA KEV vulnerabilities. That 27-33 day gap is where breaches happen, and scanning alone won't close it.
Scanning identifies the problem, but penetration testing validates whether the vulnerability is exploitable in your specific environment, so remediation decisions are driven by demonstrated risk rather than CVSS scores alone.
Why You Need Both
Auditors view these tools as serving different purposes:
- Vulnerability scans demonstrate continuous vigilance (CC7.1)
- Penetration tests demonstrate control effectiveness under adversarial conditions (CC4.1)
Organizations that present only scan results for CC4.1 often face auditor pushback. Those that present only pentest results without ongoing scanning appear to have gaps in continuous monitoring. Auditors want to see the full picture: continuous detection paired with periodic proof that your controls hold up when someone is actively trying to break them.
What Defines a Quality SOC 2 Penetration Test
Scope: Align With Your Audit Boundary
The pentest scope must mirror your SOC 2 system description; every system that processes, stores, or transmits customer data should be in scope. Typical scope components include:
- Customer-facing web applications
- APIs (REST, GraphQL, SOAP)
- Authentication and authorization systems
- Cloud infrastructure (AWS, Azure, GCP)
- Internal admin tools and dashboards
- Mobile applications (if applicable)
- Network segmentation controls
Avoid artificially narrow scopes that satisfy the audit on paper but leave real attack surfaces untested. If a component appears in your system description, it belongs in your pentest scope.
Methodology: Black, White, and Grey Box
Three methodologies are commonly used in SOC 2 pentesting:
| Methodology | Knowledge Level | Best For | Trade-offs |
|---|---|---|---|
| Black box | Zero internal knowledge | Testing perimeter controls | Misses internal vulnerabilities; less efficient |
| White box | Full architectural access | Thorough, efficient testing | Misses real-world attacker perspective |
| Grey box | Partial knowledge (credentials, limited architecture) | SOC 2 compliance | Balances efficiency with realistic simulation |
Grey box is the most common choice for SOC 2 because it provides authenticated user credentials and limited architecture detail, offering the best balance of efficiency and realistic adversarial simulation. Auditors will accept any methodology as long as scope and findings are well-documented.
Quality Indicators vs. Checkbox Compliance
A quality penetration test delivers security improvement, not just compliance theater. Methodology choice only matters if the execution holds up, and here's what separates a rigorous engagement from an automated scan dressed up as a report.
Key quality indicators include:
- Duration appropriate to scope: Per Invicti's 2025 pricing guide, typical engagements run 3-5 days for single-application or small-scope tests, extending to multiple weeks for large enterprise environments
- Manual exploitation evidence: Reports should show human-led exploitation beyond automated scan output, including proof-of-concept exploits, screenshots of successful attacks, and documented attack chains
- CVSS-scored findings with business context: Vulnerabilities should be rated using CVSS 4.0 (the current standard since November 2023) and framed against your specific environment, not just generic severity labels
- Documented remediation steps: Each finding should include specific, actionable fix guidance, not just "patch this CVE"
- Rescan confirmation: Verification testing after remediation confirms critical and high-risk vulnerabilities were actually resolved before the audit
Low-cost "express" pentests relying primarily on automated tools may satisfy a lenient auditor but create a false sense of security. Mandiant's 2025 M-Trends report shows exploits accounted for 33% of initial infection vectors, the most common attack pathway. If your pentest doesn't simulate realistic exploitation, it's not testing what actually matters.
Scoping and Timing Your SOC 2 Pentest for Audit Success
When to Run the Pentest
Complete your penetration test with all critical and high findings remediated at least 4-8 weeks before the audit period closes. This gives auditors time to review documentation and eliminates the risk of unresolved critical findings appearing in the final report.
For SOC 2 Type 2 audits, the pentest must fall within the audit observation period to be usable as evidence. Moss Adams notes that "delays occurred because the organization couldn't provide proof that meaningful penetration testing was performed within the period."
What Auditors Look for in Pentest Reports
Auditors specifically review:
- Executive summary accessible to non-technical reviewers
- Detailed technical findings with CVSS scores and exploitation evidence
- Scope documentation confirming alignment with the SOC 2 system description
- Remediation log for each finding, showing status and closure dates
- Rescan report confirming critical and high-risk vulnerabilities were resolved
Unresolved findings are not automatic disqualifiers, but they must be accompanied by documented risk acceptance or compensating control rationale. Without this documentation, auditors may issue exceptions or qualified opinions.
Annual Cadence and Trigger Events
For organizations maintaining SOC 2 Type 2 compliance year over year, annual third-party penetration testing is the industry standard. Moss Adams and Linford & Company both recommend supplementing that cadence with additional testing after significant infrastructure changes.
Trigger events that warrant additional testing include:
- Cloud migrations (AWS to Azure, on-premise to cloud)
- New product launches with customer-facing components
- Major architecture updates (microservices conversion, new API gateways)
- Acquisitions that integrate new systems
- Post-incident validation after security breaches
Deciding when a trigger event rises to the level of requiring a new pentest is not always straightforward. That judgment call, and the follow-through, is where ongoing vCISO leadership matters most. Impact Risk Advisors' vCISO services coordinate pentest timing, manage vendor selection, and ensure findings drive real remediation work within the continuous compliance program.
Frequently Asked Questions
Does SOC 2 require penetration testing?
AICPA does not mandate penetration testing, but CC4.1 explicitly names it as an acceptable evaluation method. Auditors routinely expect it as evidence of control effectiveness, particularly for SOC 2 Type 2 reports. Organizations can satisfy requirements through alternatives, but most face auditor scrutiny when penetration testing is absent.
What are the penetration testing requirements for SOC 2 Type 2?
No formal requirements exist, but Type 2 auditors expect a third-party pentest conducted during the observation period, with documented findings, remediation evidence, and a rescan report. Annual testing is the industry-accepted minimum; rescope and retest after significant infrastructure changes.
What are the five SOC 2 Trust Services Criteria?
The five Trust Services Criteria are Security, Availability, Processing Integrity, Confidentiality, and Privacy. Security is mandatory for every SOC 2 engagement. The remaining four are optional, selected based on the organization's service commitments and applicable risks.
What are the common stages of a penetration test?
Penetration tests follow four phases: scope definition, active scanning and exploitation, reporting with risk ratings and remediation steps, and retest validation. Quality engagements confirm that critical findings were resolved before the final report closes.
How much does a penetration test cost?
According to Invicti's 2025 pricing guide, costs vary by scope: SaaS applications run $5,000–$15,000, cloud environments $8,000–$25,000+, and full red team exercises $30,000–$150,000+. Lower-priced engagements often rely on automated scanning with minimal manual testing, enough for lenient auditors, but unlikely to surface real risks.
What is the difference between SOC 2 Type 1 and Type 2?
Type 1 evaluates whether controls are properly designed at a single point in time. Type 2 assesses whether those controls operated effectively over a defined period (typically 3–12 months). For Type 2, penetration testing provides direct evidence that controls held up under real-world conditions, not just that they were designed correctly.
