SOC 2 Penetration Testing Requirements

What SOC 2 actually says

The Trust Services Criteria are written as objectives rather than procedures. The relevant ones require that you monitor your system, identify vulnerabilities, evaluate whether controls operate effectively, and act on what you find. Nothing specifies how.

In practice, auditors have converged on penetration testing as the expected evidence for vulnerability identification and control effectiveness. Whether its absence becomes an exception depends on your auditor, your risk profile and what compensating evidence you can show. The safe assumption is that you will be asked for one.

Type I and Type II change what the evidence has to prove

A Type I report assesses whether controls are suitably designed at a point in time. A Type II assesses whether they operated effectively across an observation period, typically three to twelve months.

That distinction matters for timing more than for testing. For a Type II, evidence needs to fall inside the observation period, and a test conducted before the period began may not count towards it. This is the single most common scheduling error we see, and it is entirely avoidable.

How the findings map to criteria

• Vulnerability identification — the test itself is the evidence, provided the report documents scope and methodology
• Change management — testing after significant change demonstrates the control operates, which is why the test date relative to your releases matters
• Monitoring — what your systems detected during our testing is direct evidence of monitoring effectiveness, and our attack timeline supports it
• Risk assessment — findings feed your risk register, and auditors look for the loop from finding to assessment to decision
• Remediation — retest evidence closes the loop and is frequently what turns a potential exception into a clean result

What to ask your auditor before scoping

Auditor expectations vary enough that guessing is wasteful. Four questions resolve almost all of it: do you require penetration testing or accept alternative evidence; must the test fall within the observation period; do you require external independence; and do you have a required format or specific evidence requests. Bring those answers to scoping and the engagement can be shaped to close the requirement exactly.

Timing

For a first Type II, test early in the observation period. That gives you time to remediate and retest inside the window, so the auditor sees findings that were identified and closed — which evidences your remediation control operating — rather than an open list at the end.

What goes into your evidence pack

For a SOC 2 audit the report is only part of what gets requested. We produce the surrounding artifacts as a matter of course, because assembling them afterwards from memory is where teams lose time they do not have.

• A scope statement naming the systems, environments and roles tested, and the basis on which scope was drawn
• A methodology description your auditor can assess as industry-accepted
• Evidence of tester competence and organisational independence from the team that built the system
• Findings with a stated severity rationale, since unexplained ratings are challenged more often than the findings themselves
• Remediation and retest evidence with dates, which is what demonstrates your remediation control operating
• Test dates positioned relative to your observation period and your significant changes during it

The exceptions we see most often

Three patterns account for most penetration-testing-related exceptions in first-time SOC 2 audits, and all three are scheduling or scoping problems rather than testing problems.

The first is timing: a test completed before the observation period opened, which frequently cannot be counted towards it. The second is an open critical finding at period end, where remediating and retesting inside the window would have converted a weakness into evidence of a control working. The third is scope drawn around the application while the auditor's system description also covers supporting infrastructure that nobody tested.

All three are avoidable, and all three are cheaper to avoid than to explain.

Common questions