A SOC 2 penetration test scoped only to satisfy the auditor is the cheapest way to get a clean report and the most expensive way to stay insecure. The compliance question and the security question are different questions, and answering only the first one buys a PDF, not protection. If you lead security at a SaaS company heading into your first audit, that distinction decides whether your SOC 2 penetration testing spend produces evidence and protection, or just evidence.
This guide answers what a founder or security lead actually Googles before booking a test. Does SOC 2 require one? What goes in scope? What do auditors want to see? And what should you budget in 2026?
Does SOC 2 require a penetration test?
Technically, no. The AICPA Trust Services Criteria, the actual standard a SOC 2 report is measured against, never use the words "penetration test" as a hard requirement. SOC 2 is a controls audit, and the criteria describe outcomes, not specific tools.
In practice, you should plan on one anyway. Criterion CC4.1 (monitoring activities) lists penetration testing by name as an example of the "ongoing and separate evaluations" an organization uses to confirm its controls are working, alongside ISO certifications and internal audit. That explicit naming is why auditors treat a pentest as expected evidence rather than a nice-to-have.
The pentest also feeds the CC7.x criteria on detecting and responding to security events. A vulnerability scan satisfies part of that monitoring expectation, but it finds known CVEs in known software. A penetration test finds the things scanners miss: broken access control, authentication bypass, business logic flaws, and privilege escalation chains. Auditors increasingly want both, and an honest scan-plus-pentest pairing reads as a mature program.
So the accurate framing is this. SOC 2 does not mandate a penetration test, and an auditor expects one regardless. Going in without one means writing a justification memo your auditor will probably reject for any system that handles customer data.
Type I versus Type II changes the timing
The two SOC 2 report types put different demands on your test.
- Type I assesses whether your controls are designed correctly at a single point in time. A recent pentest demonstrates the monitoring control exists.
- Type II assesses whether those controls operated effectively across an observation window, usually 3 to 12 months. Here the test has to fall inside the window to count as evidence for that period.
That second point trips up first-time teams. If your Type II window runs January through June and your pentest happened the previous November, it sits outside the period and may not satisfy the auditor for that report. Schedule the test early enough inside the window that you can remediate the findings and, ideally, retest before the window closes. Most teams run their annual pentest once per audit cycle and place it deliberately rather than whenever a calendar slot opens up.
Compliance scope and security scope are not the same
Here is where the cheap report gets expensive. A pentest can be scoped to the narrowest surface that satisfies CC4.1, typically the primary production web application and its main API. That is a legitimate, budget-real choice, and for a lean SaaS startup with one product it is often a reasonable starting point. The auditor signs off, and the report is clean.
The trap is mistaking that boundary for your actual attack surface. Attackers do not respect audit scope. They probe the staging environment you forgot was internet-facing, the admin subdomain, the CI/CD pipeline, the third-party integration with an over-permissioned token, and the cloud misconfiguration that never appears in the application itself. Scope the test to pass the audit and you have measured the one room you already lock while leaving the doors open everywhere else.
The 2023 CircleCI breach is the cautionary case. Attackers compromised the build platform and exfiltrated customer environment variables, tokens, and keys, none of which live inside the production application an audit-scoped pentest would target.
The fix is to scope for security first, then map that work onto the SOC 2 evidence you need. Inventory what actually faces the internet and what would hurt most if compromised, test that, and let the resulting report cover CC4.1. The audit-driven test still has a place as a floor for cost-constrained teams, but treat it as the minimum you can defend, not the target. Cloud posture problems in particular sit outside most application pentests, which is why teams pair the test with CSPM tooling to catch the misconfigurations a pentest scoped to the app will skip.
What auditors actually want in the report
A SOC 2 auditor is not going to re-run your exploits. They read the report as evidence that a credible, independent evaluation happened and that you acted on it. A report that satisfies them includes:
- Defined scope and dates. The systems tested and the test window, with dates that line up with your audit period.
- A recognized methodology. A reference to a standard like the OWASP Web Security Testing Guide or NIST SP 800-115 signals the work was structured, not ad hoc.
- Findings with severity ratings. Each issue rated by impact and likelihood, usually on a CVSS-style scale.
- Tester independence and qualifications. Evidence the testers were independent of the engineering team, with relevant credentials.
- Remediation status and retest evidence. This is the part that carries the most weight. Auditors want to see that findings were fixed and, ideally, that a retest confirmed the fix.
That last item is where many programs lose points. A pentest report listing ten unremediated highs from eight months ago is worse than no report, because it documents that you knew and did nothing. The remediation and retest trail is the evidence auditors weight most, so budget for the fix cycle, not just the test.
What SOC 2 penetration testing actually costs in 2026
Cost is the figure most often stated as fact and least often sourced, so treat any single number with suspicion. The honest answer is a range that depends on scope, depth, retesting, and who does the work.
Published 2026 pricing from named providers gives a usable band. DeepStrike lists a SOC 2 penetration test at roughly $5,000 to $20,000, with skilled-tester hourly rates of $100 to $300. SecurityWall puts a standard SOC 2 scoped test for a SaaS or cloud-native application at $8,000 to $25,000, mapping to roughly 40 to 80 hours of active testing. The overlap, very roughly $8,000 to $25,000 for a typical first-time SaaS scope as of mid-2026, is the band most providers report.
Four things move you within or past that range:
- Scope size. One web app and one API sits at the low end. Multiple products, mobile apps, or internal networks push it up.
- Depth. A largely automated scan with light manual review is cheaper and weaker than manual, exploit-driven testing by senior testers.
- Retesting. Confirm whether a remediation retest is included or billed separately. It is the part auditors want, so do not cut it.
- Provider tier. Boutique security firms typically price in the bands above. Big 4 firms generally charge a multiple of boutique rates.
Avoid the cheapest "compliance pentest" packages that are a rebadged automated scan with a logo on the cover. They produce a document, but a scanner you already run produces the same findings, and the report adds little an auditor cannot see through.
The default recommendation
For most SaaS companies approaching a first SOC 2, the practical play is straightforward. Hire an independent boutique firm for a manual, scope-honest test of your production application, API, and the cloud and pipeline surfaces that actually face the internet, and budget in the roughly $8,000 to $25,000 band for a single-product scope. Place it inside your Type II window with enough runway to remediate and retest before the window closes. Insist that a retest of high and critical findings is in the contract.
Skip the bargain automated-only "SOC 2 pentest," skip scoping the test down to a single app purely to lower the invoice, and skip Big 4 pricing unless an enterprise customer specifically demands that name on the report. Spend the difference on fixing what the test finds. If you carry a lot of third-party components, pair the pentest with a clean software inventory using one of the best SBOM tools for 2026, since dependency risk rarely shows up in a time-boxed application test.
Beyond the once-a-year snapshot
A SOC 2 penetration test is a point-in-time photograph. It proves your controls held on the days the testers were looking, which is exactly what the audit asks for and exactly the wrong assumption to carry for the other 51 weeks. Your code ships continuously, your cloud config drifts, and new dependencies land every sprint. The clean report ages the moment the testers log off.
That gap between annual proof and continuous change is the case for continuous penetration testing, and it is also where ranking findings by real exploitability matters more than counting them, which is the heart of risk-based vulnerability management. The audit pentest tells you that you were secure in March. The harder question is whether you still are in September.
This is exactly what Vortex is built to do between audits: test the application and pipeline, validate which findings are genuinely exploitable, fix them, retest to prove the fix held, and keep the evidence current. The annual pentest gives the auditor a snapshot for CC4.1. Continuous validation keeps producing the remediation-and-retest trail those criteria reward, between audits rather than once a year. If you want to see what that looks like against your own SOC 2 scope, Get a Demo.
Detect. Defend. Deter. A SOC 2 report proves you did it once. The work is doing it on a schedule, with the receipts to show for it.