SOC 2 Penetration Testing: What Auditors Actually Require

Every week, someone discovers mid-audit that their auditor wants a penetration test. The Reddit thread at position three in search results for "SOC 2 penetration testing" is titled "In the middle of my SOC2 audit and they said I need a pentest." It has fifty replies from people who found themselves in the same situation.

The confusion is structural. SOC 2 does not contain a line that says "you must conduct a penetration test." It contains Trust Service Criteria that require evidence of security monitoring, logical access controls, and vulnerability management, and experienced auditors interpret those criteria to require penetration testing as the most credible form of security validation evidence.

Understanding exactly which criteria create the testing obligation, what evidence satisfies them, and what auditors actually examine is what separates a successful SOC 2 audit from an expensive surprise. This post covers all three.

Does SOC 2 require penetration testing?

Not literally, by name. The AICPA Trust Services Criteria do not contain the words "penetration test" as a mandatory requirement. What they contain are criteria that, in practice, require penetration testing evidence to satisfy.

The criteria most directly relevant are in the Common Criteria (CC) category, specifically CC6.1, CC6.6, CC6.8, and CC7.1. Each creates an expectation for security testing evidence that a vulnerability scan does not fully satisfy and that an experienced auditor will probe.

The criteria that create the penetration testing obligation

CC6.1: Logical and physical access controls

CC6.1 requires the organization to implement logical access security software, infrastructure, and architectures over protected information assets to protect them from security events. Specifically, it addresses the design and effectiveness of access control mechanisms.

Auditors evaluating CC6.1 look for evidence that access controls actually work, not just that they are configured. Penetration testing that attempts to bypass access controls and demonstrates whether they hold or fail under real attack conditions is the most direct evidence that CC6.1 controls are effective rather than merely present.

CC6.6: Logical access to assets from outside the entity's boundaries

CC6.6 addresses security over logical access from outside the system boundary, essentially the external attack surface. It requires that access from external sources be managed and controlled.

This criterion most directly maps to external penetration testing: testing of internet-facing systems, APIs, and remote access mechanisms from the perspective of an external attacker. An annual external penetration test is the standard approach for producing CC6.6 evidence, and its scope should cover the full external attack surface including web applications, APIs, authentication mechanisms, and infrastructure.

CC6.8: Prevention or detection of unauthorized or malicious software

CC6.8 requires controls to prevent or detect malicious software and protect against cybersecurity events. Auditors interpret this to include evidence that the organization's security controls are tested against realistic attack scenarios.

This criterion creates the strongest explicit case for penetration testing: it requires evidence that you have validated your controls against realistic attack methods, not just that you have deployed tools that theoretically provide protection.

CC7.1: Detection and monitoring of events

CC7.1 requires ongoing monitoring of the system to detect potential threats and anomalies. In the context of penetration testing, it creates a timing expectation: security testing should occur during the audit period and be aligned with the monitoring program, not just conducted once at the beginning of a SOC 2 readiness exercise and then never repeated.

This criterion is where auditors for SOC 2 Type II engagements pay the most attention to testing timing. A penetration test conducted eighteen months before the audit period does not demonstrate ongoing security monitoring. A test conducted during the audit period (or, better, a continuous testing program that operates throughout it) satisfies CC7.1's monitoring intent far more directly.

What auditors actually examine

Understanding what auditors look for during the SOC 2 review changes what organizations need to produce. Based on audit practice across the industry, SOC 2 auditors typically examine:

Test recency relative to the audit period. For SOC 2 Type II, the audit period is typically twelve months. A penetration test conducted before the audit period started is weak evidence of monitoring during the period. Auditors prefer evidence that testing occurred within the audit period, ideally within the preceding six to twelve months.

Scope coverage relative to the system description. The system description in the SOC 2 report defines what the organization claims is in scope. Auditors compare the penetration test scope to the system description and will note gaps. If the system description includes a customer-facing API but the penetration test scope does not, the auditor will ask why.

Distinction between vulnerability scanning and penetration testing. This is where many organizations discover they have the wrong artifact. A vulnerability scan report lists potential vulnerabilities based on signature matching. A penetration test report demonstrates exploitation attempts and confirmed findings. Auditors, particularly at firms with technical security expertise, know the difference and will ask clarifying questions if the report looks like scanner output. What is inside a VAPT report covers what distinguishes a credible report from a scanner report dressed up as a pentest.

