SOC 2 and Penetration Testing: What Auditors Actually Require

"Does SOC 2 require a penetration test?" is one of the most common questions we get from teams heading into their first audit, and the honest answer is: not explicitly by name, but in practice, most auditors expect one as evidence for a specific control, and skipping it tends to cost more time than doing it.

What the criteria say

SOC 2 is built around the AICPA's Trust Services Criteria, and the Security criterion (common to every SOC 2 report) includes CC7.1: the entity uses detection and monitoring procedures to identify changes that could indicate unauthorized access or vulnerabilities. Nothing in the criteria itself says "you must contract a penetration test." What it says is that you need to demonstrate you're actively identifying vulnerabilities, and a penetration test is the most direct, auditor-recognized way to demonstrate that, which is why it's become a de facto expectation rather than a written requirement.

Type I vs. Type II changes what "recent enough" means

A Type I report evaluates whether controls are designed appropriately at a single point in time. A Type II report evaluates whether those controls actually operated effectively over an observation period, typically 3–12 months, which means for Type II, a pentest from 18 months ago won't hold up as evidence for the current audit period. Most auditors expect testing at least annually, timed to fall within (or close to) the observation window being audited.

What auditors want to see, beyond "we ran a test"

• A written scope that covers the systems actually in the audit boundary, a pentest of a marketing website doesn't demonstrate anything about the production application handling customer data.
• Evidence that findings were tracked to remediation, not just a report that sat in an inbox. A clean pentest report with no follow-through on fixes is a weaker piece of evidence than a report showing findings were found and closed.
• Testing performed by a party independent of the team that built the system, internal-only testing by the engineering team itself is a materially weaker signal than an external assessment.

The mistake that costs the most time

Scheduling the pentest for the week before the audit begins. Findings need time to be triaged, fixed, and, ideally, re-tested to confirm the fix actually worked, and auditors generally want to see that follow-through as part of the evidence, not just the initial findings list. Building the test into the calendar 6–8 weeks ahead of the audit window, rather than treating it as a last-minute checkbox, is the difference between a pentest that strengthens the audit and one that just adds a line item to note as an open finding.

Where this connects to the rest of your program

A SOC 2-oriented pentest is scoped differently from a general security assessment, it needs to map cleanly to the audit boundary and produce evidence in the form auditors expect. If you're heading into a first SOC 2 audit or renewing an existing one, our penetration testing engagements are built to produce exactly that kind of audit-ready evidence, and our security consulting work covers the broader control gaps, like the ones we cover in common cloud misconfigurations, that CC7.1 and its neighboring criteria actually test for. For the equivalent, more explicitly numbered obligation in payments, see our piece on PCI DSS and penetration testing.