Does SOC 2 Require Penetration Testing?

Having advised dozens of companies through their SOC 2 audits, penetration testing is one of the most frequent questions we get at Agency. The short answer surprises most people — and the nuance matters more than you might think.

SOC 2 does not explicitly require penetration testing — the AICPA's Trust Service Criteria do not use the words "penetration test" anywhere in the framework. However, in our experience, most SOC 2 auditors expect penetration testing as evidence supporting several criteria, particularly CC4.1 (monitoring activities) and CC7.1 (identification of changes to system components that may introduce vulnerabilities). In practice, the question is not whether penetration testing is technically required by the standard but whether your auditor will accept your SOC 2 engagement without it. What we consistently see is that the vast majority of auditors expect penetration testing, and companies that skip it face a higher risk of receiving observations or exceptions related to their vulnerability management and security assessment practices.

This guide clarifies the relationship between SOC 2 and penetration testing: which Trust Service Criteria relate to pen testing, what auditors actually expect, the difference between vulnerability scanning and penetration testing, how to scope a pen test for SOC 2 purposes, frequency expectations, and how to handle the cost and logistics of penetration testing within a SOC 2 compliance program.

The Short Answer

Penetration testing is not a stated requirement in the SOC 2 Trust Service Criteria. The AICPA framework uses principles-based language that describes control objectives without prescribing specific testing methodologies. However, penetration testing is widely considered an industry best practice for assessing the effectiveness of security controls, and most auditors treat it as expected evidence for several criteria. In our experience, companies that skip penetration testing should be prepared to explain to their auditor how they assess the effectiveness of their security controls through alternative means — and should understand that many auditors will not consider the explanation sufficient.

What the Trust Service Criteria Actually Say

Criterion	Relevant Language	Connection to Penetration Testing
CC4.1	The entity selects, develops, and performs ongoing and/or separate evaluations to ascertain whether the components of internal control are present and functioning	Penetration testing serves as a "separate evaluation" that assesses whether security controls are functioning effectively
CC7.1	To meet its objectives, the entity uses detection and monitoring procedures to identify changes to configurations that result in the introduction of new vulnerabilities and susceptibilities to newly discovered vulnerabilities	Penetration testing identifies vulnerabilities that automated scanning may miss, particularly application-layer and logic-based vulnerabilities
CC7.2	The entity monitors system components and the operation of those components for anomalies that are indicative of malicious acts, natural disasters, and errors	Penetration test results validate that monitoring and detection controls would identify attack patterns
CC3.2	The entity identifies risks to the achievement of its objectives across the entity and analyzes risks as a basis for determining how the risks should be managed	Penetration test findings feed into the risk assessment by identifying real vulnerabilities that create organizational risk

Vulnerability Scanning vs Penetration Testing

Key Differences

Dimension	Vulnerability Scanning	Penetration Testing
Approach	Automated tools scan systems for known vulnerabilities using signature databases	Human testers actively attempt to exploit vulnerabilities using manual techniques and automated tools
Depth	Identifies known vulnerability signatures; limited to the tool's database	Tests for logic flaws, chained vulnerabilities, business logic errors, and attack paths that automated tools cannot detect
Frequency	Weekly or monthly (continuous is possible)	Annually at minimum; some organizations test semi-annually or quarterly
Output	List of identified vulnerabilities with severity ratings based on CVSS scores	Detailed report of exploitation attempts, successful penetrations, attack paths, and business impact assessment
Cost	$2,000-$10,000 annually for tooling	$5,000-$50,000+ per engagement depending on scope
SOC 2 relevance	Expected as a continuous control (CC7.1); demonstrates ongoing vulnerability identification	Expected as a periodic assessment (CC4.1); demonstrates deeper security evaluation
What it misses	Application logic flaws, chained attack paths, authentication bypass, authorization issues	Nothing by design, but scope limitations may exclude certain systems or attack types

Do You Need Both?

