SOC 2 Penetration Testing Requirements: What Auditors Actually Expect
Whether a pentest is required, which Trust Services Criteria it supports, what your report must contain, and when to run it.
Is a penetration test required for SOC 2?
Strictly, no — the AICPA standard never names penetration testing as a mandatory control. In practice, yes — auditors in 2026 expect a recent third-party pentest, and the Trust Services Criteria around monitoring and vulnerability detection are very hard to evidence without one.
SOC 2 is built on the AICPA's Trust Services Criteria, not a rigid checklist of tools. That's why you won't find a line that says "you must run a penetration test." What you will find is a set of criteria that ask you to prove your security controls are present, operating, and catching new vulnerabilities over time. A penetration test is the cleanest, most widely accepted way to produce that proof.
So the honest framing isn't "is it required" — it's "can you pass a modern SOC 2 audit, particularly Type II, without one?" For most companies selling into enterprise, the answer is no. Your auditor expects it, and so does the enterprise customer whose security questionnaire started this whole process.
What changes between Type I and Type II.
The two SOC 2 report types ask different questions, and a penetration test plays a different role in each. Knowing which you're pursuing tells you when to test and how much evidence you need to keep.
| Dimension | SOC 2 Type I | SOC 2 Type II |
|---|---|---|
| What it evaluates | Control design at a single point in time | Operating effectiveness over a 6–12 month period |
| Role of the pentest | Shows controls are designed to detect and prevent vulnerabilities | Proves controls actually worked under adversarial conditions during the window |
| When to test | A recent test ahead of the report date is usually enough | Early in the observation window, with time to remediate and retest |
| Evidence to keep | The report itself | Report + remediation records + retest evidence for HIGH/CRITICAL |
Most enterprise buyers ultimately want a Type II report — it's the one that demonstrates your controls hold up over time, not just on paper. Type I is often a faster first step that gets a deal unblocked while the Type II observation window runs. For Type II, the timing of your pentest is the single biggest factor in whether the evidence lands clean.
Which criteria a pentest supports.
A penetration test maps most directly to the Common Criteria around monitoring and vulnerability management. These are the controls auditors most often want pentest evidence for.
| Criterion | What it covers | How a pentest helps |
|---|---|---|
| CC4.1 | Monitoring of controls | The points of focus explicitly cite penetration testing as a way to evaluate whether controls are present and operating. A pentest is direct evidence of an ongoing, separate evaluation. |
| CC7.1 | Detection of new vulnerabilities | Requires procedures to identify configuration changes that introduce vulnerabilities and susceptibility to newly discovered ones. A periodic pentest demonstrates you actively look for both. |
| CC7.2 | Monitoring for anomalies | Adversarial testing exercises your detection and logging — a pentest that should have tripped an alert but didn't is a finding your auditor will want addressed. |
| CC3.2 | Risk identification | Findings feed your risk assessment. A pentest gives you a real, prioritized view of technical risk rather than a theoretical one. |
CC4.1's points of focus reference penetration testing directly; CC7.1 requires you to detect newly introduced and newly discovered vulnerabilities. Together they make a pentest the path of least resistance to clean evidence.
Scope the pentest to your system description.
The single rule that prevents most SOC 2 pentest problems: if a system is in scope for the audit, it's in scope for the pentest. Your test boundary should mirror your SOC 2 system description — not a convenient subset of it.
The most common — and most expensive — mistake is scoping the pentest to external infrastructure only, when the system description also covers internal systems and a web application. The auditor notices the gap, and now you're commissioning a second test on a deadline. A complete SOC 2 pentest typically covers:
- External (internet-facing) network and infrastructure
- Internal network, where the system description includes it
- Web applications and the APIs behind them
- Cloud configuration and identity (AWS, GCP, Azure)
What auditors want to see.
A finding is only useful if your auditor can act on it. These are the report elements that turn a pentest into clean audit evidence.
- 01Scope statement mapped to your SOC 2 system description
- 02A recognized methodology (PTES, OWASP, NIST SP 800-115)
- 03Risk-rated findings with CVSS scores
- 04Clear, actionable remediation guidance per finding
- 05Retest evidence for HIGH and CRITICAL findings
- 06A statement of limitations and tester attestation
Run it early in the observation window.
For a Type II audit, timing is everything. Test early, remediate, and retest — so by the time fieldwork starts, your evidence is complete. Here's the rhythm that works:
The anti-pattern is testing the week before fieldwork. If the test surfaces a critical issue, you have no time to remediate and retest — and an unresolved critical with no retest evidence becomes a gap in your control environment.
How often?
At least annually, and after any significant change to your environment — new infrastructure, a major release, or a material architecture change. For Type II, align the test to your observation window so the evidence is current when the auditor reviews it.
How much?
For a credible third-party firm, a SOC 2 penetration test typically runs $5,000–$25,000, driven by scope: number of applications and APIs, cloud footprint, and whether internal testing is included. Our SOC 2 engagements start at $15,000.
Common reasons SOC 2 pentests fail the audit.
A pentest can technically happen and still leave a gap in your control environment. These are the failures we see most often — each one avoidable.
The number-one failure: testing only external infrastructure when the SOC 2 system description also includes an internal app. The auditor flags the gap and you commission a second test on a deadline.
A test run the week before fieldwork leaves no time to remediate and retest. Any critical it surfaces becomes an open gap with no evidence of closure.
Findings marked 'fixed' but never re-verified. Auditors want documented proof the vulnerability is actually closed — a claim isn't evidence.
Automated-only output with no manual validation, no exploited findings, and no CVSS-rated risk. It reads as noise, not a penetration test, and auditors increasingly know the difference.
A pentest older than twelve months, or one performed before a major architecture change, no longer reflects the system under audit.
No recognized methodology, no statement of limitations, no tester credentials. Without these, the auditor can't rely on the report as evidence.
SOC 2 pentest questions.
01Is a penetration test required for SOC 2?+
Not by the letter of the AICPA standard — SOC 2 never names 'penetration testing' as a mandatory line item. In practice, though, auditors in 2026 expect to see a recent third-party pentest, especially for Type II. The Trust Services Criteria around monitoring (CC4.1) and vulnerability detection (CC7.1) are very hard to evidence convincingly without one.
02What's the difference for Type I vs Type II?+
Type I assesses control design at a point in time; a recent pentest helps show the design is sound. Type II assesses operating effectiveness over a 6–12 month window, so a pentest performed within that window — with remediation and retest evidence — is the strongest proof your controls work under real adversarial conditions.
03What should the pentest scope cover?+
It must align with your SOC 2 system description. If a system is in scope for the audit, it should be in scope for the pentest — external and internal networks, web applications, APIs, and cloud environments. The most common scoping failure is testing only external infrastructure while the system description includes an internal app.
04How often do we need to pentest for SOC 2?+
At least annually, and after any significant change to your environment. For Type II, align the test to your observation window so the evidence is current when the auditor reviews it.
05How much does a SOC 2 penetration test cost?+
For a credible third-party firm, typically $5,000–$25,000 depending on scope and complexity — number of applications and APIs, cloud footprint, and whether internal testing is included. Watch Owl Labs SOC 2 engagements start at $15,000.
06What happens if the pentest finds critical issues right before the audit?+
Unremediated critical and high findings with no retest evidence become gaps in your control environment, and multiple unresolved criticals can lead to a qualified opinion. That's exactly why you run the test early in the observation window — not the week before fieldwork.
Need a SOC 2 pentest your auditor will accept?
Watch Owl Labs runs SOC 2 penetration tests mapped to the Trust Services Criteria, timed to your observation window, with retest evidence for every HIGH and CRITICAL finding. Book a scoping call and we'll align the test to your system description.