Does SOC 2 Require a Penetration Test?

Somewhere between the gap analysis and the audit, every SOC 2 team asks the same question: do we actually have to buy a penetration test? The honest answer has two halves. On paper, no: the criteria never name one. In practice, yes: your auditor will ask how you know your controls work, and your enterprise customers will ask for the test by name in their security questionnaires. This article walks through what the criteria actually require, why the expectation exists anyway, how the evidence maps to your controls, and how to time the test for a Type I or Type II report.

What do the Trust Services Criteria actually say?

SOC 2 is an attestation report issued by a licensed CPA firm after auditing your organization against the AICPA Trust Services Criteria: security is mandatory, with availability, processing integrity, confidentiality, and privacy added when your customers care about them. The criteria are written as control objectives, not as a checklist of named tools or named tests. They expect you to identify and assess risks, monitor whether controls operate, detect and remediate vulnerabilities, and manage change safely. Nowhere do they say the words "perform a penetration test."

That wording is deliberate. SOC 2 leaves the how to you and your auditor. You commit to controls that meet the criteria, and the auditor examines whether those controls are suitably designed and, for a Type II report, whether they operated effectively over an observation window. The question is never "did you buy a pentest." It is "what evidence shows your security controls actually work." A penetration test is simply the strongest common answer.

Why do auditors expect a penetration test anyway?

Because the auditor's job is evidence, and a penetration test is among the strongest evidence available that controls hold up in practice. Policies describe what should happen. Monitoring output shows what did happen. A penetration test shows what a skilled adversary could actually do, which is the question the security criteria exist to answer. It is independent, adversarial validation rather than self-attestation.

There is a commercial layer too. The SOC 2 report exists because enterprise buyers ask for it, and those same buyers routinely ask for a recent penetration test directly, in the same questionnaire. Arriving with a report but no test invites the follow-up question you were trying to avoid. Most auditors and enterprise buyers now treat a recent test as the norm, which makes it a de facto requirement even though it is not a de jure one.

How does penetration test evidence map to SOC 2 controls?

A well-run test is not a single artifact. It is a cycle of scoping, testing, remediation, and verification, and that cycle feeds several areas of the criteria at once.

This mapping is why report quality matters as much as the test itself. A report with severity scoring, proof-of-exploit, and a documented retest drops into your evidence library as one clean bundle. We break down the anatomy in what's inside a penetration test report.

When should you run the test: Type I or Type II timing?

A Type I report attests that your controls are suitably designed at a point in time. For Type I, run the test before the audit so the design claims are validated and the significant findings are remediated by the report date.

A Type II report attests that controls operated effectively over an observation window, commonly three to twelve months. Here the test belongs inside the window, and early enough in it that remediation and the retest complete before audit fieldwork. That way the report covers the full cycle rather than a test still in flight. A common path is a Type I first, rolling straight into the Type II window, with the penetration test scheduled early in that window.

Two timing mistakes cause most of the audit friction. A test dated close to fieldwork with critical findings still open raises more questions than it answers. And a stale test performed against a previous architecture invites the question of whether the evidence reflects the system actually being audited.

What will the auditor look for in the pentest evidence?

Auditors want the full cycle documented, not a PDF sitting in a folder:

• A scoped, authorized engagement performed by a qualified independent party, with the scope and rules of engagement documented.
• A real report: executive summary, technical findings with severity scoring such as CVSS and CWE, and proof-of-exploit rather than raw scanner output.
• Remediation records: tickets, fixes, and decisions, including documented risk acceptance where you consciously chose not to fix.
• Verification: a retest confirming the fixes landed, ideally packaged as a remediation letter you can hand over as one artifact.

Should you run the pentest and SOC 2 readiness together?

Yes, and the reason is mostly practical: the readiness gap analysis and the penetration test scoping ask overlapping questions about the same systems, data flows, and user roles. Run them separately and you pay for that discovery twice, then spend more effort stitching the pentest findings into the control narrative afterward.

Byte Optimizer includes the penetration test inside the SOC 2 readiness engagement, so scoping and evidence are handled once and the findings map directly to your controls. The test itself is a full manual penetration testing engagement, with the retest included. And if you are weighing SOC 2 against other frameworks, our guide to SOC 2, ISO 27001, and GDPR explains how the same technical work feeds all three.

Frequently asked questions

Does SOC 2 Type II require a new penetration test every year?

The criteria do not mandate a cadence, but Type II reports recur, and each audit cycle needs evidence that is current for its observation window. In practice that means a fresh test each cycle, and sooner after major architectural changes. Enterprise security questionnaires also routinely ask for the date of your most recent test.

Can automated scanning replace a penetration test for SOC 2?

No, and the two answer different questions. Continuous scanning is good evidence of ongoing vulnerability monitoring and belongs in your program. But auditors and enterprise buyers expect human-led testing that chains weaknesses into demonstrated impact, including the business-logic flaws automation cannot detect. The strongest evidence bundle contains both, mapped to the same controls.

Who should perform the penetration test for SOC 2?

A qualified party independent of the team that built the system, so the evidence carries weight with the auditor. Buyers commonly ask about a firm's methodology, sample reports, and industry certifications. What matters most is a defensible engagement: scoped under NDA, manually executed, evidenced with proof-of-exploit, and closed with a retest.

Does ISO 27001 require a penetration test?

Like SOC 2, ISO 27001 does not name a penetration test outright, but it expects technical testing of controls and technical vulnerability management. Auditors accept a penetration test as strong evidence there too, which is why teams pursuing both frameworks run a single test and map the same evidence to each framework's language.