We recommend both vulnerability scanning and penetration testing as complementary controls, and most auditors we work with expect both. Vulnerability scanning provides continuous identification of known vulnerabilities across your infrastructure, while penetration testing provides periodic deep assessment that validates the effectiveness of your security controls against real-world attack techniques. Companies that perform only vulnerability scanning may face auditor questions about how they assess application-layer security, business logic vulnerabilities, and attack chain risks that automated scanning does not cover.

Scenario	Auditor Expectation	What We Recommend
First SOC 2 audit (Type I)	Vulnerability scanning in place; penetration test completed or scheduled	Complete at least one penetration test before or concurrent with the Type I audit
SOC 2 Type II audit	Vulnerability scanning running throughout observation period; at least one penetration test during or shortly before the observation period	Schedule the penetration test early in the observation period to allow time for remediation
Annual SOC 2 renewal	Vulnerability scanning continuous; annual penetration test	Align the penetration test timing with the observation period for maximum evidence value

How Auditors Evaluate Penetration Testing

What Auditors Look For

Evidence Element	Auditor Expectation	Common Deficiency
Test scope	Penetration test covered all in-scope production systems and applications	Test scope excluded critical systems or only covered infrastructure without application-layer testing
Test timing	Test was conducted within or close to the observation period	Test was conducted more than 12 months ago and does not reflect the current environment
Tester qualifications	Test was performed by qualified security professionals (internal or external)	Test was performed by unqualified staff or an automated-only approach was labeled as a penetration test
Findings documentation	Test report includes methodology, findings with severity classification, and evidence of exploitation attempts	Report is a generic template with minimal detail about actual testing performed
Remediation evidence	Critical and high-severity findings have been remediated or have documented remediation plans	Findings remain open without remediation plans or documented risk acceptance
Management response	Management reviewed findings and approved remediation priorities	No evidence that management was involved in reviewing or responding to test results

What Auditors Do Not Typically Require

Not Required	Explanation
Zero findings	Auditors expect penetration tests to identify findings — a test with zero findings may raise questions about test thoroughness
Specific testing methodology	Most auditors accept OWASP, PTES, or NIST SP 800-115 methodologies without requiring a specific one
Internal team testing	External third-party testing is most common, but qualified internal security teams can perform testing if they demonstrate independence
Red team exercises	Full red team engagements are beyond what SOC 2 auditors expect; standard penetration testing is sufficient
Testing of every application	Testing should cover in-scope systems; auditors understand that testing every system may not be practical for very large environments

Scoping a Penetration Test for SOC 2

What to Include in Scope

Scope Element	Inclusion Criteria	SOC 2 Relevance
Production web applications	All customer-facing applications within the SOC 2 system boundary	Application-layer vulnerabilities directly affect customer data security
Production APIs	All APIs that handle customer data or authentication	API security is critical for multi-tenant SaaS applications
Cloud infrastructure	Production cloud environment configurations and network architecture	Infrastructure vulnerabilities can compromise all applications running on the environment
Authentication systems	Login flows, MFA implementation, session management	Access control effectiveness is central to SOC 2 Security criteria
Internal network (if applicable)	Internal systems accessible from the corporate network	Relevant if the SOC 2 scope includes internal network components
Third-party integrations	Integration points with subservice organizations and vendors	Insecure integrations can create data exposure paths

Scoping Decisions

Decision	Options	Our Guidance for SOC 2
External vs internal testing	External only, internal only, or both	At minimum, external testing of production applications; add internal testing if the SOC 2 scope includes internal network
Black box vs gray box vs white box	Varies by information provided to testers	Gray box testing (providing testers with some architecture information and credentials) delivers the best balance of realism and thoroughness for SOC 2
Application vs infrastructure	Application-layer only, infrastructure only, or both	We recommend both application and infrastructure testing; application-only testing misses infrastructure vulnerabilities and vice versa
Automated + manual vs automated only	Pure automated scanning or automated tools supplemented by manual testing	Automated tools supplemented by manual testing is the standard expectation; automated-only approaches are generally considered vulnerability scanning, not penetration testing

