Not by name, same story as ISO 27001. The AICPA's Trust Services Criteria never spell out "penetration test" as a line item. But SOC 2 gets closer to naming it than ISO 27001 does: Criterion CC4.1 (Monitoring Activities) actually lists penetration testing by name as an example of the kind of evaluation it expects you to run. It's not a strict mandate, but it's about as close as a framework gets without becoming PCI DSS.
Here's what the criteria actually say, and what that means for what you put in front of an auditor.
What the Trust Services Criteria actually expect
Two criteria do most of the work here:
CC4.1, Monitoring Activities. This is the one that names penetration testing directly as an example of an "ongoing and separate evaluation." It's asking whether you're actively checking that your controls work, not just documenting that they exist on paper.
CC7.1, System Operations. This covers how you detect changes and new vulnerabilities in your environment. A penetration test is the clearest way to show an examiner that your detection and monitoring actually catch something when a skilled person tries to get past it, rather than sitting untested until a real attacker shows up first.
A few other criteria in the CC6 series (logical access controls, threat prevention) also get supported by a well-scoped test, since attacking your access controls is usually part of the engagement anyway. But CC4.1 and CC7.1 are the ones your auditor is actually thinking about when they ask "do you have a recent pentest report."
Type I vs. Type II changes the timing, not the expectation
A Type I report is a point-in-time snapshot: are your controls designed correctly as of one date. A Type II report evaluates whether those controls actually operated effectively over a period, usually 6 to 12 months. For Type II specifically, your pentest needs to fall inside that observation window to count as evidence. A test from 14 months ago doesn't help your current audit period, no matter how thorough it was.
This is the part that trips up companies running one test a year on whatever date happens to be convenient. If your audit period doesn't line up with your testing calendar, you can end up technically compliant but without valid evidence sitting inside the window your auditor is actually reviewing.
Vulnerability scan vs. penetration test, again
This confusion follows every framework we've written about, and SOC 2 is no exception. A vulnerability scan tells you a system is running outdated software. It doesn't tell you whether that vulnerability is actually exploitable, whether it can be chained with something else into real access, or whether your monitoring would have caught someone trying. CC7.1 is asking about detection of real threats, not a list of unpatched CVEs. Auditors that have seen enough of these reports know the difference immediately.
What a report needs to actually hold up
| What auditors look for | Why it matters |
|---|---|
| Scope coverage matching your SOC 2 system boundary | A test that skipped half your in-scope systems doesn't evidence the criteria for the part it missed |
| Findings mapped to specific criteria (CC4.1 at minimum) | Makes the connection between the test and the control explicit, instead of leaving your auditor to guess |
| Manual, adversarial testing, not just scan output | Automated-only or AI-only testing without human validation is increasingly flagged as insufficient on its own |
| Remediation documentation | Shows what got fixed, by whom, and when |
| Retest evidence confirming fixes held | Closes the loop, a findings list with nothing after it is an open question, not evidence |
One test, several frameworks
If you're also working through ISO 27001 or PCI DSS, the good news is a single well-scoped penetration test can generate evidence for all three at once, as long as it's mapped correctly. The same manual test that satisfies CC4.1 and CC7.1 here is the same evidence that supports Annex A 8.8 and 8.29 under ISO 27001, and with the right scoping, feeds Requirement 11.4 under PCI DSS too. The scoping and report mapping matter more than running three separate engagements for three separate certifications.