SOC 2 does not require a penetration test. Your auditor might.

The Trust Services Criteria describe outcomes, not tools: there is no clause that says "conduct an annual penetration test". Auditors commonly accept testing results as evidence for the access-control and monitoring criteria, and enterprise customers ask for them outright. Here is what that means in practice.

The requirements

What the SOC 2 text actually says

Why "SOC 2 Requires a Pentest" Is Wrong, and Why You Will Still Do One

SOC 2 is not a checklist standard. The Trust Services Criteria state objectives, you describe the controls you use to meet them, and the auditor tests whether those controls operate. Nothing in the criteria names penetration testing, which is why the honest answer to "is it required?" is no.

In practice almost every SOC 2 report from a software company references security testing, for two reasons. First, some criteria are hard to evidence any other way: you can assert that authorisation works, but a test that attempted to break it and failed is stronger evidence than an assertion. Second, your customers ask. Enterprise security reviews request a pentest report routinely, and their questionnaire does not care what the AICPA mandates.

So the useful question is not whether it is required, but what your auditor will accept. That answer varies between firms, and getting it in writing before you buy is the cheapest thirty minutes in the whole project.

What Auditors Accept as Evidence

A report that documents scope, methodology, findings with severity, and what happened to those findings. The last part carries the most weight and gets the least attention: a list of twelve issues from March says nothing about your control environment, while a trail showing each one closed, verified and not regressed demonstrates the control operating over the review period — which is exactly what a Type II examines.

Automated testing evidence is accepted by many auditors, particularly where it runs continuously and produces that trail. Some firms, and some customer contracts, specifically require human-led testing by a named third party. Neither position is unusual, and the difference in cost is large, which is why the question belongs at the start of the engagement rather than at the end.

What consistently causes friction: a vulnerability scan presented as a penetration test. Auditors and reviewers can tell — a scan report has no exploitation narrative and no scope statement — and being caught reframing one as the other damages credibility on everything else in the package.

Frequency: Your Policy Is the Requirement

Because the framework sets no interval, your own policy becomes the standard you are audited against. Write "annually and after significant change" and you will be asked for evidence of both, including what you classified as significant. Write "quarterly" and you have created four obligations a year.

Set the policy to something you will actually do. The most common self-inflicted audit finding in this area is a policy promising more testing than the team performed, which converts a strength into an exception in the report.

For teams deploying weekly, the sensible shape is a policy that names continuous automated testing plus a periodic deeper assessment. It is both more defensible and closer to how the risk actually behaves than an annual test that covers one day of a year of changes.

Scope: What Belongs Inside the Boundary

SOC 2 scope follows your system boundary, and testing scope should match it. That means the production application, the APIs, the infrastructure that supports them, and the administrative interfaces your staff use — internal admin tooling is inside the boundary and is routinely left out of testing, which is a gap an auditor may notice and an attacker certainly will.

Subservice organisations (your cloud provider, your payment processor) are handled through the carve-out or inclusive method rather than by testing them yourself. What remains yours is your configuration of them, which is testable and is where findings concentrate.

Evidence

What to hand your auditor

• ✓A test report covering the systems inside your SOC 2 boundary, dated within your policy interval
• ✓The scope statement: which applications, which environments, which roles were tested
• ✓Methodology description, so the auditor can see it was testing rather than scanning
• ✓Findings with severity ratings and business impact
• ✓Remediation status for every finding, including anything still open with an owner and a date
• ✓Retest evidence proving closed findings are actually closed and have not regressed
• ✓Your testing policy, and evidence you followed the interval it states
• ✓Your definition of "significant change" and the tests triggered by ones that occurred

Avoid

What costs teams an audit cycle

• ✕Writing a policy that promises more frequent testing than you will perform — the policy becomes the standard you are measured against.
• ✕Presenting a vulnerability scan as a penetration test. Reviewers can tell, and it costs you credibility on the rest of the package.
• ✕Leaving internal admin tooling out of scope when it sits inside the system boundary.
• ✕Testing once, twelve months before the audit, and having no evidence of the control operating during the review period.
• ✕Assuming your auditor accepts automated testing without asking, or assuming they demand manual testing without asking. Both assumptions are wrong roughly half the time.
• ✕Closing findings without a retest, so remediation is asserted rather than demonstrated.

FAQ

SOC 2 testing questions

Further reading

Produce the evidence continuously, not the week before the audit

Penetrify tests on every deploy from $100/month, with retests included — so the trail of what was found, fixed and verified builds itself.