Frequency and Timing

How Often Should You Penetration Test

Frequency	When Appropriate	Auditor Acceptance
Annually	Standard for most organizations; aligns with annual SOC 2 audit cycles	Widely accepted as the minimum frequency
Semi-annually	Organizations with high-risk environments, frequent application changes, or sensitive data	Exceeds minimum expectations; demonstrates strong security posture
Quarterly	Organizations in highly regulated industries or with rapidly changing applications	Exceeds expectations; typically only necessary for very high-risk environments
After major changes	Following significant infrastructure changes, application rewrites, or architecture modifications	Expected as a supplement to scheduled testing; demonstrates risk-aware testing approach

Timing Relative to the SOC 2 Audit

Timing Strategy	Advantage	Disadvantage
Early in the observation period	Maximum time to remediate findings before the audit	Findings may be stale by end of observation period
Mid-observation period	Balanced between allowing remediation time and keeping results current	Remediation of critical findings may be rushed
Late in the observation period	Results are maximally current for the auditor	Limited time to remediate findings; critical findings may appear as exceptions
Before the observation period begins	Findings drive remediation that improves controls before observation starts	Test does not fall within the observation period and may need supplementation

What we recommend for most of our clients is to schedule the penetration test in the first half of the observation period. This provides evidence that falls within the observation window while allowing adequate time to remediate findings before the auditor evaluates your controls.

Cost and Logistics

Penetration Testing Cost Ranges

Test Scope	Cost Range	Duration	Typical Provider
Small web application (single app, limited API)	$5,000-$12,000	3-5 days	Boutique security firm
Standard SaaS application (web app + APIs + infrastructure)	$12,000-$30,000	5-10 days	Mid-market security firm
Complex multi-application environment	$25,000-$50,000	10-20 days	Established security consultancy
Enterprise environment (multiple apps, internal network, cloud infrastructure)	$40,000-$100,000+	15-30+ days	Large security firm

Selecting a Penetration Testing Vendor

Selection Criteria	What to Evaluate	Red Flags
Qualifications	Certifications (OSCP, GPEN, CREST) and demonstrated experience	No verifiable certifications; inability to provide sample reports
Methodology	Uses recognized methodologies (OWASP, PTES, NIST 800-115)	No documented methodology; relies entirely on automated tools
Report quality	Provides detailed reports with reproducible findings, severity ratings, and remediation guidance	Generic reports with only tool output; no manual testing evidence
Industry experience	Experience testing similar applications and environments to yours	No experience with your technology stack or industry
Remediation support	Provides retesting after remediation to verify fixes	No retesting option; engagement ends with report delivery
Communication	Clear scoping process, rules of engagement, and status updates during testing	Vague scope definitions; no communication during the engagement

Alternatives and Compensating Controls

If You Cannot Perform Penetration Testing

Alternative	Auditor Acceptance	Limitations
Comprehensive vulnerability scanning with manual review	May be accepted for Type I; less likely for Type II	Does not assess application logic flaws or chained attack paths
Bug bounty program	Supplementary evidence; unlikely to replace formal penetration testing	Inconsistent coverage; no guaranteed testing of all in-scope systems
Security code review	Valuable complementary evidence; does not replace runtime testing	Identifies code-level issues but not deployment or configuration vulnerabilities
Automated application security testing (DAST/SAST)	Supplementary evidence; unlikely to replace penetration testing	Automated tools miss logic flaws and complex attack chains

The strongest position is to perform a formal penetration test. If budget or timing constraints make a full engagement impossible before the first audit, we advise our clients to communicate proactively with their auditor about the planned testing schedule and the compensating controls in place. Some auditors will accept a scheduled penetration test with a defined completion date, particularly for Type I engagements where the assessment is point-in-time.

