Does SOC 2 require a penetration test?

No. No Trust Services Criterion mandates a penetration test. The term appears only in the AICPA’s non-binding “points of focus.” In practice your auditor will expect a recent test anyway, your enterprise customers will ask for the report itself, and the test must land inside your Type 2 observation window to count as evidence. Here is how that works, with the source text.

On this page: what the AICPA says · why auditors expect one · internal or third party · timing · scans vs pentests · cost · other frameworks

What the AICPA actually says

SOC 2 audits are performed against the Trust Services Criteria (TSC, 2017 with revised 2022 points of focus). The criteria never require penetration testing. The concept enters through two points of focus, which the AICPA describes as illustrative guidance, not requirements.

CC4.1: separate evaluations

“COSO Principle 16: The entity selects, develops, and performs ongoing and/or separate evaluations to ascertain whether the components of internal control are present and functioning.”

The supporting points of focus list penetration testing as a named example of a separate evaluation. An example, not a mandate.

CC7.1: vulnerability detection

“…the entity uses detection and monitoring procedures to identify (1) changes to configurations that result in the introduction of new vulnerabilities, and (2) susceptibilities to newly discovered vulnerabilities.”

Points of focus are explicitly optional. The AICPA’s own framework material states that an entity can meet a criterion without addressing every point of focus. That is the whole legal answer: penetration testing is an expected form of evidence, not a requirement.

If someone tells you SOC 2 “requires” an annual pentest, they are selling you one. We sell penetration tests and we are telling you it is not required. What follows is why nearly everyone buys one anyway.

Why auditors expect one anyway

Your auditor has to form an opinion on whether your vulnerability management controls actually operated during the period. A recent penetration test is the cheapest, densest piece of evidence that they did. Without one, auditors typically respond in one of two ways: supplemental evidence requests (scan logs, patch records, remediation tickets, assembled by you at the worst possible time), or exception language in the report that your customers will read.

The customer side matters more than the auditor side. 82% of companies use SOC 2 reports as part of third-party security assessment (Whistic TPRM Impact Report, 2025), and the market has become intolerant of thin evidence: in A-LIGN’s 2026 compliance benchmark (1,043 respondents, 85% US-headquartered), more than half of organizations had a report rejected for incomplete documentation or insufficient testing, up from 38% two years earlier.

Thomas Ptacek’s much-cited fly.io essay on SOC 2 puts the relationship between the two artifacts plainly:

“[SOC 2 is] a weak positive indicator of security maturity, in the same ballpark of significance as a penetration test report (but less significant than multiple pentest reports).”

Security reviewers agree in practice. One CISO on the buyer side of vendor reviews, on r/SaaS:

“Give me a penetration test or allow me to run one, vulnerability reports, SAST, DAST, SCA, and it doesn’t matter if you have SOC 2 or not.”

Internal team or third party?

SOC 2 does not say the tester must be external. The Trust Services Criteria never mention tester independence at all. Even PCI DSS, the strictest framework in common use, states repeatedly through Requirement 11.4 that the tester is “not required to be a QSA or ASV.” What PCI does demand is organizational independence: the tester cannot assess systems they build, run, or maintain.

That is the practical bar for SOC 2 too, and it is why small teams end up buying the test. At seed or Series A, with one platform team, there is no engineer who is independent of the systems being tested. Independence is a quality bar rather than a legal one, and for most startups it is structurally impossible to meet in-house.

What actually gets judged

Your customers’ security teams will read the report. They will look at who performed the test, what methodology was used, whether findings carry working reproduction steps, and whether a retest verified the fixes. A report that fails that reading is worse than no report, because it signals you bought a checkbox.

The timing rule that catches teams out

For a Type 2 report, evidence has to come from inside your observation window, the 3 to 12 month period the audit covers (Linford & Co, a licensed CPA firm, notes 12-month windows are the most common). A penetration test dated before the window opened is not evidence that the control operated during the period.

Three timing rules

1. Book the test early in the window, not at the end. You need time to fix what it finds and to document the remediation.
2. Expect a retest. A finding that stays open at report time becomes an exception. A finding that was found, fixed, and verified is a functioning control.
3. Repeat annually and after major changes. That is the cadence auditors treat as normal, and it maps to the annual renewal of the report itself.

A scan is not a pentest, and reviewers can tell

The cheap tier of this market sells automated scans dressed as penetration tests. Buyers have noticed. A compliance readiness vendor describing its competitors: “what they sell as a pen test we would call a vulnerability scan (fully automated, no human involved).” A practitioner reviewing a bundled compliance pentest called it “a very trivial, automated blackbox affair, almost completely meaningless.”

The consequence lands on you, not the vendor. A security reviewer on r/soc2:

“If I’m reviewing your report and you hand me a cheap/fast one that does not meet the quality/reporting standards, then I will classify you as worse than not having one at all.”

The honest heuristic: if the price is under about $4,000 and the timeline is under a week, you are buying a scan with a cover page, and the people your SOC 2 is supposed to convince can tell. Our comparison of manual pentests and continuous testing goes deeper on what separates real testing from report theater.

What it costs, in real numbers

Most firms in this market do not publish prices. These are the observable 2026 bands for a SOC 2-driven test of a typical SaaS product, consistent with DeepStrike’s market survey (updated July 2026) and with what founders self-report paying. The full band-by-band breakdown, including the day-rate math behind every quote, is in how much penetration testing costs:

Where the cheap tier breaks

The trap is the single vendor who bundles the audit and the pentest into one cheap fee. An auditor charging $150 an hour who sells a $2,500 package covering both has about 16 hours for the two combined, which is why those reports converge on templated no-exception findings. The 2026 audit-mill scandal (533 near-identical reports across 455 companies) made buyers actively hostile to that tier. A standalone attestation is a different thing: when the penetration test runs separately and continuously all year and the evidence is pre-mapped to the controls, the CPA’s own hours go entirely to a real audit, which is how an independent attestation prices low without becoming a mill. The one legitimate way real testing gets cheap is stack ownership: AI agents run the coverage and hackers in the loop validate what actually exploits (public examples: a critical RCE advisory in velocity.js and a reported RCE fixed in JSONPath Plus). That is how our pricing stays published and low without the report going templated.

How SOC 2 compares to the other frameworks

SOC 2’s soft expectation is the exception. Most other frameworks are stricter, and if any of them is on your roadmap the pentest stops being optional:

A useful consequence: a properly scoped penetration test is the one artifact that satisfies evidence expectations across every framework on that list. If ISO 27001 or PCI is coming, buy one test that covers both sets of requirements instead of two thin ones. The frameworks we test against and our public benchmarks show how we scope that.

The short version

• SOC 2 does not require a penetration test. Anyone who says otherwise is paraphrasing a sales page, not the AICPA.
• Your auditor expects one, your customers increasingly demand the report itself, and more than half of companies have had a report bounced for thin testing.
• No certification is required of the tester. Organizational independence and a readable methodology are what reviewers actually judge.
• Time it inside the observation window, early enough to fix and retest.
• Budget $4,000 to $25,000 for a real one-off test depending on surface. Below that, at human day rates, you are buying a scan, and reviewers can tell.

More background: penetration testing cost in 2026, what PCI DSS 11.4 requires, and how our pricing works.