Does SOC 2 Require Penetration Testing?
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.
Key Takeaways
- •What we recommend for most of our clients is to schedule the penetration test in the first half of the observation period.
- •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.
- •For the next operating decision, compare penetration test reporting with compliance penetration testing.
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. 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.
For the next operating decision, compare penetration test reporting with compliance penetration testing. Confirm the work included, the evidence you need, and who will own implementation before committing to a provider.
What is the short answer about SOC 2 penetration testing?
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 |
How do vulnerability scanning and penetration testing differ?
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 | Varies based on tooling choice | Varies 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 | Depends on scope and readiness |
| 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 |
Cost and Logistics
Penetration Testing Cost Ranges
| Test Scope | Cost | Duration | Typical Provider |
|---|---|---|---|
| Small web application (single app, limited API) | Varies based on scope | 3-5 days | Boutique security firm |
| Standard SaaS application (web app + APIs + infrastructure) | Varies based on scope | 5-10 days | Mid-market security firm |
| Complex multi-application environment | Varies based on scope | 10-20 days | Established security consultancy |
| Enterprise environment (multiple apps, internal network, cloud infrastructure) | Varies based on scope | 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.
AICPA & CIMA’s SOC overview describes CPA assurance services. It defines the assurance context; it does not establish vendor rankings, market prices, or a particular company’s readiness.
Frequently Asked Questions
Does SOC 2 require a penetration test?
Is vulnerability scanning enough, or do you need a pen test?
Tyler Carbone
Managing Director and Cofounder
Tyler Carbone is a Managing Director and Cofounder of Agency and one of the industry's leading voices on governance, risk, and compliance. He holds degrees from Harvard and a JD/MBA from the University of Virginia, and previously worked in cybersecurity at Deloitte. Tyler has helped hundreds of companies operate SOC 2, ISO 27001, HIPAA, and GDPR programs.
LinkedIn