Remediation evidence. Finding a vulnerability and reporting it is the first half of what auditors want to see. The second half is evidence that findings were remediated and that remediation was confirmed. A finding list without a remediation tracking record leaves the auditor uncertain whether identified vulnerabilities were addressed before the audit period closed. What a real web application penetration test should cover includes remediation validation as one of the twelve essential components of a complete assessment.

Tester independence. For SOC 2 evidence, an internal team testing their own systems provides weaker evidence than an independent external provider. Auditors note who conducted the test. For organizations seeking SOC 2 reports reviewed by sophisticated buyers (enterprise security teams, large financial institutions), tester independence is a quality signal that matters beyond the letter of the criteria.

Why vulnerability scanning does not satisfy SOC 2

This is the most common error in SOC 2 security testing programs. Organizations conduct regular vulnerability scans, assume this satisfies the security testing criteria, and discover during audit review that the auditor disagrees.

The distinction is foundational. A vulnerability scan identifies potential vulnerabilities through pattern matching. It does not attempt to exploit them, does not confirm which findings are actually exploitable in the specific environment, and does not cover vulnerability classes with no signatures, including business logic flaws, authorization gaps across user roles, and chained attack paths.

SOC 2 auditors evaluating CC6.8 (preventing and detecting unauthorized access) want evidence that security controls hold under realistic attack conditions. A vulnerability scan tells you what patterns were detected. A penetration test tells you what was actually exploitable and what an attacker could have achieved.

How DAST compares to agentic penetration testing on real-world coverage covers the specific gap between what automated scanning finds and what genuine penetration testing finds. For SOC 2 purposes, that gap is exactly what auditors are trying to close by asking for penetration testing evidence.

SOC 2 Type I vs Type II: different testing expectations

SOC 2 Type I reports on the suitability of the design of controls at a point in time. A penetration test conducted before or during the Type I assessment period and submitted as evidence that security controls are suitably designed satisfies the standard expectation. Recency is important but the one-time nature of the assessment means a single annual test is generally acceptable.

SOC 2 Type II reports on the operating effectiveness of controls over a period, typically twelve months. This is where the timing requirement becomes more demanding. An auditor evaluating whether security monitoring was effective over a twelve-month period wants to see evidence of security testing that occurred during that period, not evidence from before the period started.

For organizations pursuing SOC 2 Type II, this creates a practical argument for continuous or more frequent penetration testing rather than annual. Continuous penetration testing and how it differs from annual pentests covers the operational model. A continuous testing program that operates throughout the audit period produces evidence of ongoing security monitoring that satisfies CC7.1 more directly than a single annual engagement.

What the SOC 2 penetration test scope should cover

The scope of a SOC 2 penetration test should map to the system description in the SOC 2 report. Auditors check this mapping. Systems described as in-scope for the SOC 2 report that are absent from the penetration test scope create a gap that auditors will note.

At minimum, the scope should cover:

External attack surface. All internet-facing systems included in the system description: customer-facing web applications, public APIs, authentication endpoints, and any remotely accessible administrative interfaces.

Internal network and access controls. Internal network segmentation relevant to the protection of sensitive data in scope, and the access controls governing who can reach those systems from within the network.

API layers. Modern SaaS applications expose most functionality through APIs. API security testing should be scoped as a distinct component, applying the API-specific methodology that standard web application testing does not cover. API vulnerabilities standard penetration tests miss covers the eight classes most commonly absent from SOC 2 pentest scopes.

Authenticated application surfaces. Testing under multiple user roles to confirm that authorization boundaries prevent horizontal and vertical privilege escalation. CC6.1's access control evidence requirement is most directly satisfied by testing whether access controls hold under realistic attack conditions with valid credentials.

Timing: when to conduct the pentest relative to the audit

For SOC 2 Type I, timing is flexible. Conducting the penetration test during readiness preparation, ideally within six months of the Type I assessment date, produces reasonable evidence.

For SOC 2 Type II, the audit period is the relevant window. Auditors reviewing a twelve-month audit period want to see testing that occurred during that period. A common approach is to conduct the annual pentest three to four months before the audit period ends, which provides time to remediate findings before the period closes and allows the remediation record to be included in the evidence package.

Organizations that conduct a penetration test as part of SOC 2 readiness and then do not repeat it during subsequent Type II audit periods are producing evidence of a one-time assessment rather than an ongoing security program. The most defensible SOC 2 security testing program for Type II includes testing that occurs within every audit period, with evidence of remediation and ideally retesting to confirm findings are closed.

