SOC 2 Penetration Testing Requirements

SOC 2 penetration testing sits at the intersection of audit compliance and offensive security practice, governing how service organizations demonstrate the operational effectiveness of their security controls to auditors and customers. The SOC 2 framework, administered by the American Institute of Certified Public Accountants (AICPA), does not mandate penetration testing as an explicit line-item requirement — but the Trust Services Criteria it enforces make substantive penetration testing a practical necessity for most organizations seeking an unqualified opinion. This page covers the scope of penetration testing within SOC 2 engagements, the mechanics of how such tests are structured, the scenarios in which they arise, and the decision criteria that distinguish compliant from insufficient approaches.

Definition and scope

SOC 2 is an attestation framework developed by the AICPA under its System and Organization Controls suite. It evaluates service organizations — cloud providers, SaaS vendors, managed service providers, and similar entities — against 5 Trust Services Criteria: Security, Availability, Processing Integrity, Confidentiality, and Confidentiality of Privacy. The Security criterion (CC6-CC9 within the 2017 Trust Services Criteria) addresses logical and physical access controls, change management, and risk mitigation — categories where penetration testing generates direct, examiner-reviewed evidence.

Penetration testing is not explicitly named in the AICPA Trust Services Criteria text, but CC7.1 requires that organizations monitor for security threats and use detection tools, while CC9.2 addresses vendor and business partner risk management. Auditors treating SOC 2 under SSAE 18 (Statements on Standards for Attestation Engagements No. 18) evaluate whether controls are designed and operating effectively — a test-of-effectiveness inquiry that penetration testing directly supports by providing adversarially validated evidence rather than self-reported control status.

The scope of a SOC 2 penetration test typically mirrors the system boundary defined in the organization's System Description document. That boundary determines which assets — production environments, APIs, internal networks, administrative interfaces — fall within the engagement. Excluding in-scope infrastructure from the penetration test creates an evidence gap that auditors can flag as a scope limitation.

For organizations navigating how this testing category fits within the broader service landscape, the penetration testing providers section of this resource covers qualified providers structured by specialty.

How it works

A SOC 2-oriented penetration test follows a phased structure aligned to recognized methodology frameworks, including NIST SP 800-115 (Technical Guide to Information Security Testing and Assessment) and the PTES (Penetration Testing Execution Standard). The discrete phases are:

1. Scoping and rules of engagement — The test boundary is defined against the SOC 2 system description. Authorization documentation is executed to satisfy legal requirements under 18 U.S.C. § 1030 (Computer Fraud and Abuse Act).
2. Reconnaissance — Passive and active information gathering against in-scope systems, including DNS enumeration, certificate transparency analysis, and service fingerprinting.
3. Vulnerability identification — Automated scanning combined with manual inspection to enumerate attack surface. This phase produces findings that vulnerability-scanner-only programs stop at; penetration testing continues to exploitation.
4. Exploitation — Testers attempt to chain vulnerabilities — privilege escalation, lateral movement, credential harvesting — to demonstrate real-world impact. This distinguishes penetration testing from a vulnerability assessment and is the phase that satisfies auditor requests for evidence of control effectiveness.
5. Post-exploitation and documentation — The extent of access achieved is documented with reproducible evidence (screenshots, logs, command output). Impact is rated against confidentiality, availability, and integrity of the systems in scope.
6. Reporting — A formal report is produced covering executive summary, technical findings, evidence artifacts, and remediation guidance. This report becomes audit evidence submitted to the SOC 2 auditor.

SOC 2 auditors typically request penetration test reports conducted within the audit period — the trailing 12 months for Type 2 engagements. A report older than 12 months at the time of the audit opinion period creates a coverage gap.

Common scenarios

Type 1 vs. Type 2 engagements. A SOC 2 Type 1 report evaluates the design of controls at a point in time; a Type 2 report evaluates operating effectiveness over a period, typically 6 to 12 months. Penetration testing evidence is most relevant to Type 2 engagements because it demonstrates that monitoring and detection controls are operationally active, not merely documented. Organizations pursuing a Type 1 as a first-year report may still conduct penetration testing to satisfy customer security questionnaires and to prepare for the Type 2 cycle.

Cloud-hosted SaaS providers. The most common scenario involves a SaaS company using AWS, Azure, or GCP infrastructure where the shared responsibility model limits what the provider controls directly. The penetration test scope focuses on the application layer, APIs, authentication mechanisms, and tenant isolation controls — the components the provider owns — rather than the underlying hypervisor infrastructure controlled by the cloud platform.

Network segmentation validation. Organizations with internal networks serving the in-scope service must validate that segmentation controls prevent lateral movement from lower-trust zones into the production environment. Penetration testers attempt to breach segment boundaries, and the results feed directly into CC6.6 (logical access restriction) evidence.

Third-party testing independence. Most SOC 2 auditors expect penetration testing to be conducted by a party independent of the organization's internal security team. Internal red team results are occasionally accepted, but auditors assess the tester's independence as part of evaluating the weight of the evidence. Third-party firms with qualified practitioners — holding credentials such as OSCP (Offensive Security Certified Professional) or GPEN (GIAC Penetration Tester) — are the standard expectation.

The penetration testing provider network purpose and scope page describes how provider categories are classified across this reference network.

Decision boundaries

Annual cadence vs. event-triggered testing. A 12-month testing cycle satisfies the operating-period coverage requirement for most Type 2 engagements. Significant infrastructure changes — a major cloud migration, a new product line entering scope, acquisition of a technical asset — typically require a supplemental test outside the annual cycle to maintain evidence continuity.

Scope inclusions that cannot be waived. Any system or sub-system processing, storing, or transmitting data that falls within the SOC 2 system description must be included in the penetration test scope. Removing a component because it is "low risk" without documented risk acceptance creates an auditable gap. The AICPA's SOC 2 Guide makes clear that the system description must accurately reflect the service being evaluated.

Automated scanning as a substitute. Automated vulnerability scanning does not satisfy the evidence standard that penetration testing meets. Scanning identifies vulnerabilities; penetration testing demonstrates exploitability and impact. Auditors familiar with the distinction — particularly at firms with dedicated IT audit practices — will differentiate between scan output and a penetration test report when assessing CC7.1 and CC9.2.

Remediation and retesting. A penetration test that identifies critical findings requires documented remediation and, in most cases, a targeted retest confirming closure. Submitting a report with open critical findings without remediation evidence presents an auditor with evidence of a control gap, not control effectiveness. Remediation timelines vary by severity, but critical findings — those enabling unauthorized access to customer data — require closure before the audit opinion period closes.

For a broader orientation to how this testing type fits within the full service landscape, the how to use this penetration testing resource page provides structural context on provider categories and engagement types covered across this reference.