Is Penetration Testing Required for SOC 2? What Your Auditor Actually Wants to See

"Do we need a pen test before our SOC 2 audit?" is one of the first questions almost every company asks once they start scoping their engagement — and it's a fair question, because the honest answer isn't a simple yes or no. Search the actual Trust Services Criteria and you won't find the words "penetration test" written anywhere as a mandatory requirement. And yet the overwhelming majority of companies walking away with a clean SOC 2 audit report have one in their evidence folder. That contradiction is worth unpacking properly before you either skip something your auditor is quietly expecting or spend money on testing that's scoped wrong for what SOC 2 actually needs.

SOC 2 Is Outcome-Based, Not a Checklist — That's Where the Confusion Starts

Unlike a framework like PCI DSS, which spells out annual penetration testing as a hard, named requirement, SOC 2 was built around a different philosophy entirely. The AICPA's Trust Services Criteria describes outcomes your controls need to achieve — vulnerabilities get identified, unauthorized access gets prevented, security events get monitored — without dictating exactly how you get there. That's intentional. It gives your SOC 2 auditor room to apply professional judgment based on your specific environment, rather than forcing every company, from a five-person API startup to a thousand-person SaaS platform, through an identical checklist.

The tradeoff is that this flexibility creates exactly the confusion driving the question in the first place. Nothing in the framework technically mandates a pen test. But "technically not required" and "practically expected" turn out to be two very different things once you actually sit across from a SOC 2 auditor mid-engagement.

Why Auditors Ask for It Even Though the Criteria Doesn't Name It

Criteria like CC6.1 and CC6.8 require you to demonstrate that vulnerabilities in your environment are actively identified and addressed. An automated vulnerability scanner is a reasonable first layer of evidence — it flags outdated packages, missing patches, misconfigurations. What it generally doesn't do is prove those weaknesses are actually exploitable, or reveal the more dangerous class of issues that live in business logic: broken authorization checks, privilege escalation paths, ways to bypass authentication that no scanner would ever catch because they're not a known CVE, they're a design flaw.

A skilled SOC 2 auditor knows the difference between "we scan for vulnerabilities" and "we've actually tested whether someone could break in." For a SOC 2 Type 2 audit specifically — where the auditor is testing sustained operational effectiveness across a real observation period, not just a policy document — the absence of any penetration testing evidence tends to prompt follow-up questions rather than a quiet pass. Most experienced auditors will ask what compensating evidence exists if a formal pen test wasn't performed, and "we didn't think it was required" is rarely a satisfying answer on its own.

Situations Where a Company Can Reasonably Move Forward Without One

There are legitimate scenarios where a SOC 2 audit report gets issued cleanly without a dedicated penetration test:

Very early-stage companies with minimal external attack surface — a simple internal tool, no customer-facing application, limited exposure — where an auditor can reasonably conclude other controls sufficiently cover the relevant criteria.

A SOC 2 Type 1 report specifically, which evaluates whether controls are designed appropriately as of a single date rather than whether they operated effectively over months. The bar for proving ongoing vulnerability management is generally lower here than for a SOC 2 Type 2 report.

Scope boundaries that exclude testable systems entirely — if your audit scope genuinely doesn't include anything internet-facing, the case for a pen test weakens accordingly.

Even in these situations, this shouldn't be a decision made unilaterally and hoped for the best. Raise it directly with your SOC 2 auditor during scoping, before readiness work begins. Different audit firms weigh this differently, and finding out mid-fieldwork that your auditor expected a pen test you didn't budget for is a far more expensive surprise than a five-minute conversation upfront.

Scoping the Test So It Actually Counts as SOC 2 Evidence

Getting a penetration test done isn't automatically sufficient — the scope has to actually align with what your SOC 2 auditor is testing against. A few things matter here:

It needs to cover your application layer, not just infrastructure. Authentication logic, session handling, authorization boundaries, and input validation are where the interesting findings usually live, especially for SaaS products. A test that only pings your network perimeter and calls it done misses most of what an auditor wants to see addressed.