Key Takeaways

• We consistently see that SOC 2 auditors treat penetration testing as expected evidence for CC4.1 (monitoring activities) and CC7.1 (vulnerability identification), even though the Trust Service Criteria do not explicitly require it — companies that skip penetration testing face a higher risk of audit observations
• What we recommend is treating penetration testing and vulnerability scanning as complementary, not interchangeable — vulnerability scanning identifies known vulnerabilities through automated tools, while penetration testing uses human testers to identify logic flaws, chained attack paths, and application-level vulnerabilities that scanners miss
• Annual penetration testing is the standard minimum frequency for SOC 2, and we advise scheduling the test in the first half of the observation period to provide current evidence while allowing time for remediation of findings
• In our experience, the right SOC 2 penetration test scope should include production web applications, APIs, cloud infrastructure, and authentication systems — gray box testing (providing testers with some architecture information) delivers the best balance of thoroughness and realism
• Cost ranges from $5,000-$30,000 for most startup and growth-stage SaaS companies, with scope and application complexity as the primary cost drivers
• Auditors evaluate penetration test evidence on five dimensions: scope coverage, test timing, tester qualifications, findings documentation, and remediation evidence — we advise our clients to ensure all five are addressed before presenting the evidence
• We help our clients select penetration testing vendors, define appropriate scope for SOC 2 purposes, and integrate test findings into the broader compliance evidence program

Frequently Asked Questions

Will my auditor accept vulnerability scanning instead of penetration testing?

What we tell clients is to plan for needing both. Most auditors will not accept vulnerability scanning as a complete substitute for penetration testing. Vulnerability scanning is an automated process that identifies known vulnerability signatures, while penetration testing involves human testers actively attempting to exploit vulnerabilities — they assess fundamentally different aspects of your security posture. Some auditors may accept vulnerability scanning alone for a Type I audit if you can demonstrate a scheduled penetration test, but for Type II audits most auditors expect at least one penetration test during or close to the observation period. The advice we give is to discuss this with your auditor early in the engagement to set clear expectations.

How do I handle penetration test findings that reveal serious vulnerabilities?

The advice we give is to remediate critical and high-severity findings as quickly as possible, ideally before the SOC 2 audit fieldwork evaluates the relevant controls. Document the finding, your remediation plan, the remediation implementation, and verification testing that confirms the fix is effective. Auditors do not expect zero findings from penetration tests — in fact, a test with no findings may raise questions about the test's thoroughness. What auditors do expect, and what we coach our clients to demonstrate, is evidence that your organization identified the findings, assessed their risk, implemented remediation for critical and high-severity items, and verified the remediation was effective. Medium and low-severity findings should have documented remediation plans with target dates, even if remediation is not yet complete at the time of the audit.

Can our internal security team perform the penetration test?

What we tell clients is that internal penetration testing is acceptable to some auditors, provided the testers can demonstrate independence from the systems being tested and possess appropriate qualifications (OSCP, GPEN, or equivalent experience). The key concern is objectivity — if the same team that built and maintains the application also tests it, the auditor may question whether the testing was sufficiently rigorous and independent. In our experience, external third-party testing is more common and less likely to raise auditor questions about independence. If budget constraints make external testing prohibitive for the first audit, we recommend internal testing with documented methodology and qualified testers over no testing at all.

When should I schedule the penetration test relative to my SOC 2 audit?

The advice we give for Type II audits is to schedule the penetration test in the first half of the observation period. This ensures the test results fall within the observation window (satisfying the auditor's evidence timing requirements) while providing adequate time to remediate any critical or high-severity findings before the auditor evaluates your controls. For Type I audits, we recommend scheduling the test before or concurrent with the audit engagement. What we consistently warn clients about is scheduling the test immediately before the audit begins — a test that reveals significant vulnerabilities just days before audit fieldwork starts creates a difficult situation where findings may appear as exceptions because there was no time for remediation.