If you’re pursuing SOC 2 Type II certification — or you’re in the middle of an audit cycle — you’ve probably encountered a question that auditors, customers, and prospects ask with increasing frequency: Do you perform regular penetration testing?
The honest answer is that SOC 2 doesn’t use the phrase “penetration testing” in its core framework. But that answer is incomplete in a way that trips up a lot of SaaS and technology companies. In practice, penetration testing has become a standard expectation for SOC 2 Type II readiness, and organizations that omit it from their security program often find out during an audit — not before.
This guide explains exactly what SOC 2 requires, where penetration testing fits, and what you need to do to prepare your organization for a successful audit.
What Is SOC 2 and Who Needs It?
SOC 2 (System and Organization Controls 2) is an auditing standard developed by the American Institute of Certified Public Accountants (AICPA). It evaluates how a service organization manages customer data against five Trust Services Criteria (TSC):
1. Security — Protection against unauthorized access (required for all SOC 2 reports)
2. Availability — System availability as agreed or committed
3. Processing Integrity — Complete, accurate, and timely processing
4. Confidentiality — Protection of confidential information
5. Privacy — Collection and use of personal information
The Security category is mandatory. The others are optional depending on your service commitments and customer requirements.
Who needs SOC 2? Any service organization that stores, processes, or transmits customer data — particularly SaaS companies, cloud service providers, managed service providers, data analytics firms, and fintech platforms. Enterprise buyers increasingly require SOC 2 Type II as a condition of doing business.
Type I vs. Type II
The difference matters for penetration testing. Type I audits sometimes proceed without penetration testing — but for Type II, the operating effectiveness bar is significantly higher.
Does SOC 2 Require Penetration Testing?
Not explicitly — but effectively, yes, for most organizations pursuing Type II.
Here’s the technical answer: The AICPA’s Trust Services Criteria reference “risk assessment” (CC3), “monitoring activities” (CC4), “logical and physical access controls” (CC6), and “system operations” (CC7) as the core security criteria. None of these name penetration testing directly.
But here’s where the practical requirement emerges.
The CC7 Connection
CC7.1 requires that organizations “use detection and monitoring procedures to identify changes to configurations or new vulnerabilities.” CC7.2 requires response to identified vulnerabilities. These controls, combined with CC4 (monitoring and evaluation of the control environment), create a framework where auditors routinely ask: How do you know your controls are effective?
A vulnerability scan answers part of that question. A penetration test answers it more completely — because it tests whether identified vulnerabilities are actually exploitable, whether your detective controls respond as designed, and whether an attacker following a realistic path would be stopped at each layer.
What Auditors Actually Look For
SOC 2 auditors don’t follow a rigid checklist. They evaluate the design and operating effectiveness of your control environment against the applicable Trust Services Criteria. For the Security category, experienced auditors commonly:
An organization that has never performed penetration testing, or can’t demonstrate regular security testing over the Type II audit period, will have a harder time satisfying auditors on the operating effectiveness of CC3, CC4, and CC7 controls.
Practically speaking: most SOC 2 Type II auditors expect to see penetration testing conducted within the audit period, especially for companies with meaningful cloud infrastructure, APIs, or customer data handling.
Customer and Prospect Expectations
Even if your auditors are flexible, your customers often aren’t. Enterprise security questionnaires (SIG, CAIQ, custom vendor assessments) routinely ask about penetration testing frequency, findings, and remediation. A SOC 2 report that doesn’t address penetration testing leaves a gap that prospects will probe directly.
SOC 2 Penetration Testing: What’s Required
While the framework doesn’t specify exact requirements, the following reflects what organizations typically need to satisfy auditors and pass a rigorous Type II audit:
Scope
Your penetration testing scope should cover the systems in your SOC 2 scope — the infrastructure, applications, and services that handle customer data subject to your audit. At minimum, this typically includes:
Internal network testing may be included depending on your architecture and the controls you’re asserting.
Frequency
Auditors expect testing to occur during the audit period. For a 12-month Type II audit:
Annual testing completed before your audit period begins won’t satisfy Type II operating effectiveness requirements — the test needs to fall within the period under audit. For a deeper look at why annual-only testing programs leave security gaps beyond compliance minimums, see Why Annual Penetration Tests Are Not Enough.
Findings Management
The penetration test itself isn’t enough. Auditors want to see a complete cycle. Understanding what those findings typically look like helps you prioritize remediation — see Top 5 Vulnerabilities We Find in Every Penetration Test for a practitioner’s view of the most common issues that surface across environments.
1. Testing conducted — with documentation of scope, methodology, and findings
2. Findings reviewed — risk-rated and prioritized
3. Remediation tracked — a formal process for closing findings, with evidence
4. Critical/high findings closed — before audit conclusion, or with documented exception rationale
This is where many organizations fall short. The testing gets done, the report is received, and then findings languish in a backlog. Auditors reviewing your CC4 and CC7 controls want to see that findings were acted on — not just identified.
Documentation You’ll Need
How to Prepare for SOC 2 with Penetration Testing
1. Define Your SOC 2 Scope First
Before scoping a penetration test, get clear on what systems, services, and environments are in your SOC 2 scope. Working with your auditor or a compliance advisor to define scope boundaries before engaging a penetration testing firm will save you significant time and avoid gaps.
2. Prepare Your Team Before the Engagement Starts
Getting the most out of a penetration test requires preparation on your side — scope documentation, stakeholder alignment, and defined escalation procedures. See How to Prepare Your Team for a Penetration Test for a full pre-engagement checklist.
3. Engage a Penetration Testing Firm Before the Audit Window Closes
If you’re working toward a first Type II audit, allow enough time to:
Compressed timelines are the most common reason organizations fail to close findings before their audit. Schedule your test early in the audit period, not at the end.
4. Ask for SOC 2-Aligned Deliverables
Not all penetration testing firms produce reports that satisfy auditors. When evaluating providers, ask specifically:
A good penetration testing firm with SOC 2 experience knows how to structure deliverables in a way that supports the audit process — not just internal remediation.
5. Build a Formal Vulnerability Management Process
The penetration test is a point-in-time assessment. CC7 requires ongoing monitoring and response, not just an annual exercise. Before your audit, make sure you have:
Auditors review the process, not just the results.
6. Prepare for Auditor Questions
Your auditor will likely ask questions such as:
Prepare clear, documented answers. Auditors respond well to organizations that have a mature, documented approach — even if no program is perfect.
Type I vs. Type II: A Comparison for Penetration Testing
| Factor | SOC 2 Type I | SOC 2 Type II |
|---|---|---|
| Audit scope | Design effectiveness at a point in time | Operating effectiveness over 6–12 months |
| Pentest requirement | Uncommon but sometimes expected | Expected by most auditors for Security category |
| Timing | Complete before report date | Must fall within audit period |
| Findings management | Less rigorous | Full remediation tracking expected |
| Customer acceptance | Basic vendor qualification | Enterprise procurement standard |
What to Look for in a SOC 2 Penetration Testing Provider
Choosing a penetration testing firm for SOC 2 purposes is different from choosing one for a general security exercise. For a detailed evaluation framework — including eight specific questions to ask any firm and what good vs. bad answers look like — see our guide on how to choose a penetration testing company. For SOC 2 specifically, you need a firm that:
Understands how their deliverables map to the audit process. A penetration testing report is evidence in an audit. The firm should know how their findings documentation will be reviewed and should produce output that satisfies that process.
Provides remediation guidance, not just findings lists. Auditors want to see that you acted on findings — which means you need actionable guidance from your tester, not a raw CVE list.
Has relevant certifications. OSCP, CREST, GPEN, and similar hands-on technical certifications demonstrate that your testers are conducting real testing, not automated scanning with a manual summary.
Can support re-testing. For critical and high findings, auditors want evidence that vulnerabilities were fixed. A firm that includes re-testing confirms that your fixes were effective — and gives you documentation to show your auditor.
Is available post-delivery. Remediation often surfaces questions. Your development or infrastructure team will have questions as they work through findings. The firm should be reachable.
### Get a SOC 2 Readiness Assessment
>
Not sure whether your organization is ready for a SOC 2 Type II audit? StrikeHaven’s team works with SaaS companies, fintech platforms, and cloud service providers to assess security posture, identify control gaps, and conduct penetration testing aligned with Trust Services Criteria requirements.
>
>
We’ll give you an honest assessment of where you stand — and what needs to happen before your audit window opens.
>
For a comprehensive guide covering SOC 2, HIPAA, PCI DSS, and CMMC penetration testing requirements in one place, download the 2026 Penetration Testing Buyer Guide.
SOC 2 Penetration Testing Preparation Checklist
Use this before your audit period:
Scope & Planning
Testing & Deliverables
Findings Management
Audit Readiness
Frequently Asked Questions
Is penetration testing explicitly required for SOC 2?
Not by name — but the Trust Services Criteria around monitoring, vulnerability management, and control effectiveness create a strong practical expectation. For SOC 2 Type II, auditors routinely ask for evidence of security testing over the audit period, and penetration testing is the most common and defensible way to provide it.
Can I use a vulnerability scan instead of a penetration test for SOC 2?
A vulnerability scan satisfies the monitoring aspects of CC7.1, but it doesn’t validate whether vulnerabilities are actually exploitable or whether your detective and response controls work as designed. Auditors and customers increasingly distinguish between scanning and testing. For Type II, penetration testing is the stronger evidence.
How often should I conduct a penetration test for SOC 2?
Annual testing is the standard minimum, conducted within each audit period. Organizations that go through significant changes — new infrastructure, new features handling customer data, major cloud migrations — should test after those changes, not just on an annual calendar.
My SOC 2 auditor didn’t specifically ask for a penetration test. Do I still need one?
Your current auditor may not have flagged it, but your customers and prospects may. Enterprise vendor security questionnaires and procurement processes routinely ask about penetration testing frequency and results. Building a penetration testing program now positions you well for those conversations — and protects against an auditor in a future period asking why there’s no history of security testing.
Does my penetration testing firm need to be pre-approved by my SOC 2 auditor?
Generally, no. Your auditor reviews the output of the testing, not the firm itself. That said, you should use a firm with credible certifications and a methodology that produces documentation your auditor can review. Letting your auditor know who conducted testing — and sharing their qualifications if asked — is standard practice.
For more on compliance-driven penetration testing, see our guide on CMMC penetration testing requirements — if you serve defense clients in addition to commercial customers, the two programs have meaningful overlap.
Authoritative SOC 2 resources: AICPA Trust Services Criteria and the AICPA’s SOC 2 Guide.