SOC 2 Penetration Testing Requirements: What Auditors Actually Expect

SOC 2 never spells out its penetration testing requirements as a literal checklist item. The Trust Services Criteria set by the American Institute of CPAs (AICPA) never demand one explicitly. Yet in practice, most auditors treat a documented penetration test as close to compulsory. That is especially true for a Type II report. There is no other credible way to prove your controls actually hold up against an attacker. If you are preparing for an audit and wondering whether you can skip it, the honest answer is simple. You can, but almost nobody does, and your auditor will ask why.

What the SOC 2 Penetration Testing Requirements Actually Say

Formally, no. SOC 2 is built around five Trust Services Criteria: security, availability, processing integrity, confidentiality and privacy. None of them list specific technical tests. Instead, the framework asks you to design and run controls that meet each criterion, then leaves the method up to you.

The catch sits in Criterion CC4.1, part of the Monitoring Activities section. It calls for “ongoing and/or separate evaluations to ascertain whether the components of internal control are present and functioning.” Vulnerability scans, security assessments and penetration tests are all offered as ways to satisfy that. A penetration test is the one auditors trust most, though, because it shows a real attempt to exploit a weakness rather than just flag one.

So while the standard stays silent on paper, the practical SOC 2 penetration testing requirements are set elsewhere. Your auditor and your customers decide what counts as adequate evidence. For most SaaS and technology companies handling customer data, that expectation has hardened into a near-universal norm.

Type I vs Type II Changes What You Need to Show

A SOC 2 Type I report checks whether your controls are designed correctly on a single date. A Type II report goes further. It checks whether those controls actually operated effectively across an observation period, typically three to twelve months. Six months is common for a first audit; twelve months is standard for renewals.

That distinction matters because a Type I audit can sometimes pass on documentation and policy alone. A Type II audit cannot. Auditors want proof the test happened inside the observation window, not a stale report from eighteen months ago pulled out to tick a box. If your penetration test predates the window, expect the auditor to ask for a fresh one before they sign off.

How Often Should You Test?

Annual testing is the accepted floor. Most auditors expect a full penetration test at least once a year, covering every system in scope for the audit. Automated vulnerability scanning should run more frequently, often quarterly, to catch new issues between the bigger tests.

Trigger events push that baseline higher. A major infrastructure change, a new product launch, a significant code rewrite or a security incident should all prompt an additional test rather than waiting for the calendar. An auditor who spots a large architectural change with no corresponding test is likely to flag it as a gap in your monitoring controls.

What Scope Should the Test Cover?

Auditors expect coverage that matches what is actually in your SOC 2 boundary, not a token scan of one server. That usually means:

• Internet-facing infrastructure, tested through external network penetration testing.
• Internal systems and segmentation, particularly if the audit boundary includes staff or admin access to customer data.
• Any customer-facing web application, since this is usually where the highest volume of exploitable bugs sits.
• APIs that move customer data between services, a growing blind spot as SaaS products lean harder on integrations.
• Cloud infrastructure and configuration, where a single exposed storage bucket or overly permissive role can undo months of otherwise solid controls.

Scoping badly is one of the most common reasons a SOC 2 penetration test fails to satisfy an auditor. A test that only covers a marketing website is not much use if the real customer data lives in a separate cloud environment. It produces a report, but not evidence of anything the auditor cares about. Getting a properly scoped penetration test commissioned against your real SOC 2 boundary is worth the extra scoping conversation up front.

What Auditors Want to See in the Report

A pass mark is not just “no critical findings.” Auditors are checking that the test was real, current and acted upon. They typically look for:

• A defined scope and methodology, so they can see what was and was not tested.
• A test date that falls within the observation period for a Type II report.
• Evidence the tester used manual techniques, not only an automated scanner with a rebranded PDF.
• A remediation record showing findings were fixed, retested, or formally accepted as risk.
• Tester credentials or accreditation, since an unaccredited or anonymous report carries less weight.

That last point trips up a surprising number of companies. Choosing the cheapest available tester on the assumption that any report will do is a false economy. It often produces a report an auditor pushes back on, which then delays the whole audit while a proper test gets commissioned. It is usually faster and cheaper overall to book a credible tester the first time.

Frequently Asked Questions

Can I use a vulnerability scan instead of a penetration test for SOC 2?
A scan is useful and often expected quarterly, but it only flags known weaknesses automatically. It does not show whether those weaknesses are actually exploitable, which is the gap a manual penetration test closes. See our penetration testing vs vulnerability scanning comparison for the full breakdown. Most auditors treat the two as complementary, not interchangeable.

Does SOC 2 Type I need a penetration test?
It is less strictly enforced than for Type II, since Type I only checks control design at a point in time. Many companies still commission one anyway, both to catch real issues early and because it smooths the path to a Type II audit later.

Who can perform the penetration test?
SOC 2 does not mandate a specific accreditation, unlike some other frameworks. An independent, suitably qualified tester with no conflict of interest in your organisation is the general standard auditors apply.

Does the penetration test need to happen every year, even after a clean result?
Yes. A clean result last year says nothing about new code, new infrastructure or newly disclosed vulnerabilities this year. Annual testing, plus testing after major changes, is the expectation regardless of prior results.

What happens if the test finds critical vulnerabilities close to the audit date?
Flag it to your auditor early rather than hiding it. Auditors generally respond better to a documented finding with a remediation plan in progress than to a report that looks suspiciously clean. What damages an audit is an unaddressed critical finding, not the fact that one existed.

Getting the SOC 2 Penetration Testing Requirements Right Is Mostly About Timing

The most common mistake is leaving the test until just before the audit deadline. A serious issue found two weeks before your auditor arrives leaves no real time to fix it, retest it, and document the remediation properly. Booking the test early in the observation period, with room left for a retest, is what keeps a SOC 2 timeline realistic instead of a scramble.

If you are not sure how to scope an engagement against your specific audit boundary, getting advice before you book is a cheap step. It is far cheaper than redoing a test that missed the systems your auditor actually cares about. Aardwolf Security scopes SOC 2 engagements against the real audit boundary rather than a generic checklist. You can get in touch to talk through timing before your next observation period starts.