Do I Need a Penetration Test to Get SOC 2 Certified?

This question comes up in almost every first conversation we have with a company starting their SOC 2 journey. The short answer: technically no, but practically yes. SOC 2 does not contain a line item that says “you must run a penetration test.” What it does require is evidence that your security controls actually work under real conditions. In our experience supporting SOC 2 clients at Bugstrix, every single one of them has needed a penetration test before their auditor would sign off.

That gap between what the framework technically says and what auditors actually expect is where a lot of confusion and wasted time happens. Companies sometimes find this out midway through their audit, when their auditor asks for testing evidence that doesn’t exist yet, and the timeline suddenly gets a lot tighter. This post answers the question directly, explains why the gap exists, and walks through exactly when you need a penetration test, what kind, and how to fit it into your audit timeline without a last-minute scramble.

Key Takeaways

SOC 2 does not explicitly require penetration testing in its written criteria, but every Bugstrix client pursuing certification has needed one before their auditor approved the report.
The requirement that effectively mandates testing is CC4.1, which calls for ongoing evaluation that controls are present and functioning, and auditors treat a penetration test as the standard evidence for this.
In our engagements, a vulnerability scan alone has never satisfied a SOC 2 auditor’s expectations once they understand the difference between scanning and manual testing.
Type II audits, which most enterprise customers require, need the test to fall within the audit observation period, not just sometime in the past year.
Companies that schedule their penetration test with at least six to eight weeks of lead time before their audit consistently avoid the remediation timeline pressure that causes delays.

Does SOC 2 Officially Require a Penetration Test?

No, SOC 2 does not officially require a penetration test as a named line item anywhere in its written Trust Services Criteria. What it requires is evidence that your security controls are designed appropriately and operating effectively. Auditors have settled on penetration testing as the most reliable way to demonstrate that in practice.

The criterion most directly responsible for this expectation is CC4.1, which falls under the Monitoring Activities category of the Trust Services Criteria. It requires organizations to select, develop, and perform ongoing or separate evaluations to confirm whether internal controls are present and functioning as intended. The criterion does not say “penetration test.” It says you need to evaluate whether your controls actually work, and a scoped, third-party penetration test is the evidence auditors consistently accept for that evaluation.

In every SOC 2 engagement we have supported at Bugstrix, the auditor has either explicitly requested a penetration test as part of the evidence package or made clear that, without one, additional alternative evidence would be needed, which is, in practice, harder to produce and less convincing than a straightforward test report. We have not seen an auditor accept a SOC 2 report without some form of independent security testing in the file.

So the honest framing is this: SOC 2 is outcomes-based, meaning it tells you what to prove rather than exactly how to prove it. But the path of least resistance, and the path every company we have worked with has ultimately taken, runs through a penetration test.

Why Do Auditors Expect a Penetration Test If It’s Not Officially Required?

Auditors expect a penetration test because it is the most efficient and credible way to satisfy multiple Trust Services Criteria simultaneously, and because alternative forms of evidence are harder to produce convincingly. A penetration test report with documented findings and remediation evidence answers several auditor questions at once, which is exactly why it has become the de facto standard even without being named explicitly in the framework.

A single, well-structured penetration test addresses CC4.1 directly. It also supports CC6.1, which requires demonstrating that logical access controls actually restrict unauthorized access. It supports CC7.1, which requires evidence that vulnerabilities are detected and remediated. And it supports CC9.2, which requires showing that identified risks are mitigated to an acceptable level. Across our engagements, this overlap is exactly why we structure SOC 2 penetration tests with a criteria mapping table built into the report from the start, so the same evidence does the work it needs to do across all four areas without requiring separate documentation for each.

The alternative to a penetration test, in theory, would be some other form of independent control evaluation. In practice, we have not encountered an alternative that an auditor found convincing. A penetration test produces concrete evidence: a specific vulnerability was identified, it was confirmed exploitable, it was remediated, and the remediation was verified through a retest. That chain of evidence is difficult to replicate through any other single activity, which is why auditors keep coming back to it as their preferred form of proof.

What Happens If You Try to Get SOC 2 Certified Without a Penetration Test?