It should mirror your system description's boundaries. If your SOC 2 scope includes three products and the pen test only covers one, that mismatch is something your auditor will notice and ask about.

Internal risk deserves consideration too, where relevant. If a compromised laptop or an over-permissioned internal account could realistically reach sensitive systems, some auditors want evidence that lateral movement risk was assessed, not just external-facing exposure.

Timing the Test Within Your Audit Period

This is a detail that trips up a surprising number of first-time companies. For a SOC 2 Type 2 report, the observation period typically spans six to twelve months, and your auditor wants evidence that vulnerability management — including any penetration testing — actually happened within that window. A test run eighteen months earlier, before the current review period even started, doesn't tell your SOC 2 auditor anything meaningful about your current security posture.

Most companies going through an annual SOC 2 Type 2 audit build the pen test into their yearly cadence, scheduling it to land inside the current observation period so the evidence stays current relative to what's actually being tested — rather than treating it as a one-time box checked back when the company first pursued SOC 2 compliance and never revisited since.

Findings Aren't the Problem — an Unmanaged Response Is

A common source of anxiety: "what if the pen test finds something bad right before our audit?" Findings themselves aren't a red flag to a SOC 2 auditor — they're expected. Every real-world application has something a skilled tester can find. What actually matters is what happened next: was each finding triaged by severity, assigned an owner, remediated within a reasonable window, and re-verified as fixed.

Ironically, a pen test that comes back with zero findings sometimes draws more scrutiny than one with a handful of properly closed medium-severity issues, because a perfectly clean result on a live production application can suggest the testing wasn't rigorous enough rather than that nothing was there to find. Your SOC 2 reporting story is strengthened by a visible remediation trail, not undermined by having something to remediate in the first place.

Who Should Actually Perform the Test

Not every penetration test carries equal weight during a SOC 2 audit. A quick internal scan run by the engineer who built the feature being tested doesn't satisfy the same independence expectation your SOC 2 auditor is applying to the audit itself. Most auditors expect testing performed by a party genuinely independent of the team responsible for building and maintaining the system in question.

It's also worth confirming your testing vendor has produced reports before that are actually usable as SOC 2 evidence. A pen test report written for general internal security purposes doesn't always include what an auditor needs — findings clearly mapped to severity, documented remediation status, and a scope statement that lines up cleanly with your system description. Asking this question upfront saves a round of rework later.

Fitting Penetration Testing Into the Bigger SOC 2 Compliance Picture

A pen test on its own doesn't complete your story — it's one input supporting a broader claim your SOC 2 audit report is making, that your organization actively hunts for and manages security risk rather than assuming its controls are working. Paired with regular vulnerability scanning, defined patch management SLAs, and a documented incident response process, a properly scoped and correctly timed penetration test closes a gap that a sharp enterprise buyer's security team is very likely to ask about anyway, whether or not your auditor required it explicitly.

Where Accorp Fits In

Accorp Partners works with companies from the very start of scoping their SOC 2 audit — helping determine whether penetration testing is genuinely necessary for a specific engagement, making sure the scope actually satisfies what a SOC 2 auditor is looking for, and timing it correctly within the observation period so it holds up as current, credible evidence rather than a disconnected report sitting in a folder from a year ago.

Frequently Asked Questions

1. Does SOC 2 explicitly require penetration testing?

No. The Trust Services Criteria doesn't name it as a mandatory control, but most SOC 2 auditors expect to see it as supporting evidence for vulnerability management, particularly during a SOC 2 Type 2 audit.

2. How often should a pen test be conducted for ongoing SOC 2 compliance?

Annually is standard for most companies, timed to fall within the current observation period so the evidence reflects your actual current environment rather than an outdated snapshot.

3. Will pen test findings hurt my SOC 2 audit report?

Not if they're properly triaged and remediated. A documented remediation trail signals a mature security program more convincingly than a suspiciously clean, finding-free report.