Does SOC 2 require a penetration test?

Short version, because this is the question you actually came for: SOC 2 does not literally require a penetration test, and you should almost certainly get one anyway. The framework never uses the word "required" next to penetration testing. It does something more interesting, and more binding in practice, which is name it directly as the expected way to satisfy a criterion you cannot skip. So the real answer is not yes or no. It is "not mandated, expected in all but name," and the gap between those two things is where teams get into trouble.

What the Trust Services Criteria actually say

SOC 2 is built on the AICPA's Trust Services Criteria. The criterion that matters here is CC4.1, which covers monitoring. Its points of focus spell it out almost verbatim: "management uses a variety of ongoing and separate evaluations, including penetration testing, independent certifications such as ISO, and internal audit assessments." Penetration testing is not buried in a footnote or implied between the lines. It is named, by the framework, as an example of how you demonstrate the control.

That is why "is it required" is the wrong question. The framework is principles-based: it tells you the outcome (you continuously evaluate whether your controls work) and lists the recognized ways to prove it, with penetration testing first among them. You are technically free to satisfy CC4.1 another way. You are not free to ignore CC4.1.

Why "not required" still means "do it"

Here is what happens in practice when a pentest is missing from your evidence. The auditor reaches CC4.1, looks for your separate evaluations, and does not find the one their framework names first. Now you owe them a documented justification for why not, plus alternative evidence that you monitor for vulnerabilities to the same standard. That is a harder, more uncertain conversation than simply producing the report would have been. For almost every company pursuing SOC 2, the pentest is the path of least resistance, not the burden. Skipping it is the burden.

CC4.1 versus CC7.1: a pentest is not a scan

This is the distinction that trips people up, and getting it right saves you an awkward audit. Two different criteria are in play, and they are not interchangeable. CC7.1 covers vulnerability management, the ongoing detection of known weaknesses, which is where automated vulnerability scanning lives. CC4.1 covers monitoring through evaluations like penetration testing, which validates whether your controls actually hold up under attack. A scanner flags what might be wrong; a penetration test demonstrates the impact. Handing an auditor a scan report where a pentest belongs is a common and avoidable miss: it answers a different criterion.

Type I versus Type II, and the calendar

Timing is where the requirement gets concrete. A Type I report assesses whether your controls are designed correctly at a single point in time. A Type II report assesses whether they operated effectively across a window, typically three to twelve months, and that window is the part that bites. For Type II, the expectation is that the penetration test falls inside the observation period, and that you remediate the serious findings, the criticals and highs, before the period closes. A test from eighteen months ago, or one whose critical findings are still open on the last day of the window, is not the evidence the auditor needs.

What a SOC 2-ready pentest needs

Not every penetration test satisfies an auditor. The ones that do share a recognizable shape.

1. 01Scoped to your SOC 2 system boundary, the actual systems and data in the report, not a convenient subset.
2. 02Run within the audit period, so the evidence is live rather than historical.
3. 03Findings mapped to the relevant criteria (CC4.1 and the CC6 and CC7 controls they touch), so the auditor can connect proof to requirement.
4. 04Each finding carrying severity and concrete evidence, not a raw tool dump.
5. 05Documented remediation of the serious findings, verified by a retest before the period closes.
6. 06A report dated within the period and scoped to the systems in question.

The trap to avoid

The failure mode is buying the cheapest thing that produces a PDF, usually an automated scan with a cover page, and assuming a logo satisfies the criterion. A sharp auditor reads past the cover. If the findings have no proof of exploit, if the severities are clearly just raw tool scores, and if nothing maps to your boundary or your criteria, you have evidence for CC7.1 at best and a gap at CC4.1. Worse, you have a false sense that you are covered. The point of the exercise was never the document. It was knowing what an attacker would actually find, and being able to show you fixed it.

That is the test Uvy is built to deliver: a real penetration test against a recognized methodology, scoped to your boundary, run within your window, every exploitable finding proven with a working exploit, and a retest to confirm the serious ones are closed, in a report your auditor and your prospect can both read. See how it works.