Introduction
SOC 2 has become the de facto standard for service organizations demonstrating security maturity to customers, partners, and prospects. Whether you're pursuing Type I or Type II attestation, penetration testing is a critical component of your security program—and your auditors will expect to see evidence of regular security validation.
Unlike prescriptive frameworks that mandate specific controls, SOC 2 follows the Trust Service Criteria, which require organizations to implement controls "suitable to meet the entity's commitments and system requirements." This principles-based approach gives you flexibility, but also requires you to justify your security testing strategy to auditors.
This guide explains what SOC 2 actually requires for penetration testing, how to build a testing program that satisfies auditors, and how to generate the evidence you need for successful attestation.
Understanding SOC 2 Trust Service Criteria
SOC 2 reports evaluate organizations against the Trust Service Criteria (TSC), which include:
- Security (Common Criteria): Required for all SOC 2 reports
- Availability: Optional, for systems with uptime commitments
- Processing Integrity: Optional, for systems with data processing accuracy commitments
- Confidentiality: Optional, for systems handling confidential information
- Privacy: Optional, for systems handling personal information
Penetration testing primarily supports the Security criteria, though findings may also impact Availability, Confidentiality, and Privacy depending on the vulnerabilities discovered.
The Security Criteria and Penetration Testing
The Security common criteria (CC) include several criteria directly relevant to penetration testing:
CC7.1: Detect and Respond to Anomalies
This criterion requires organizations to detect and respond to security events. Penetration testing validates that your detection and response mechanisms actually work when faced with real attack techniques.
CC7.2: Evaluate Security Events
Organizations must analyze security events to determine their cause and impact. Penetration test findings provide concrete examples of vulnerabilities and their potential business impact, supporting this analysis.
CC7.3: Respond to Security Incidents
This criterion requires incident response procedures. Penetration testing can validate that your incident response team detects and responds to simulated attacks appropriately.
What Auditors Actually Look For
SOC 2 auditors examine several key areas related to penetration testing:
Testing Frequency
SOC 2 doesn't mandate specific testing frequencies, but auditors evaluate whether your cadence is appropriate for your risk profile:
SOC 2 auditors generally look for a risk-based, repeatable process. Environments that change frequently or handle more sensitive data usually justify more frequent testing and more rigorous evidence of remediation. For Type II reports (covering an extended period), auditors often expect to see that security validation occurred during the audit window and that findings were tracked through remediation or risk acceptance.
Testing Scope
Auditors verify that your testing scope covers:
- In-scope systems: All systems included in your SOC 2 boundary
- Attack vectors: Web applications, APIs, authentication systems, network infrastructure
- Data flows: Systems that process, store, or transmit sensitive data
- Third-party integrations: Connections to external services within your trust boundary
A common finding is scope misalignment—where the penetration test covers your main application but excludes APIs, admin portals, or third-party integrations that handle sensitive data.
Evidence of Remediation
Finding vulnerabilities isn't enough. Auditors want to see:
- Tracking: How findings are logged, prioritized, and assigned
- Remediation: Evidence that vulnerabilities were actually fixed
- Verification: Retest results confirming fixes are effective
- Risk acceptance: Documented justification for any vulnerabilities not remediated
Report Quality
Your penetration test reports should include:
- Executive summary with business impact
- Scope and methodology documentation
- Detailed findings with reproduction steps
- Risk ratings aligned with your organization's risk framework
- Remediation recommendations
- Evidence of retesting and closure
SOC 2 Type I vs Type II Penetration Testing
SOC 2 Type I
Type I reports evaluate controls at a single point in time. For penetration testing:
- One test covering your in-scope systems
- Test date must fall within your Type I audit period
- Report available for auditor review
SOC 2 Type II
Type II reports evaluate controls over a 12-month period. For penetration testing:
- At least one test during the audit period (more is better)
- Demonstrated remediation and retesting processes
- Evidence that testing is an ongoing practice, not a one-time event
Building a SOC 2-Ready Testing Program
Step 1: Define Your Scope
Document your SOC 2 system boundary and ensure penetration testing covers:
- All applications within the trust boundary
- APIs and microservices processing sensitive data
- Network infrastructure supporting in-scope systems
- Cloud infrastructure and configurations
- Third-party integrations handling sensitive data
Step 2: Establish Testing Cadence
Create a documented testing schedule:
- Annual baseline for all in-scope systems
- Quarterly testing for high-risk or frequently changing components
- On-demand testing after significant changes or security events
Step 3: Implement Remediation Workflow
Build a process that tracks findings from discovery to closure:
- Finding identified and logged
- Severity assessed and risk rated
- Remediation assigned with deadline
- Fix implemented by development team
- Retest scheduled and executed
- Finding closed with evidence
Step 4: Generate Audit-Ready Evidence
Ensure your penetration testing produces:
- Professional reports with executive summaries
- Detailed findings with business impact
- Clear remediation guidance
- Evidence of retesting and verification
- Historical record demonstrating ongoing testing
Common Audit Findings (And How to Avoid Them)
Finding 1: Outdated Penetration Test
The problem: Your only penetration test was 14 months ago, outside the SOC 2 Type II audit period.
The fix: Schedule testing at least annually, ideally more frequently. For Type II, ensure at least one test falls within the 12-month audit window.
Finding 2: Incomplete Scope
The problem: Your penetration test covered the main web application but excluded the admin portal, API, or database infrastructure.
The fix: Map your SOC 2 system boundary to your penetration testing scope. Every component handling sensitive data should be tested.
Finding 3: No Remediation Evidence
The problem: You have a penetration test report but no documentation showing vulnerabilities were fixed.
The fix: Implement a vulnerability tracking system that documents the full remediation lifecycle with evidence.
Finding 4: Generic Reports
The problem: Reports lack business context, making it difficult for auditors to assess risk and impact.
The fix: Ensure reports include business impact assessment, risk ratings aligned with your risk framework, and clear prioritization.
SOC 2 Penetration Testing Checklist
Before your SOC 2 audit, verify:
- Penetration testing scope covers all SOC 2 in-scope systems
- Testing frequency documented and risk-appropriate
- At least one test within the audit period (Type II)
- Findings tracked with severity ratings and business impact
- Remediation documented with timelines and owners
- Retesting completed to verify fixes
- Risk acceptance documented for unfixed vulnerabilities
- Reports available in audit-ready format
- Remediation workflow documented and followed
Conclusion
SOC 2 penetration testing requirements aren't about checking a box—they're about demonstrating that your security controls effectively protect the data your customers entrust to you. By building a well-documented, risk-based testing program, you satisfy auditors while genuinely improving your security posture.
The key is consistency: regular testing, thorough documentation, and demonstrated remediation. When these elements align, your penetration testing program becomes powerful evidence of security maturity.
RedVeil's AI-powered penetration testing platform helps you meet SOC 2 requirements with on-demand testing across web applications, APIs, networks, and cloud infrastructure. Generate audit-ready evidence in hours, not months, with built-in remediation tracking and one-click retesting.