Does SOC 2 require a penetration test?

What the criteria actually say

The Trust Services Criteria are written as outcomes, not procedures. The ones a penetration test typically supports are the risk-identification and monitoring criteria — the organisation identifies and assesses risks to its objectives, and evaluates whether its controls are working — along with the vulnerability-management expectations that sit under the common criteria for system operations.

Because the criteria are outcome-based, your auditor is looking for evidence that you identify security weaknesses in a structured, repeatable way and act on what you find. A penetration test report with tracked remediation is the cleanest possible evidence of exactly that. That is why it has become the de facto expectation despite never being named.

What to scope

Scope the test to the systems inside your SOC 2 boundary — the infrastructure and applications that deliver the service your report covers. Testing things outside that boundary does not strengthen the report.

• The production application(s) your customers use, tested both unauthenticated and authenticated across each user role.
• The external perimeter of the production environment — exposed hosts, services and APIs.
• The cloud environment hosting it: IAM configuration, storage exposure, network segmentation, and secrets handling.
• Your identity provider and any SSO integration, since compromise there compromises everything.
• Internal network testing if your boundary includes corporate systems that can reach production.

Timing it around your audit

For a Type II report the test needs to fall inside your observation window, and you need enough time after it to remediate and evidence the remediation. Testing in the final fortnight before fieldwork is the classic mistake: you get findings and no time to fix them, and the auditor documents that.

A practical sequence is to test early in the window, remediate, run the included retest so you have documented closure, and hand the auditor both reports. Findings that were found and fixed are a strength in an audit — they demonstrate the control working. Findings still open on the last day are a weakness.

What the deliverable needs to contain

• Clear scope statement — what was tested, what was excluded, and over what dates.
• Methodology, so the auditor can see this was a structured engagement rather than a scan.
• Findings with severity ratings, evidence, and business impact.
• Remediation guidance specific enough for your engineers to act on.
• Retest results confirming that critical and high findings are closed.
• An executive summary that a non-technical reader can follow.