If you attempt to get SOC 2 certified without a penetration test, the most likely outcome is that your auditor requests one mid-audit, which introduces a delay you did not plan for and forces remediation work to happen under deadline pressure rather than on a comfortable timeline. In the engagements we have supported, this is the single most common reason a SOC 2 timeline slips from the original plan.

The sequence typically plays out the same way. A company completes most of its audit preparation, believing its written policies and access controls are sufficient evidence. The auditor reviews the evidence package and identifies the gap, specifically the absence of independent testing evidence supporting CC4.1. At that point, the company needs to commission a penetration test, wait for it to be scheduled and completed, review the findings, remediate anything critical, and arrange a retest, all while the audit clock is still running.

This is a worse position than simply scheduling the test from the outset, for one specific reason: there is no longer time to address findings comfortably. A critical authorization vulnerability discovered with eight weeks of runway before the audit is a manageable remediation task. The same finding discovered with two weeks of runway, because the test was an afterthought, creates real pressure on both the security team and the audit timeline. In our experience, this is exactly the scenario that causes companies to either delay their audit or submit a report with unresolved findings, neither of which is a good outcome.

There is also a more direct consequence in some cases. If an auditor cannot get comfortable with the evidence on file, they may issue a qualified opinion or decline to issue the report at all until the gap is closed. For a company whose enterprise sales pipeline is waiting on that SOC 2 report, either outcome is costly in a way that has nothing to do with the cost of the penetration test itself.

Does the Type of SOC 2 Audit Change Whether You Need a Penetration Test?

Yes, the type of SOC 2 audit changes both how critical the penetration test is and when it needs to happen. Type I audits assess whether your controls are suitably designed at a single point in time. In contrast, Type II audits assess whether those controls operated effectively over an extended observation period, and that distinction directly affects the timing requirements for your testing.

For a Type I audit, a penetration test conducted reasonably close to the audit date is generally sufficient, because Type I is a point-in-time assessment rather than an evaluation of sustained performance. We still recommend it for every Type I engagement we support, because most companies pursuing Type I are using it as a stepping stone toward Type II, and starting the testing habit early makes that transition smoother.

For a Type II audit, which is what the overwhelming majority of enterprise customers actually require before signing a contract, the timing requirement is stricter. The observation period typically runs six to twelve months, and the penetration test needs to fall within that window, not just sometime in the past calendar year. More importantly, any findings need to be remediated and retested before the observation period closes, since auditors are evaluating whether your controls operated effectively throughout the period, not whether they were eventually fixed afterward.

In our experience, the companies that handle Type II testing well schedule the penetration test early in their observation period rather than near the end. That gives enough runway to remediate findings and complete a retest. At the same time, the observation window is still open, which produces a much cleaner audit story than discovering critical findings in the final weeks with no time to address them properly.

What Kind of Penetration Test Does a SOC 2 Audit Actually Need?

A SOC 2 audit needs a penetration test that covers every system within your defined system boundary, conducted by a tester independent from the systems being tested, with findings mapped to the relevant Trust Services Criteria and supported by retest evidence confirming remediation. A test that misses any of these elements creates friction during the audit, even if the underlying technical work was solid.

This is where we see the most avoidable mistakes happen. A company will commission a penetration test that is technically excellent but scoped around only part of their actual system boundary, for example, testing the production web application but leaving out a recently added API or a third-party integration that is technically within scope for the audit. The auditor will notice the gap, and closing it after the fact takes far longer than scoping it correctly from the start.

There is also a meaningful difference between a vulnerability scan and a genuine penetration test that matters specifically for SOC 2 purposes. In every engagement at Bugstrix where a client initially believed a scan would be sufficient, the auditor, once they understood the testing was automated scanning rather than manual, human-validated testing, asked for a real penetration test. Authorization failures, business logic flaws, and access control bypasses are consistently the findings that matter most for SOC 2’s relevant criteria, and these are also the findings that automated scanners are structurally unable to identify. A scan and a manual test produce fundamentally different evidence, and only one of them holds up under auditor scrutiny.

