SOC 2 penetration testing: what auditors actually expect

If you’re going through your first SOC 2, someone will bring up a penetration test early: your auditor, your compliance platform, or the security reviewer at the customer who asked for the SOC 2 in the first place. The confusing part is that the criteria you’re audited against never ask for one by name.

Not required, usually expected

Mike DeKock, a CPA whose firm issues SOC reports, puts the rule plainly¹:

The short version of the answer is “no” - there are no explicit requirements for penetration testing (or any controls) within a SOC 2 report.

That’s the rule on paper. In practice, the compliance platforms that prepare startups for audit describe a different normal. Secureframe writes that “almost all SOC 2 reports include them and many auditors require one.”² Vanta goes further: because SOC 2 asks you to identify vulnerabilities, “most auditors will require you to do a penetration test as part of the SOC 2 process.”³

Both are true because of how SOC 2 works. The AICPA sets criteria, you choose the controls that meet them, and your auditor decides whether the evidence is enough. That’s how a pentest ends up in the evidence folder even though no criterion makes it mandatory.

Where pentesting appears in the criteria

Two criteria point toward testing. The first is CC4.1, the monitoring criterion. Its 2022 points of focus list the kinds of evaluations management can use⁴:

Depending on the entity’s objectives, such risk and control evaluations may include first- and second-line monitoring and control testing, internal audit assessments, compliance assessments, resilience assessments, vulnerability scans, security assessment, penetration testing, and third-party assessments.

The second is CC7.1, which covers finding new vulnerabilities. Its point of focus on scanning describes scans “on a periodic basis and after significant changes are made to the environment,” with problems fixed “in a timely manner.”⁴

Points of focus are examples, not a checklist. Nothing fails because you skipped one. But a pentest report is the most direct thing an auditor can read for CC4.1, and a scan or test schedule is what they look for under CC7.1. The full mapping is in which trust services criteria a pentest covers.

What auditors look for in the evidence

With no written requirement, expectations come from practice. The same five things come up across auditors and platforms:

• Timing. Vanta says most auditors or customers want a third-party test “at least once a year, if not twice a year,” and for SOC 2 the test “must be completed before the end of your SOC 2 observation period” to count.³
• An independent tester. Secureframe’s rule of thumb is a third-party test “with a reputable vendor at least annually,” with critical and high-risk findings resolved.²
• Scope. Software Secured says auditors generally expect the test to cover in-scope systems that handle customer data, including internet-facing applications, APIs, cloud infrastructure, authentication systems and admin interfaces.⁵
• Agreement up front. Alex Lauerman of the pentest firm TrustFoundry advises working “with your auditor to figure out the scope and make sure your approach is acceptable.”⁶
• Remediation. A report full of open critical findings invites questions. Keep the tickets that show what you fixed and the retest that shows it worked.

Customers often ask before the auditor does

Even when an auditor would accept scans alone, customers might not. DeKock says penetration testing “is the most common requirement we hear as the last component to close a deal with an enterprise customer (along with having a SOC 2 report).”¹ A commenter on Indie Hackers made the same point from the founder’s side: “buyers often want pen-test evidence even before the SOC 2 report exists.”⁷

And if a customer contract names a pentest, the question is settled. As DeKock puts it, if you have customer contracts requiring one, “then it’s required.”¹

A sensible plan for a first SOC 2

1. Ask your auditor on the first call what they expect: a manual test, an automated one, or scans plus remediation. Get the answer in writing.
2. Clean up your external attack surface first: exposed files, open database ports, weak TLS, forgotten subdomains. These are cheap to find and cheap to fix.
3. Get a test done inside the audit window, fix critical and high findings, and retest.
4. If your auditor or a customer needs testing behind your login or of your business logic, buy a manual pentest for that part.
5. Store the report, the tickets and the retest together. That bundle is the evidence.

Pentrail covers step 2 and the external half of step 3. For $20 per domain it runs a non-destructive external test (50 common ports on your own addresses, 80 sensitive paths such as .git and .env, open redirects, weak TLS ciphers, subdomain takeover, DNS zone transfer) and delivers a PDF with CVSS scores, the real request and response for each finding, and a SOC 2 control map, plus a letter of attestation. It doesn’t test behind your login, your business logic or your internal network. If your auditor requires that, a manual tester still has to do it, and the report gives them a list of where to start.