Does SOC 2 Require a Penetration Test? (2026 Auditor Guide)
Short answer: SOC 2 does not literally require a penetration test. No clause in the AICPA Trust Services Criteria says "you must run a pentest." But the Security criteria do require you to monitor for vulnerabilities and prove your controls detect and respond to threats. A pentest is the standard, audit-accepted way to produce that evidence, so most companies that pass SOC 2 run one anyway.
That nuance is exactly where founders and security leads get stuck. SOC 2 is criteria-based, not prescriptive. It tells you what outcomes your controls must achieve, not which specific tests to run. Yet your auditor will ask how you find and treat security weaknesses, and a vulnerability scan rarely settles that question on its own. Below is what SOC 2 actually demands, why auditors expect a pentest anyway, and what a SOC 2-aligned test has to include to count as evidence.
What SOC 2 Actually Says About Testing
SOC 2 is an attestation built on the AICPA Trust Services Criteria (TSC). Every SOC 2 report covers the Security category, also called the common criteria, and optionally adds Availability, Confidentiality, Processing Integrity, or Privacy. The pentest expectation lives inside the common criteria, even though the word "penetration test" never appears.
CC4.1, monitoring of controls
This criterion requires you to select, develop, and perform ongoing evaluations to confirm your controls are present and operating. In plain terms: you have to actively check that your security works, not assume it does. A penetration test is one of the most direct ways to evaluate whether your technical controls hold up, because it tests them the way a real attacker would.
The CC7 series, detection and response
CC7.1 expects you to use detection mechanisms to spot new vulnerabilities. CC7.2 and CC7.3 expect you to detect, evaluate, and respond to security events and incidents. A pentest produces direct evidence here: it surfaces real, exploitable weaknesses, shows whether your monitoring noticed the activity, and gives you findings to remediate and retest.
CC3.2 and CC6, risk and access
Your risk assessment has to identify and analyze risks to your objectives, and your logical access controls have to actually protect your systems. A pentest validates both. It shows whether the access controls you documented stop an attacker, or whether they have gaps you did not know about.
So SOC 2 never says "pentest." It says "monitor your controls, find your vulnerabilities, and prove you can detect and respond." A penetration test is how serious organizations answer all three.
Type 1 versus Type 2: Does the Answer Change?
A common question is whether a SOC 2 Type 2 report raises the bar. It does, in a way that makes a pentest even more useful.
A Type 1 report tests whether your controls are designed appropriately at a single point in time. A Type 2 report tests whether those controls operated effectively across a period, usually three to twelve months. Type 2 is what most enterprise customers ask for, because it proves your security worked over time, not just on the day of the audit.
For Type 2, your auditor wants evidence that your monitoring and vulnerability management ran throughout the review period. A pentest fits cleanly into that story: it is a scheduled, documented evaluation of your controls, with findings, remediation, and ideally a retest that proves you closed the gaps. That trail of "we tested, we found, we fixed, we verified" is exactly the operating-effectiveness evidence a Type 2 examiner looks for. So while SOC 2 Type 2 does not require a pentest by name either, the period-of-time requirement makes a documented, repeatable test the path of least audit friction.
Why Auditors Expect a Pentest Even Though the Criteria Do Not Name It
Auditors are not ticking a box labeled "pentest completed." They are deciding whether your evidence convincingly shows that CC4.1 monitoring and the CC7 detection criteria are operating.
Here is the practical problem. If you tell an auditor you monitor for vulnerabilities, they will ask to see how. A vulnerability scan report shows you ran a scanner. It does not show whether the findings were exploitable, whether they were treated, or whether your defenses and monitoring caught an attacker moving through the system. Auditors have seen too many clean scans sitting next to a system that any tester could break in an afternoon.
A penetration test closes that gap. It is performed by a human who validates findings, demonstrates real impact, and tells you which issues actually put customer data at risk. That is the difference between "we scanned" and "we proved." Most SOC 2 auditors now treat an annual pentest as the expected baseline for any company whose systems touch customer data or the public internet, which is to say almost every SaaS company pursuing SOC 2.
In short: the criteria give you flexibility, but the path of least audit friction runs straight through a pentest.
Need a SOC 2-ready pentest? Map your system to the common criteria your auditor checks, then get a dashboard-delivered report built for your evidence file.
Book your SOC 2 pentestWhat a SOC 2-Aligned Pentest Must Include
Not every pentest satisfies a SOC 2 examiner. To serve as evidence, it has to map to your in-scope system and produce a report the auditor can read against the criteria. Three things matter.
Scope that matches your system boundary
Your pentest scope should match the system boundary described in your SOC 2 report: the production application, the supporting infrastructure, and the environments where customer data lives. If your report covers a customer-facing SaaS platform and its cloud backend, a test that only covers the marketing website leaves a gap the examiner will flag. The test has to cover the assets that carry your in-scope data.
This is where scoping goes wrong most often. Companies buy a generic "website pentest," then discover at audit time that their actual production environment was never touched.
Budget Security solves this with AI goal-based scoping. You register your IT assets once, then pick the goal: in our case, SOC 2 readiness. The scoping engine maps your assets to the common-criteria expectations behind CC4.1 and the CC7 series, then proposes exactly what gets tested and how deep. If a tighter budget would leave an in-scope production asset uncovered, the engine tells you plainly that the scope no longer meets the SOC 2 goal and why. No guesswork, no over-scoping, no expensive surprises during the audit window.
Frequency: annual, plus after major change
SOC 2 does not set a fixed pentest interval, but examiner expectation and good practice have converged on a clear rule. Run a penetration test at least once a year, and again after any significant change to your in-scope system. A major new feature, an infrastructure migration, or a new public-facing service all reset your risk picture and warrant a fresh test.
For a Type 2 report, an annual cadence keeps your evidence current across the review period. A test from two years ago does not reflect the system your auditor is examining today, and it weakens the operating-effectiveness story your report depends on.
The report as audit evidence
This is the part most articles skip. The pentest only counts if the deliverable works as audit evidence against the criteria. Your auditor wants to see the scope tested, the findings, the risk ratings, the remediation status, and ideally proof of retesting on the issues you fixed. That trail is what links CC4.1 and CC7 to a working reality.
Budget Security delivers all of this through a dashboard rather than a static PDF buried in an email thread. You get an issue tracker, remediation status per finding, retest results, and a full history across engagements. When your auditor asks for evidence that you monitor controls and respond to vulnerabilities over time, you open one view that shows the finding, the fix, and the verification. For a Type 2 report covering a period, that continuity is far more convincing than a one-off PDF that documents a single moment.
How Budget Security Scopes a SOC 2 Pentest
Most providers scope from a sales call, where a senior tester estimates your needs from a conversation. That introduces guesswork and usually padding. We replaced that with objective, goal-based scoping.
- Register your assets. Web apps, APIs, cloud infrastructure, all in one place.
- Pick the goal: SOC 2 readiness. The engine maps your in-scope system to what CC4.1 and the CC7 criteria expect.
- See the test plan and the tradeoffs live. Add days to deepen coverage, or trim them and see exactly what gets cut and whether the scope still meets the SOC 2 goal.
- Get a dashboard-delivered report built to drop straight into your audit as control evidence.
The test itself is run by OSCP-certified veterans. We kept the caliber of a premium consultancy and modernized everything around it: the scoping, the delivery, the program management. The result is a test that is genuinely SOC 2-aligned, not a generic scan with a compliance label on the cover.
Cost and Timeline
Pricing starts from 849 EUR per day, published on the site, with no "contact sales" wall. The day count depends on your in-scope system and the depth your SOC 2 goal requires, which the scoping engine sets transparently rather than guessing. For a full breakdown of what drives pentest pricing, see our guide to what a pentest costs.
On timeline: most SOC 2 clients move from booking to test kickoff within 7 days. That matters when your audit window is open and your evidence has to be in place before the examiner reviews the period.
Get a SOC 2-Ready Pentest, Scoped in Minutes
Map your system to the common criteria your auditor checks, then get a dashboard-delivered report built for your SOC 2 evidence file.
OSCP-certified testers · dashboard-delivered evidence · from 849 EUR/day