Our penetration testing services are structured specifically around producing SOC 2-ready evidence from the start, including the criteria mapping and retest documentation that auditors expect to see. For companies whose core product is a web application, which describes most SaaS companies pursuing SOC 2, our web app penetration testing services cover the specific authorization and access control testing that maps most directly to the criteria SOC 2 auditors care about most.

A related confusion worth clearing up is the difference between a penetration test and a security audit itself, since SOC 2 is technically the audit, and the penetration test is one piece of evidence feeding into it. People often use the two terms interchangeably, but they are not the same activity, and conflating them is part of why some companies assume their audit alone will cover what a penetration test is specifically meant to prove. Our post on the difference between penetration testing and security audits breaks down exactly how the two relate, which is useful context for understanding why SOC 2, as an audit, still needs a separate penetration test to produce the evidence it’s actually asking for.

When Should You Schedule Your Penetration Test Relative to Your Audit?

You should schedule your penetration test at least six to eight weeks before your audit date, and ideally early within your Type II observation period rather than near its end. This window provides enough time to receive the report, remediate any critical or high-severity findings, and complete a documented retest before the auditor’s review begins.

In the engagements we have run at Bugstrix, the companies that schedule with this much lead time almost never experience audit delays related to penetration testing. The companies that schedule closer to their audit date, typically within two to three weeks, are the ones most likely to discover a finding that requires remediation under real-time pressure, sometimes pushing the audit itself back.

A practical timeline that has worked consistently for our SOC 2 clients: testing takes one to three weeks depending on scope, remediation of critical and high findings typically takes two to four weeks depending on the complexity of the fix, and the retest confirming remediation takes about a week. Add buffer time for scheduling and report review, and the full six to eight week window becomes the realistic minimum rather than a conservative estimate.

Get a free quote for your SOC 2 penetration test

Frequently Asked Questions

Is penetration testing legally required for SOC 2?

No, there is no legal requirement, and SOC 2’s written Trust Services Criteria never use the words “penetration test.” What is required is evidence that your security controls function effectively, and in practice, every SOC 2 engagement Bugstrix has supported has needed a penetration test for the auditor to accept that evidence. The honest answer is that it is not legally mandated but is effectively required in nearly every real-world audit.

Can I use an automated vulnerability scan instead of a penetration test for SOC 2?

In our experience, no. Once an auditor understands that a scan is an automated tool output rather than a manual, human-validated test, they request a genuine penetration test instead. The findings that matter most for SOC 2’s relevant criteria, particularly authorization failures and access control gaps, are exactly the category of findings that automated scanners are not designed to catch.

How long before my SOC 2 audit should I schedule a penetration test?

At least six to eight weeks before your audit date. This allows time for testing, remediation of any critical or high-severity findings, and a documented retest confirming those fixes actually worked, all before the auditor’s review begins. Companies that schedule closer to their audit date consistently run into avoidable delays in our experience.

Does a penetration test need to cover my entire SOC 2 system boundary?

Yes. The test scope needs to match the system boundary defined for your audit exactly. Leaving out an application, API, or third-party integration that falls within your defined boundary creates an evidence gap that an auditor will identify, and closing that gap after the fact takes considerably longer than scoping the engagement correctly from the beginning.

What if my auditor finds out I haven’t done a penetration test partway through the audit?

This is the most common scenario that causes SOC 2 timelines to slip, in our experience. The auditor will request testing evidence; you commission a test, and remediation now has to happen under audit deadline pressure rather than on a comfortable schedule. It is a recoverable situation, but it almost always costs more time than scheduling the test from the start of your audit preparation.

The Practical Answer

If you are asking whether you technically need a penetration test to get SOC 2 certified, the literal answer is no; the framework does not say so explicitly. If you are asking whether you will actually get certified without one, based on what every company we have supported through this process has experienced, the answer is effectively yes, you need it.

The smarter way to approach the question is not whether you need a penetration test, but when to schedule it and how to make sure it produces evidence your auditor will actually accept. Companies that build it into their audit preparation from day one, with enough lead time to remediate and retest, move through SOC 2 certification with far less friction than companies that treat it as an afterthought; their auditor eventually has to flag.