SOC 2 Penetration Testing: What Auditors Actually Require (2026)

Short answer: the SOC 2 framework does not explicitly mandate a penetration test — but in practice a pen test is how most organizations demonstrate the vulnerability-management and monitoring controls an auditor looks for, and many auditors now expect one, especially for a Type II report. If a SOC 2 audit is on your calendar, plan on a pen test.

Here is what that means in practice: what the criteria actually say, what your auditor wants to see, how often to test, and what a report has to contain to clear review without back-and-forth.

Does SOC 2 require a penetration test?

SOC 2 is built on the AICPA Trust Services Criteria, not a checklist of tools. No single criterion says "perform a penetration test." Instead, several common-criteria controls — around vulnerability detection, monitoring, and risk assessment — are most credibly satisfied by an independent test that proves your defenses hold up against a real attacker. A vulnerability scan alone is often not enough for a Type II, because it shows what might be exploitable, not what is.

The result is a de facto expectation: you can technically pass without a pen test if you satisfy the criteria another way, but the cleanest, least-argued path through most audits is an annual third-party penetration test with a report you can hand the auditor.

What SOC 2 auditors actually look for

When an auditor reviews your pen test, they are checking a few specific things:

• Independence — the test was run by a qualified third party, not your own team scanning yourselves
• Scope that matches your system boundary — the same environment described in your SOC 2 report
• Findings rated by severity, with clear evidence (proof-of-concept steps), not just a scanner dump
• Remediation — what you fixed, and retest evidence showing the important findings are closed
• Timing — the test falls inside the audit period for a Type II

The single most common reason a report gets kicked back is that it is a raw scanner export with no severity context and no remediation evidence. Auditors want a narrative they can rely on, not a 200-page appendix.

Type I vs Type II: does the timing change?

A Type I report describes your controls at a single point in time. A Type II covers how those controls operated over a period — usually 3 to 12 months. For a Type II, the pen test generally needs to fall within that observation window, and any material findings should be remediated and retested before the window closes. Scheduling the test early in the period, not the week before the auditor arrives, is what keeps a deadline from becoming a crisis.

How often do you need to test for SOC 2?

The common cadence is annual, plus a retest after remediating significant findings, plus a fresh test after any major change to the in-scope environment (a new production application, a cloud re-architecture, a migration). Annual is the baseline auditors expect; the change-driven tests are what keep you from carrying a known gap into the next audit.

What the report needs to include

A report built for a SOC 2 auditor — rather than for a bookshelf — contains:

• An executive summary a non-technical reader can act on
• Scope and methodology (what was tested, how, and against which standard)
• Each finding with severity, business impact, and reproduction steps
• Clear remediation guidance ranked by what to fix first
• Retest results proving the high-severity items are closed

This is exactly where a lot of firms stop — they send the report and disappear. The report is evidence for your auditor; the walkthrough of what to fix first is what actually closes the gaps before the audit.

Cost and timeline

A scoped SOC 2 penetration test for an SMB or mid-market team is a fixed-price project, not an open-ended engagement — you should get an exact number before any work starts. Turnaround is typically 2 to 3 weeks from kickoff to a finished, auditor-ready report, which leaves room to remediate and retest before an audit date rather than racing it.

Frequently asked

Is a vulnerability scan enough for SOC 2?

Sometimes for a Type I, rarely for a Type II. A scan finds known issues; a penetration test validates whether they are actually exploitable in your environment. Most auditors want the second thing.

Can we use our own team instead of a third party?

For the pen test that backs your SOC 2, independence matters. An internal test can support your program, but auditors give far more weight to a qualified third-party assessment.

How far before our audit should we test?

Early enough to fix and retest — realistically 4 to 8 weeks before the audit date, not the week of. That buffer is the difference between a clean report and a finding you have to explain.