SOC 2 Penetration Testing Requirements: What You Need and When
Everything engineering teams need to know about SOC 2 penetration testing — when it's required, what scope auditors expect, how to track findings, and how to share results with customers.
Is Penetration Testing Required for SOC 2?
Technically, no — the SOC 2 Trust Services Criteria do not explicitly require penetration testing. However, in practice, most enterprise customers contractually require it, most auditors expect to see it, and many SOC 2 reports include it as an additional control. For any company targeting enterprise SaaS contracts, annual penetration testing is effectively required.
The relevant SOC 2 criteria that pen testing addresses:
- CC4.1 — The organization selects and develops control activities
- CC7.1 — The organization uses detection and monitoring procedures to identify security events
- CC7.2 — The organization monitors the system for anomalies and security events
What Scope Do SOC 2 Auditors Expect?
At minimum, enterprise customers and auditors expect:
Annual external penetration test — Simulates an attacker with no prior knowledge of your systems targeting your externally accessible attack surface: web application, API endpoints, authentication mechanisms, and public cloud infrastructure.
Scope should include:
- Production web application and API (all endpoints, authentication, authorization)
- External AWS/cloud perimeter (public-facing resources)
- Social engineering simulation (optional but positive signal)
- A report from a reputable pen testing firm (CREST-certified, OSCP-credentialed testers)
- Test completed within the last 12 months
- All critical and high findings either remediated or have documented risk acceptance
- A letter of attestation confirming scope, methodology, and completion date
Choosing a Penetration Testing Vendor
For SOC 2 purposes, the key criteria:
Certification: Look for firms with CREST accreditation or testers with OSCP, GPEN, or equivalent certifications. These signal methodological rigor that auditors recognize.
Scope experience: The firm should have explicit experience testing cloud-native SaaS applications on AWS, Azure, or GCP — not just traditional on-premise or network penetration testing.
Deliverable quality: You need a written report that includes: executive summary, technical findings with CVSS scores, proof of concept details (not just descriptions), and remediation recommendations. This report is what you share with customers and what your auditor reviews.
Retesting included: After you remediate critical and high findings, you need a retest to confirm the remediation is effective. This should be included in the engagement.
Managing and Documenting Findings
The penetration test report alone is not complete SOC 2 evidence. You also need evidence that findings were managed:
Sharing Pen Test Results with Customers
Enterprise customers increasingly request pen test reports as part of their vendor security reviews. Common sharing approaches:
Full report under NDA: Share the full technical report after the customer signs a mutual NDA. This is the most thorough option but requires NDA processing time.
Executive summary only: Share the executive summary (scope, methodology, finding counts by severity, remediation status) without detailed technical findings. This satisfies most initial security review requirements without exposing detailed attack paths.
Trust center summary: Display the test date, scope, testing firm name, and a summary of finding disposition on your public trust center. This answers the most common initial question without requiring any document exchange.
SecureSpect Pen Test Management
SecureSpect's Pen Tests module provides a structured workspace for uploading pen test reports, tracking findings from the report through remediation, and documenting risk acceptance decisions. When a customer asks for pen test evidence, you can export a clean finding-and-remediation status report directly from SecureSpect — no spreadsheet assembly required.