Does SOC 2 require a penetration test? Not in so many words. The AICPA’s Trust Services Criteria, the framework a SOC 2 report is assessed against, never actually use the phrase “penetration test”. But in practice, auditors expect one, and going without makes for a harder audit and a tougher conversation with enterprise customers. So while a pen test isn’t technically mandatory, the honest answer is that most organisations treat it as required, because their auditor effectively does too.

If you’re a UK SaaS or technology business, this matters more than it might first appear. SOC 2 is a US-originated standard, but it’s become one of the most common things American and enterprise customers ask UK suppliers for. Understanding what your auditor genuinely expects, rather than what a checklist says, is the difference between a clean report and one littered with exceptions.

Why penetration testing is expected, even though it isn’t named

SOC 2 isn’t a tick-box list. It’s a framework built on a set of criteria, and your auditor’s job is to judge whether your controls meet them and, for a Type II report, whether they’ve worked over time. Penetration testing has become the standard, audit-accepted way to produce evidence for several of those criteria.

Two in particular do the heavy lifting:

Monitoring activities. This criterion expects you to carry out ongoing and separate evaluations to check that your controls are actually present and working. Crucially, the framework’s own guidance names penetration testing directly as one of the accepted ways to do this, alongside things like independent certifications and internal audits. That single detail is why auditors take the absence of a pen test as a red flag: the standard itself points at testing as evidence.

System operations and vulnerability identification. This criterion expects you to detect weaknesses, both new vulnerabilities introduced by changes to your systems and newly discovered ones in software you already run. Vulnerability scanning helps here, but a penetration test demonstrates something a scan can’t: that your defences hold up when someone actively tries to get through them.

Testing can support other criteria too, such as the ones covering access controls and anomaly detection, by proving that your restrictions genuinely keep unauthorised people out rather than just looking correct on paper.

The through-line is simple. Your controls can be beautifully documented and still not work. A penetration test is how you show they work in the real world, which is exactly what an auditor is trying to establish.

Type I versus Type II: why the difference changes your testing

SOC 2 comes in two forms, and they treat testing slightly differently.

A Type I report assesses whether your controls are suitably designed at a single point in time. Because the auditor is only judging design, not operation, a penetration test is genuinely useful but not strictly essential. It strengthens the picture without being the make-or-break piece of evidence.

A Type II report is the one most enterprise customers actually want, and it’s a different proposition. It assesses whether your controls operated effectively across a period, typically somewhere between three and twelve months. Here, auditors expect to see testing carried out within that observation window, and for a longer period they’ll want evidence that you test regularly rather than once. Just as importantly, they’ll look for proof that you acted on what the test found. A report full of unaddressed findings is often worse than no report at all.

What auditors actually want to see

If you strip it back, auditors are looking for a small number of specific things. Get these right and your pen test does its job in the audit.

Independent, human-led testing: Auditors want a test performed by qualified people who probe your systems the way an attacker would, not an automated scan wearing a pen test label, and not an AI-only tool spitting out a vulnerability list. The value is in the human judgement: the business-logic flaws, the chained attacks and the real-world context a scanner simply can’t provide. Recognised credentials, such as CREST accreditation, give the auditor confidence in who did the work.

Scope that matches your system boundary: Your test should cover the systems inside your SOC 2 scope: your production environment, customer-facing applications, APIs and the supporting infrastructure that processes, stores or transmits customer data. Auditors will compare your pen test scope against your SOC 2 system description, and a mismatch is an easy way to pick up an observation.

Timing within your audit period: For a Type II report, a test carried out before or after the observation window doesn’t count as evidence for that period. The practical move is to schedule testing early in the window, so the evidence is current and you’ve still got time to fix and retest anything it uncovers before the period closes.

A report mapped to the criteria: The most useful pen test reports don’t just list findings, they show which controls were validated and connect the work back to the relevant criteria. That makes your auditor’s job easier and speeds the whole engagement up.

Evidence of remediation: This is the one businesses most often underestimate. Finding issues isn’t enough. Auditors want to see that you triaged them, fixed the important ones, and ideally retested to confirm the fix held. Showing a report alongside clear remediation and retest evidence is what turns a test into clean audit evidence.

A repeatable process: A single test looks like a one-off. Testing on a regular cadence, and after significant changes such as a major release or a new integration, shows an ongoing programme, which is precisely what the monitoring criterion is asking for.

Common mistakes that cause audit exceptions

Most SOC 2 testing problems come down to a handful of avoidable errors:

• Relying on a vulnerability scan instead of a penetration test. They’re complementary, not interchangeable, and a scan alone rarely satisfies an auditor looking for evidence that controls work. (We’ve explained the difference in full in our guide to vulnerability scanning versus penetration testing.)
• Testing outside the audit period, so the evidence doesn’t apply to the window under review.
• Scoping too narrowly, leaving in-scope systems untested and creating a gap the auditor will spot.
• Doing the test but not the remediation, and having nothing to show for the findings.
• Using an unqualified or purely internal tester, which undermines the independence auditors are looking for.

How to get SOC 2 penetration testing right

Pulling it together, a strong approach looks like this:

Scope the test to mirror your SOC 2 system description, so there are no gaps between what you claim and what you tested. Book it early in your observation period, giving you room to remediate and retest before the window closes. Choose a qualified, independent tester who can produce auditor-ready reporting mapped to the criteria. Then track your findings through to resolution, fix what matters, and get the fixes retested.

There’s a useful bonus in doing this well. The same testing and the same report can support your other obligations too. Penetration testing that satisfies your SOC 2 auditor will also help with ISO 27001, strengthen a cyber insurance application, and answer the security questionnaires enterprise prospects send you. One piece of work, several requirements covered.