SOC 2

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 short answer

SOC 2 does not name penetration testing as a requirement. The Trust Services Criteria require controls over logical access and monitoring, and auditors commonly accept penetration testing results as evidence for them. Ask your auditor whether they require human-led testing specifically.

Is a pentest mandatory?
No. The criteria are outcome-based; testing is the usual evidence, not a named control.
Criteria it maps to
CC6.x (logical and physical access), CC7.x (system operations and monitoring)
Typical frequency
Annually, plus after significant change. Set by your own policy, not by the framework.
Type I vs Type II
Type I is design at a point in time; Type II tests operating effectiveness over a period, usually 3-12 months.
Who decides what counts
Your auditor, within professional standards. Get the answer in writing before you buy testing.
What reviewers ask for
Scope, methodology, findings by severity, remediation status, retest evidence.

The requirements

What the SOC 2 text actually says

CC6.1

The entity implements logical access security software, infrastructure and architectures over protected information assets to protect them from security events.

In practice: Authentication and authorisation have to work, and you need evidence that they do. Penetration testing results are the most common way teams demonstrate it, because a policy document cannot show that access control holds under attack.

CC6.6

The entity implements logical access security measures to protect against threats from sources outside its system boundaries.

In practice: External-facing surface needs protecting and testing. This is where external penetration testing and attack surface monitoring fit most naturally.

CC6.8

The entity implements controls to prevent or detect and act upon the introduction of unauthorised or malicious software.

In practice: Dependency and image scanning, plus pipeline controls over what can be introduced into a build.

CC7.1

The entity uses detection and monitoring procedures to identify changes to configurations and susceptibilities to newly discovered vulnerabilities.

In practice: Vulnerability management as a running process rather than an annual event. Continuous scanning and testing evidence maps here directly.

CC7.2 / CC7.3

The entity monitors system components for anomalies and evaluates security events to determine whether they represent incidents.

In practice: Logging, alerting and a triage process. Testing intersects here when a test surfaces something your monitoring should have caught and did not.

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

Does SOC 2 require a penetration test?

No. The Trust Services Criteria describe control objectives and do not name penetration testing. Auditors commonly accept testing results as evidence for the access-control and monitoring criteria, and enterprise customers frequently ask for a report regardless, so most companies do one.

How often do we need to test for SOC 2?

The framework sets no interval, so your own policy does. Most companies write "annually and after significant change", and are then audited against exactly that — including their definition of significant. Set it to something you will actually perform.

Will an automated penetration test satisfy our SOC 2 auditor?

Often yes, particularly when it runs continuously and produces a retest trail showing findings closed over the review period, which is what a Type II examines. Some firms require human-led testing by a named third party. Ask before you buy: the cost difference is large.

What is the difference between Type I and Type II for testing?

Type I assesses whether controls are suitably designed at a point in time; Type II tests whether they operated effectively over a period, typically three to twelve months. For testing evidence that means Type II wants a history, not a single report — which favours continuous testing with a documented trail.

Do we need to test our cloud provider?

No. Subservice organisations are handled through the carve-out or inclusive method, using their own reports. What is yours to test is your configuration of them — IAM, storage permissions, network exposure — and that is where findings concentrate.

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.

Start free scan