How continuous agentic testing maps to SOC 2

Agentic pentesting and continuous security validation is the model that most directly satisfies SOC 2's monitoring-oriented criteria.

For CC7.1 (ongoing monitoring), a continuous testing program that runs throughout the audit period produces evidence that security monitoring is operating continuously rather than as an annual event. The timestamped record of assessments, findings, and remediation confirmations demonstrates the kind of ongoing security vigilance the criterion intends.

For CC6.8 (preventing and detecting malicious activity), a continuous testing program that validates controls against realistic attack scenarios on an ongoing basis satisfies the criterion's operating effectiveness requirement more directly than a once-yearly snapshot.

How autonomous pentesting produces a continuous compliance evidence record covers how the continuous model generates the evidence portfolio that auditors want to see: not just a report, but a running record of security testing, identified findings, remediation actions, and closure confirmations.

For penetration testing services in the US structured for SOC 2 evidence production, or PTaaS and agentic penetration testing for the continuous audit-period coverage model, the 10x Pentest platform produces findings with proof-of-exploitation evidence, remediation tracking, and same-day retest confirmation. See pricing for what continuous coverage costs relative to annual manual engagements, or get in touch to discuss building a SOC 2 security testing program around your audit timeline.

Frequently asked questions

Q1. Does SOC 2 require a penetration test?

SOC 2 does not mandate a penetration test by name. However, the Trust Service Criteria (specifically CC6.1, CC6.6, CC6.8, and CC7.1) require evidence of security control effectiveness and ongoing security monitoring that experienced SOC 2 auditors satisfy through penetration testing evidence. In practice, if your auditor reviews these criteria seriously and your system description includes significant internet-facing applications or APIs, you will need penetration testing evidence. The Reddit thread that shows up at position three for this search term exists because many organizations discover this during the audit rather than before it.

Q2. How often should a penetration test be done for SOC 2?

For SOC 2 Type I, once before or during the assessment period is the standard expectation. For SOC 2 Type II, testing should occur within every twelve-month audit period. Conducting a penetration test once during SOC 2 readiness and not repeating it in subsequent Type II audit periods produces evidence of a one-time event rather than ongoing security monitoring. The most defensible approach for Type II is annual penetration testing timed to occur three to four months before the audit period closes, with remediation documented before period end. Continuous penetration testing throughout the audit period satisfies the CC7.1 monitoring criterion more directly.

Q3. Will a vulnerability scan satisfy SOC 2 penetration testing requirements?

No. A vulnerability scan identifies potential vulnerabilities through signature matching without confirming whether those vulnerabilities are exploitable in the specific environment. SOC 2 auditors, particularly those with technical security backgrounds, distinguish between vulnerability scan output and penetration test findings. CC6.8 requires evidence that controls are effective against realistic attack scenarios, which signature matching does not demonstrate. If your current security testing program consists of vulnerability scanning and you are uncertain whether it satisfies your auditor's expectations, ask the auditor directly and early rather than at the end of the audit period.

Q4. What should a SOC 2 penetration test report contain?

A SOC 2-appropriate penetration test report should contain: a scope statement mapping to the system description in the SOC 2 report; findings with proof-of-exploitation evidence rather than theoretical signature matches; severity ratings for each finding; remediation guidance specific to the technology stack; and a remediation tracking section or companion document showing which findings were addressed and when. Separately, the organization should maintain retest confirmation records showing that identified vulnerabilities were closed before the audit period ended. An auditor reviewing this package has everything needed to evaluate CC6.1, CC6.6, CC6.8, and CC7.1 without asking supplementary questions.

Q5. Can we use the same penetration test report for multiple compliance frameworks?

Yes, in many cases. A well-scoped penetration test that covers your external attack surface, internal access controls, API layers, and authenticated application surfaces produces evidence relevant to SOC 2 (CC6 and CC7), ISO 27001 (Annex A control A.12.6), PCI DSS (Requirement 11.4), and HIPAA (reasonable security arrangements). The key is ensuring the scope covers the systems that each framework treats as in-scope. For healthcare organizations managing both SOC 2 and HIPAA, HIPAA penetration testing requirements covers the seven specific gaps that healthcare-specific testing must address beyond standard SOC 2 scope expectations.