Does SOC 2 require a penetration test?

Short answer: no. SOC 2 has no control that says “obtain a penetration test.” People are often surprised by that, and then disappointed, because knowing it rarely gets them out of buying one.

Here is the longer version, which is more useful.

What SOC 2 actually is

SOC 2 is not a checklist you pass. It is an audit of claims you make about yourself.

You write control descriptions covering the Trust Services Criteria you have chosen, a licensed CPA firm tests whether those controls exist and operate as described, and the report says what they found. Type I looks at design at a point in time. Type II looks at operating effectiveness across a window, usually three to twelve months.

The word “penetration test” does not appear as a requirement anywhere in that. What does appear, under the common criteria, is language about evaluating and monitoring vulnerabilities and about assessing whether controls work. CC4.1 is about evaluations of internal control. CC7.1 covers detecting vulnerabilities and monitoring for change. Those are the hooks.

So the framework asks whether you evaluate your security controls. It does not tell you how.

Why your auditor asks anyway

Because you told them you would.

That sounds glib, so let me be specific about the mechanism. When your organisation writes its control descriptions, somebody has to describe how you satisfy the criteria around vulnerability evaluation. Almost every company writes something like “an independent third party performs annual penetration testing,” because it is the shortest defensible sentence that closes the gap and because the template they started from said so.

Now it is in your own description. The auditor’s job is to test whether you did what you said. You committed to an annual penetration test in writing, and if you cannot produce one, the finding is not “you failed to meet SOC 2.” It is “the control described did not operate,” which lands in the report the same way.

You could describe a different control. Internal scanning with documented remediation, a bug bounty, architecture review, secure development practices. All defensible, and auditors do accept them. Very few companies rewrite that sentence, because rewriting it means arguing with an auditor about whether your substitute is equivalent, and buying the test is faster than winning that argument.

Your customers ask harder than the framework

This is the part people miss, and it is usually what actually forces the purchase.

The report is a sales document. You are getting it because enterprise buyers will not sign without one. And those buyers do not stop at the report; they send a security questionnaire, and the questionnaire is not bound by the Trust Services Criteria. It asks directly: do you perform annual third-party penetration testing, and can we see the summary or attestation letter.

There is no interpretive wiggle room in a checkbox. Explaining that SOC 2 does not technically require one is a losing move in a procurement review, where the person reading has three hundred vendors and a spreadsheet.

So the real answer to “does SOC 2 require a pentest” is that SOC 2 does not, your own control description probably does, and your customers definitely do.

Where it genuinely is required

Worth separating out, because the frameworks differ and people blur them together.

PCI DSS requires it outright, in requirement 11.4, at least annually and after significant change, plus segmentation testing where segmentation is used to reduce scope. It also requires the tester be organisationally independent of the systems under test, which for most companies means external. This one is not negotiable.

HIPAA does not name penetration testing either. The Security Rule requires a risk analysis and periodic technical evaluation, and testing is a common way to satisfy the latter.

ISO 27001 works like SOC 2 in this respect: Annex A talks about technical vulnerability management, not about penetration tests specifically.

CMMC and NIST SP 800-171 ask for security assessments and vulnerability scanning. CA-8, the control that names penetration testing, lives in 800-53 rather than 800-171.

Only PCI DSS names it as a requirement. Everywhere else it is the customary way to satisfy something broader.

What the report needs to contain

If you are buying one for an audit, the technical findings are almost beside the point for the auditor. What they check is the paperwork around them:

• scope, stated plainly enough that they can match it against your system description
• dates covering the audit window
• methodology, so it is clear this was testing rather than a scan
• who performed it, and their independence from the systems tested
• findings with severity ratings and their remediation status
• evidence that the findings went somewhere, which is usually the part that fails

That last one catches people. A clean report with unresolved highs and no ticket trail is worse than a report with findings you can show you fixed. The auditor is looking for a functioning process, not a good grade.

We write reports to carry both halves: an attestation letter and scope summary you can hand to an assessor or a customer, and technical detail your engineers can actually act on. Those audiences want different documents, and pretending one artefact serves both is how you end up with a report nobody reads.

The advice, plainly

Get the test. Not because SOC 2 says so, but because your control description says so and your customers will ask regardless, so the argument costs more than the engagement.

Then do the thing that actually matters, which is fixing what it finds and keeping the trail. The report is a snapshot. The audit is a snapshot of a snapshot. Neither one is security, and companies with clean reports get breached routinely through something nobody scoped.

If you are working toward a first audit, compliance readiness is the gap assessment side, and penetration testing is the evidence side. Same people either way, which is the point: the report comes from whoever did the testing, not from a subcontractor you never met.