SOC 2 Penetration Testing: What Auditors Actually Expect
- July 15, 2026
SOC 2 Type II is an annual exercise for most organizations. Most wait too long to schedule testing, get vague guidance from their auditor, and end up with a pentest report that technically exists but barely satisfies the controls it was supposed to evidence.
This post cuts through that ambiguity: what auditors actually expect, how to scope and time the engagement, and what the report needs to include to hold up under scrutiny.
What SOC 2 Actually Requires for Penetration Testing
SOC 2 does not mandate penetration testing by name — that’s the source of most of the confusion. What it requires, under CC6.1, CC6.6, CC6.8, and CC7.1, is evidence that your organization identifies, monitors, and responds to vulnerabilities and security events affecting in-scope systems.
In practice, most auditors interpret that as penetration testing, because a vulnerability scan alone doesn’t demonstrate that someone actually attempted to exploit what was found.
What auditors want to see: scope, methodology, findings, and evidence of remediation. What they don’t care about: finding count, which scanning tool you used, or how long the report is.
What SOC 2 Trust Services Criteria Require for Security Testing
| Criteria | What It Covers | Testing Implication |
|---|---|---|
| CC6.1 | Logical and physical access controls | Verify access controls are tested, not just documented |
| CC6.6 | Malicious software prevention | Evidence of threat detection and response testing |
| CC6.8 | Controls prevent unauthorized access | Demonstrate attempted exploitation, not just scanning |
| CC7.1 | Vulnerability and threat detection | Ongoing identification and response to vulnerabilities |
Scoping Your Pentest for SOC 2 Evidence
The most common scoping mistake is treating the pentest as a separate exercise from the SOC 2 boundary. Your test should cover the systems your auditor is already looking at: externally facing applications, APIs, network perimeter, and any systems explicitly included in your Trust Services Criteria scope.
Common gaps that create audit problems:
- Testing only one application when multiple systems are in SOC 2 scope
- Skipping the API layer — auditors increasingly ask about this directly
- Ignoring cloud misconfiguration, even when cloud infrastructure is explicitly in scope
- Excluding phishing or social engineering when your criteria covers availability or confidentiality controls for human access
Ask your auditor directly what they’ll want to see covered before you scope the engagement. That conversation takes fifteen minutes and can save you a challenged finding three weeks before your audit window closes.
SOC 2 Penetration Testing Timeline: When to Schedule
| Timing Before Audit | Feasibility | Notes |
|---|---|---|
| 60–90 days | Ideal | Time to remediate, retest, and produce audit-ready evidence |
| 30 days | Minimum viable | Requires fast turnaround and a clean environment — critical findings must be addressable |
| Under 4 weeks | Difficult | Have a conversation about what’s achievable before scoping |
| The week before | Won’t work | Remediation evidence gaps and retest timing will leave you with a report that documents findings rather than demonstrating they were addressed |
If you’re reading this with six weeks to your audit, you’re in tight-but-workable territory. Fewer than four weeks means a scoping conversation, not a scoping document.
What Your Pentest Report Needs to Include for SOC 2
The report format matters for SOC 2 evidence in ways it doesn’t for internal-only testing.
At minimum, auditors expect:
- Executive summary with scope clearly stated
- Methodology section — many auditors require this explicitly; it establishes that the test was structured and repeatable, not ad hoc
- SOC 2 Trust Services Criteria mapping — built into the findings, not added as an appendix after the fact
- Remediation status — ideally including retest evidence, or a remediation tracking log if retesting isn’t complete before the audit
If you receive a report missing these elements, ask your vendor to add them before you submit it. Most can. The ones that won’t are telling you something about how they treat the compliance use case.
Penetration Test vs. Vulnerability Scan: What’s the Difference for SOC 2?
Vulnerability scan: Identifies known weaknesses by comparing systems against a database of known CVEs. Automated, fast, produces a list. Does not demonstrate that someone attempted to exploit what was found.
Penetration test: A human analyst attempts to exploit what the scan or their own reconnaissance finds. The report demonstrates that someone actually tried, not just looked.
Some auditors accept scan-only evidence at smaller organizations with limited scope. Most will push back. If you’re submitting scan results as your primary security testing evidence and your auditor hasn’t explicitly confirmed that’s sufficient, confirm before your window opens.
Frequently Asked Questions
Does SOC 2 require penetration testing? SOC 2 doesn’t mandate penetration testing by name. Under CC6.1, CC6.6, CC6.8, and CC7.1, it requires evidence of vulnerability identification, monitoring, and response. Most auditors interpret this as requiring penetration testing because a vulnerability scan alone doesn’t demonstrate that exploitation was attempted.
What SOC 2 controls does penetration testing support? Penetration testing primarily supports CC6.1 (logical access controls), CC6.6 (malicious software and threat prevention), CC6.8 (unauthorized access controls), and CC7.1 (vulnerability and threat detection).
How often should we perform penetration testing for SOC 2? Most SOC 2 Type II auditors expect penetration testing at least annually. Some organizations perform additional testing after significant infrastructure changes, major releases, or cloud migrations to maintain continuous evidence.
What should a SOC 2 pentest report include? At minimum: a clearly scoped executive summary, a methodology section, findings mapped to SOC 2 Trust Services Criteria, and remediation status including retest evidence where available.
Can we use a vulnerability scan instead of a penetration test for SOC 2? Some auditors will accept scan-only evidence in limited circumstances, typically at small organizations with narrow scope. Most will push back. Confirm with your auditor before your window opens rather than after you’ve submitted the evidence.
How long before our SOC 2 audit should we schedule penetration testing? Schedule 60–90 days before your audit window opens. This gives time to remediate, retest, and produce evidence in a format your auditor can use. 30 days is the practical minimum. Less than four weeks makes full remediation evidence extremely difficult.
What systems should be in scope for a SOC 2 penetration test? Everything your auditor is already looking at: externally facing applications, APIs, network perimeter, and any systems included in your Trust Services Criteria scope. Common gaps include secondary applications, API layers, cloud infrastructure, and human access controls.
What’s the difference between a SOC 2 penetration test and a regular penetration test? The core testing is similar. The difference is in reporting: a SOC 2 pentest report needs to explicitly map findings to Trust Services Criteria, include a formal methodology section, and document remediation status in a format that serves as audit evidence.
How Canary Trap Supports SOC 2 Penetration Testing
Canary Trap delivers SOC 2-aligned offensive security testing with reporting structured for audit evidence, not just internal use. Engagements include scope documentation, methodology statements, Trust Services Criteria mapping, and remediation tracking support.
Services relevant to SOC 2 requirements include:
- External Vulnerability Assessment & Penetration Testing (CC6.1, CC6.6, CC6.8)
- Web Application Penetration Testing (CC6.1, CC6.8)
- API Penetration Testing (CC6.1, CC6.8)
- Internal Network Penetration Testing (CC6.6, CC7.1)
- Social Engineering Vulnerability Assessment (CC6.1, CC6.6)
- Cloud Configuration Review (CC6.1, CC7.1)
Preparing for a SOC 2 audit? Schedule a scoping conversation with Canary Trap to confirm timeline, scope, and report format before your window opens.
