SOC 2 is where terminology matters, so a correction first: SOC 2 is an attestation, not a certification. There is no SOC 2 certificate. A licensed CPA firm enrolled in the AICPA peer review program examines your controls against the Trust Services Criteria and issues a report containing their opinion. No certification body can issue one, and any vendor offering you a “SOC 2 certification” is describing something that does not exist.
With that established, the practical question.
Penetration testing is not a named requirement
Search the Trust Services Criteria for “penetration test” and you will not find a requirement. This surprises people, and it occasionally leads teams to conclude that testing is optional.
What the criteria do say is more general and, in practice, more demanding.
CC4.1 requires the entity to select, develop and perform ongoing and/or separate evaluations to ascertain whether the components of internal control are present and functioning. A penetration test is the most direct evidence of a separate evaluation of technical controls that most organisations can produce.
CC7.1 requires the entity to use detection and monitoring procedures to identify changes to configurations that introduce new vulnerabilities, and susceptibilities to newly discovered vulnerabilities. Vulnerability management, patching and testing evidence all land here.
So the requirement is not “have a pentest”. It is “demonstrate that you evaluate whether your controls work”. Testing is how most organisations demonstrate it, which is why most auditors expect to see it.
The second reason to have one
Independent of the audit: your enterprise customers will ask. A recent third-party penetration test report, or an attestation letter derived from it, is a standard item on vendor security questionnaires. Organisations pursuing SOC 2 are usually pursuing it because enterprise buyers asked, and those same buyers ask for the test.
In our experience the report gets used more often in sales than in the audit.
What makes the evidence useful
Not every report satisfies an auditor equally. What they look for:
- Scope that matches the system description. A test of your marketing site does not evidence controls over the production platform in your SOC 2 boundary.
- Timing within the observation period. For a Type II, testing performed before the period started is weaker evidence than testing inside it.
- Independence. Performed by a party independent of the team that built and operates the system.
- A documented methodology — PTES, NIST SP 800-115, the OWASP testing guides — rather than an unexplained list of findings.
- Evidence of remediation. This is the one most often missing. A report full of open critical findings evidences that you evaluated your controls and that they failed. Retest results showing findings closed are what actually supports the criteria.
Type I and Type II
A Type I reports on the design of controls at a point in time. A Type II reports on operating effectiveness over a period, typically three to twelve months. Type II is what enterprise buyers usually mean when they ask for SOC 2.
For a first Type II, the practical sequencing is: readiness work and remediation first, testing early enough in the observation period that findings can be closed and retested inside it, and the examination afterwards.
What readiness should involve
Scoping which criteria apply and which systems are in the boundary. A gap assessment against the applicable criteria with each gap owned and dated. Control design and evidence collection — knowing what the auditor will ask for and having it ready before they ask. Penetration testing against CC4.1 and CC7.1. Then coordination with the CPA firm through fieldwork.
Done properly, readiness makes the examination shorter and cheaper, because the findings are closed before fieldwork begins rather than discovered during it.