SOC 2 is the dominant trust and security certification for technology service providers, SaaS companies, and cloud platforms — particularly those serving enterprise customers in the US and increasingly in the EU. Unlike PCI DSS, SOC 2 does not explicitly require penetration testing. But if you're pursuing SOC 2 Type II — and especially if your customers are asking about your security posture — penetration testing has become a de facto expectation that auditors and enterprise procurement teams take seriously.
SOC 2 is built around the AICPA's Trust Service Criteria (TSC). The Security category — CC6 and CC7 — includes controls around logical and physical access, system monitoring, and vulnerability management:
Penetration testing doesn't map directly to a single SOC 2 control. Instead, it provides evidence across multiple criteria — demonstrating that access controls actually prevent unauthorized access (not just that policies say they should), and that monitoring systems detect real attacks (not just theoretical ones).
Three trends have driven the shift from penetration testing as an optional SOC 2 activity to an increasingly expected one:
Large enterprise customers conducting vendor security assessments now routinely ask for penetration test reports as part of security due diligence questionnaires. Many organizations pursuing SOC 2 are doing so specifically to close enterprise deals — and those deals may require a recent pentest report alongside the SOC 2 attestation.
While AICPA does not mandate penetration testing, individual SOC 2 auditors increasingly ask about it when evaluating vulnerability management controls. Organizations that cannot demonstrate how they verify their security controls are effective may find their SOC 2 report qualified with weaknesses in vulnerability management.
Cyber insurers use SOC 2 certification as one signal of security maturity, but they also ask separately about penetration testing. A SOC 2 attestation without an underlying penetration test can result in higher premiums or exclusions for certain attack vectors.
For SOC 2 Type I (point-in-time attestation of control design), penetration testing supports the design evaluation but is less critical — Type I asks whether controls are designed appropriately, not whether they work under attack.
For SOC 2 Type II (attestation of control effectiveness over an observation period, typically 6–12 months), penetration testing is much more relevant. Auditors evaluating whether access controls and monitoring have been effective over the period will find a penetration test conducted during that period to be strong supporting evidence.
Best practice: conduct a penetration test before your SOC 2 Type II observation period begins, remediate critical findings, and include the test evidence in your control documentation. This gives auditors clean evidence of both testing and remediation.
| Criteria | Control Intent | How Penetration Testing Supports It |
|---|---|---|
| CC6.1 | Logical access controls prevent unauthorized access | Pentest verifies controls cannot be bypassed |
| CC6.6 | Network and infrastructure controls block external threats | External pentest validates perimeter security |
| CC7.1 | Vulnerability management process identifies and remediates weaknesses | Pentest provides manual vulnerability evidence beyond automated scans |
| CC7.2 | Security events are detected and evaluated | Pentest may reveal gaps in detection and logging |
SOC 2 testing scope should align with your defined system boundary — the set of infrastructure, software, and data covered by your SOC 2 report. This typically includes:
If you're unsure what falls within your SOC 2 system boundary, Q-Sec's compliance consulting team can help you define it before the penetration test — which also helps manage cost and scope creep.
Many technology companies pursue both SOC 2 and ISO 27001 — SOC 2 for North American market access and ISO 27001 for European enterprise customers. A penetration test conducted for one framework can satisfy both, provided the scope and methodology are aligned.
Q-Sec can structure a single engagement that generates evidence for SOC 2 (vulnerability management controls), ISO 27001 (Annex A control verification), and — if applicable — NIS2 or DORA requirements. See our guide on ISO 27001 penetration testing for details on multi-framework scoping.
Not always — but increasingly, yes. Auditors evaluating vulnerability management and access control effectiveness as part of SOC 2 Type II often request penetration test evidence. Whether it is formally required depends on the auditor and the controls you have mapped. If you operate in competitive markets where enterprise customers conduct vendor due diligence, having a recent pentest report is important regardless of auditor expectations.
No formal age requirement exists in SOC 2 standards. In practice, a test conducted within the observation period (or shortly before it) is most useful for SOC 2 Type II. Enterprise customers conducting vendor assessments typically expect a test within the past 12 months.
Yes. Q-Sec provides penetration testing aligned to SOC 2 Trust Service Criteria and compliance consulting for organizations preparing for their first SOC 2 audit or maintaining continuous readiness. Our Managed SIEM and SOC-as-a-Service provide the ongoing monitoring controls that SOC 2 Type II auditors evaluate throughout the observation period.
SOC 2 ready? Q-Sec delivers penetration testing and compliance consulting that supports your full Trust Service Criteria program. Contact team@q-sec.com