← jacob.masse

Do You Need a Penetration Test for SOC 2?

This question comes up in almost every SOC 2 engagement: "Do we actually need a penetration test?" The technically-correct answer surprises people, and then the practical answer overrides it. Let me give you both, because the gap between them is where startups get tripped up.

The technical answer: not strictly

SOC 2 does not contain a control that says "thou shalt run a penetration test." The framework is built on the Trust Services Criteria, which describe outcomes, you must identify vulnerabilities, monitor your systems, and manage risk, without mandating a specific tool or test. In principle, you could satisfy the relevant criteria with a robust vulnerability management program and no formal pentest.

In practice, almost nobody does, and here is why.

The practical answer: yes, effectively

Three forces turn "not required" into "you need one":

• Auditors expect it. A pentest is the cleanest evidence that you are actively identifying vulnerabilities (criteria like CC4.1 and CC7.1). When an auditor sees a recent third-party pentest with remediation, that whole area of the audit gets easy. When they do not, they ask a lot more questions.
• Your customers demand it. The real pressure comes downstream. Enterprise vendor security questionnaires almost always ask, "Do you perform annual third-party penetration testing?" A "no" stalls the deal regardless of what SOC 2 technically requires.
• It is genuinely good security. SOC 2 is supposed to reflect that you are secure, not just documented. A pentest is one of the few controls that actually tries to break in.

Vulnerability scan vs penetration test, not the same thing

This trips up a lot of teams. An automated vulnerability scan runs a tool against your systems and produces a list of known issues. A penetration test is a human actively trying to compromise your application, chaining together the broken access control, the IDOR, the auth logic flaw, and the misconfigured cloud role that no scanner strings together on its own. Auditors and serious customers can tell the difference, and a scan report submitted as a "pentest" tends to invite scrutiny rather than close it.

What a SOC 2-ready pentest should include

If you are getting a pentest specifically to support SOC 2 and customer reviews, make sure the engagement produces:

• Manual testing of your web application, APIs, and cloud configuration, not just an automated scan.
• An executive summary plus a detailed technical report with severity, impact, and reproduction steps.
• Clear, prioritized remediation guidance your engineers can act on.
• A remediation retest, so you can show the auditor that findings were closed, not just logged.
• A letter of attestation, the shareable one-pager that satisfies customer security questionnaires without handing over your full findings.

How often?

Annually is the baseline expectation, plus after any significant change to your architecture. For a fast-moving startup shipping major features, a test before a big enterprise deal or a funding round often pays for itself immediately by clearing the security review that would otherwise block it.

So: SOC 2 does not force you to run a pentest, but your auditor, your customers, and your own risk posture all effectively do. Treat it as a required part of the program, scope it as manual testing rather than a scan, and make sure it produces something you can actually hand to a customer.