Is penetration testing required for SOC 2?

No. SOC 2 does not explicitly require a penetration test. The Trust Services Criteria that a SOC 2 examination is built on never use the words “penetration test.” What they do require is that you find and manage vulnerabilities, and in practice most auditors expect a penetration test as evidence that you actually do. So the honest answer is: not required by the letter, effectively expected by the people signing your report.

The short version

SOC 2 is an attestation, not a checklist of tools. A licensed CPA firm forms an opinion on whether your controls meet the criteria you chose to be examined against. Nowhere in that process is there a line item that says “run a penetration test.” There is also no line item that says “use a firewall” or “encrypt backups.” The criteria describe outcomes, and you show the auditor how you reach them.

That design is why the question keeps coming up. Because nothing is named, teams reasonably ask whether a penetration test is mandatory, optional, or a waste of budget. The practical reality sits between the first two: it is the cleanest way to satisfy a control that every Security-scoped SOC 2 report has to address, and auditors have come to treat it as the default evidence.

What SOC 2 actually asks for

A SOC 2 report covers controls at a service organization that are, in the AICPA’s words, “relevant to security, availability, processing integrity, confidentiality, or privacy”. Those are the five trust services categories, and only the first is mandatory. Security, also called the common criteria, is included in every SOC 2 examination. The other four are added only if they matter to your service and your customers.

Inside the common criteria sits the control that drives the whole pentest question. CC7.1 asks the organization to use detection and monitoring procedures to identify both new vulnerabilities introduced by configuration changes and susceptibility to newly discovered vulnerabilities. Its points of focus name vulnerability scans run on a periodic basis and after significant changes. The text describes the outcome, finding your weaknesses before someone else does, and leaves the method to you and your auditor.

Where a penetration test fits

This is where the difference between a scan and a test starts to matter, and it is a real difference, not a marketing one. NIST draws the line cleanly. A vulnerability scan is an automated process that flags potential weaknesses. A penetration test is a hands-on exercise where, in NIST’s definition, “assessors mimic real-world attacks to identify methods for circumventing the security features of an application, system, or network”. NIST SP 800-115 splits that work into four phases: planning, discovery, attack, and reporting. The attack phase is the part a scanner cannot do, it verifies a suspected vulnerability by trying to exploit it.

For SOC 2, the two are complementary rather than interchangeable. A scan gives you breadth and frequency: it runs often and covers everything cheaply, which is exactly what CC7.1’s “periodic basis” language asks for. A penetration test gives you depth and proof: it confirms which of those findings an attacker could actually chain into access. Auditors like seeing both because together they answer the question the criteria really pose, which is not “do you own a scanner” but “do you actively look for, and act on, the ways your system can be broken.” If you want the full breakdown of how the two methods diverge, we wrote a vulnerability scanning vs penetration testing guide on exactly that.

So a penetration test is not strictly required by the standard. It is, however, the most defensible single piece of evidence you can hand an auditor for the vulnerability-identification controls, and skipping it tends to invite questions you would rather not field during fieldwork.

How often, and what to test

Once you accept that a test is effectively expected, two practical questions follow: how often, and over what scope.

On cadence, an annual penetration test is the common baseline, with an additional test after any significant change to the in-scope system. The reason is partly the criteria’s “after significant change” language and partly timing. A SOC 2 Type II report examines whether controls operated effectively over a period rather than on a single day, so the test, and any remediation that follows, needs to fall inside that observation window to count as evidence for the period.

On scope, the test should cover the system described in your SOC 2 boundary: the production application, the infrastructure that supports it, and the externally reachable surface that an attacker would actually meet. Testing a marketing site that sits outside the boundary proves nothing about the controls under examination. A test scoped to the wrong assets is worse than no test, because it costs money and still leaves the gap an auditor will find.

Two more details decide whether the test helps or hurts on report day. First, remediation. A report full of open findings with no evidence of fixes reads as a control that is not operating. The pattern auditors expect is find, fix, and retest, with the retest attestation in the file. Second, independence. The value of the exercise comes from someone who did not build the system trying to break it, which is the spirit of NIST’s planning-phase emphasis on a written scope and rules of engagement agreed before testing starts.

Type I versus Type II changes the timing

The two SOC 2 report types treat your penetration test differently, and it is worth knowing which you are pursuing before you schedule one.

A Type I report assesses whether your controls are designed appropriately at a single point in time. For that, a recent penetration test and a documented plan to act on its findings can be enough to show the control exists and is sound by design.

A Type II report goes further and tests whether those controls operated effectively across a period of months. Here a single point-in-time test is necessary but not sufficient on its own: the auditor wants to see that vulnerability identification ran throughout the window, which usually means the pentest plus the ongoing scanning and remediation activity that surrounds it. Plan the test early enough that the findings can be remediated and retested before the observation period closes, not in the final week.

Quick answers

Does SOC 2 explicitly require a penetration test? No. The Trust Services Criteria never use the phrase. They require you to identify and manage vulnerabilities, and a penetration test is the evidence most auditors expect for that control.

Is a vulnerability scan enough on its own? Sometimes for the letter of CC7.1, rarely for the auditor’s comfort. A scan satisfies the “periodic” language, but it cannot confirm exploitability the way a test’s attack phase does. Most teams do both.

How often do I need to test for SOC 2? Annually is the common baseline, plus a test after any significant change to the in-scope system. For a Type II report, make sure the test sits inside the observation period.

Who can perform the test? Anyone with the relevant skills, but the value comes from independence. A tester who did not build the system, working to a written scope and rules of engagement agreed in advance, produces evidence an auditor can rely on.

What does the auditor actually want to see? A test scoped to the in-scope system, performed within the period, with findings that were remediated and retested. The report is evidence; the closed findings are the control working.

Does a clean penetration test guarantee I pass SOC 2? No. The pentest covers one family of controls. SOC 2 also examines access management, change management, monitoring, and more. A strong test removes one common source of audit friction; it does not stand in for the rest.