Does SOC 2 Require a Penetration Test? (2026 Guide)
The security questionnaire always shows up at the worst possible moment. You're days from closing your first real enterprise contract, everyone's excited, and then procurement forwards a spreadsheet with 200 rows. Somewhere around row 40 you find it: "Provide your most recent SOC 2 report and penetration test results."
And you don't have either.
So you start Googling at 11pm, and you land on the question I've heard from dozens of founders over the years: does SOC 2 actually require a penetration test, or is it just something everyone assumes you need?
The technically-correct answer is no. The practically-correct answer is yes. Let me explain the gap, because understanding it will save you money and stop you from buying the wrong thing.
The requirement nobody actually reads
SOC 2 isn't a checklist. It's built on the AICPA's Trust Services Criteria, which are written as principles rather than prescriptions. If you go looking for a line that says "you must run a penetration test," you won't find one. It doesn't exist.
What the criteria do ask — under sections like CC4.1 and CC7.1 — is that you monitor your environment for vulnerabilities, evaluate your controls on some regular basis, and actually do something when you find a weakness. In other words, prove your locks work. A penetration test happens to be the most convincing way to prove it, which is exactly why it's become the default.
So the honest framing isn't "required vs. not required." It's "required by the letter of the standard" (no) versus "required by every auditor and customer you'll ever deal with" (yes). Guess which one determines whether you close the deal.
Do you need a pentest for SOC 2?
|
+---------+----------+
v v
Does the standard Does your auditor
literally require + enterprise buyer
one? expect one?
| |
NO YES
| |
+---------+----------+
v
You're getting a pentest.
(Effectively required, every time.)
Why everyone thinks it's mandatory
The myth is understandable. Three things happen at roughly the same time and blur together in a founder's head.
Your auditor asks for pentest results, because it's the cleanest piece of evidence they can drop into the vulnerability-management section of their report. Your enterprise customer asks for pentest results, completely separately, as part of their vendor review. And both requests tend to arrive in the same week, wrapped in the same compliance language. From where you're sitting, it all looks like one big SOC 2 requirement — even though the pentest demand is really coming from three directions at once.
If you're going for Type II, plan on it
Quick distinction that trips people up. A Type I report says your controls are designed correctly at a single point in time. A Type II report says they actually worked over a period — usually three months to a year. Type II is the one enterprise buyers care about, and it's the one where a penetration test within your audit window stops being optional in practice.
If you're only doing Type I to check a box, you might get away with lighter testing. If you're doing Type II because you're selling upmarket, budget for a real pentest inside the observation period and an annual cadence after that.
What auditors are really looking for
Here's where founders waste money: they think the goal is to hand over a document with the word "penetration test" on the cover. It isn't. Auditors have seen enough of those to know most of them are automated scans in a nice PDF.
What they actually want to see is a test done by an independent third party — not your own developers running a tool they found last week. They want a scope that makes sense: your production app, your APIs, the infrastructure that matters. They want a recognized methodology behind it (OWASP, PTES, NIST — pick one and stick to it). And more than anything, they want to see that you closed the loop.
That last part is the one people miss. A report listing twelve critical vulnerabilities that are all still open is worse than useless — it's a signed confession. What earns trust is the follow-through: findings triaged, criticals fixed, and a retest confirming they're actually gone. Auditors care less about the fact that you had bugs and more about whether you dealt with them like grown-ups.
+----------------+
| 1. TEST | Expert simulates real attacks
+--------+-------+
v
+----------------+
| 2. TRIAGE | Rank findings by severity
+--------+-------+
v
+----------------+
| 3. FIX | Remediate criticals + highs first
+--------+-------+
v
+----------------+
| 4. RETEST | Verify the fixes actually worked
+--------+-------+
v
[ Clean report ] -> hand to the auditor
This is the "closed loop" auditors want to see — not a one-off scan, but evidence that a finding went all the way from discovered to fixed to verified fixed.
Don't buy a scan and call it a pentest
This is the most expensive mistake I see, and it's expensive precisely because it feels cheap.
An automated scanner crawls your app looking for known issues. It's fast, it's inexpensive, and it has its place — but it produces a mountain of false positives and, critically, it cannot understand your business logic. It doesn't know that a regular user shouldn't be able to hit /api/admin/refunds, or that changing an order ID in a request lets you read someone else's invoice. Those are the bugs that get companies breached, and they're the bugs a scanner walks right past.
A real penetration test is a person thinking like an attacker: chaining small issues into a real exploit, bypassing authentication, escalating privileges, abusing the logic you assumed was safe. For SOC 2 evidence — and, more importantly, for actually keeping your customers' data safe — that human judgment is the whole point.
What it costs, roughly
Price tracks scope and depth more than anything else. A pure automated scan is cheap but rarely stands on its own for SOC 2. An expert-led manual test on a typical SaaS app is the usual first-audit choice. And increasingly, teams are moving to PTaaS — penetration testing as a service — where you get continuous scanning plus periodic manual testing on a monthly model, with retesting bundled in. The appeal for SaaS teams is obvious: instead of one nervous snapshot a year, you have evidence year-round and you're not scrambling before every audit.
If you want the regional numbers broken down properly, we did that in a separate pricing guide. The one rule that saves the most money: nail down your scope before you ask for quotes. Vague scope is what vendors pad.
A timeline that actually works
8-12 wks out During test After report Pre-audit Ongoing
=====================================================================>
Scope & Stay in the Fix criticals Retest -> Annual /
book the loop (no & highs first clean report continuous
pentest 3-wk silence) in hand cadence
Start scoping the test eight to twelve weeks before your audit window closes — not the week before, when you'll pay a rush premium and have no time to fix anything. Stay in the loop while testing happens; a good team talks to you as they go rather than vanishing for three weeks and mailing back a PDF. When the findings land, fix the criticals and highs first, then get them retested so you have a clean report to hand the auditor. After that, settle into an annual rhythm at minimum. SOC 2 Type II is not something you do once and forget.
Frequently asked questions
Does SOC 2 legally require a penetration test? No. SOC 2 rests on the AICPA Trust Services Criteria, which call for vulnerability management and periodic evaluation of your controls — not a specific pentest. In practice, though, auditors expect one and enterprise customers demand it, so it's effectively required even if the standard never says the word.
How often do I need one? Annually is the accepted baseline. For Type II, you'll want a test inside your audit period. Continuous testing through PTaaS goes beyond the requirement and gives you evidence all year.
Can an automated scan replace a real pentest? Not for SOC 2, and not for your own safety. Scans miss business-logic flaws entirely, and auditors increasingly recognize a scan-in-a-PDF for what it is. Expert manual testing is what's expected, ideally with continuous scanning alongside it.
Do I have to fix everything before the audit? You need to remediate the serious findings — criticals and highs — and show evidence they were retested. Lower-severity issues can sometimes be documented as accepted risk with a reasonable justification. What matters is that you closed the loop on the dangerous stuff.
What should the test cover? Usually your production web app, your APIs, and whatever infrastructure falls inside your SOC 2 scope. Define this clearly up front — it prevents both security blind spots and inflated quotes.
The takeaway
SOC 2 never actually says "get a penetration test." But between your auditor and the enterprise customer holding your contract, you're going to need one anyway — and treating it as real security work rather than a compliance chore is what separates the founders who breeze through vendor review from the ones stuck answering follow-up questions for a month.
At ZeroSight360 we run expert manual pentests aligned to OWASP and PTES, retesting always included, with reports built for exactly this situation — whether that's a one-time test for your first audit or continuous PTaaS coverage for Type II. We'll scope it to where you are, not where a big four consultancy wishes you were.
Prepping for SOC 2? Grab a free 15-minute scoping call and we'll help you figure out the right scope for your audit — no obligation, no pressure.
Did you find this helpful?
0xCobra
Security Researcher at ZeroSight360