SOC 2 Penetration Testing Requirements: What You Actually Need to Know

You're not wrong to be confused. The SOC 2 framework is deliberately flexible, which is great for tailoring controls to your environment but terrible for getting a straight answer. And when the stakes are a delayed audit, a qualified opinion, or a lost enterprise deal, "it depends" isn't the kind of guidance that helps you sleep at night.

Here's the truth: penetration testing is not technically required by SOC 2. But in 2026, walking into your audit without one is a gamble that most organizations can't afford to take. Let's break down exactly what the framework says, what auditors actually expect, and how to scope a penetration test that strengthens your security posture and satisfies your assessor.

---

A Quick Primer on SOC 2

Before we talk penetration testing, it helps to understand what SOC 2 actually is—and what it is not.

SOC 2 was developed by the American Institute of Certified Public Accountants (AICPA). Unlike prescriptive compliance standards like PCI DSS, which spell out specific technical controls you must implement, SOC 2 is outcomes-based. It defines criteria your controls must meet but gives you significant flexibility in how you get there.

The framework evaluates organizations against five Trust Services Criteria (TSC):

Security (also called Common Criteria) is mandatory for every SOC 2 audit. It covers access controls, risk assessments, change management, incident response, and protection against unauthorized access. The remaining four—Availability, Processing Integrity, Confidentiality, and Privacy—are optional and selected based on the services you provide and the commitments you make to customers.

There are two types of SOC 2 reports. A Type I audit evaluates the design of your controls at a single point in time. A Type II audit examines both the design and the operating effectiveness of those controls over a period, typically six to twelve months. Type II is what most enterprise buyers and partners require, and it's where penetration testing becomes especially significant.

So, Does SOC 2 Require Penetration Testing?

The short answer is no. The word "penetration testing" does not appear in any SOC 2 requirement as a mandatory activity. The AICPA's Trust Services Criteria provides guidelines but allows organizations flexibility in demonstrating that their security controls are present and functioning.

But here's where the nuance lives.

The criteria that matter most in this conversation fall under the Monitoring Activities category, specifically Common Criteria 4.1 (CC4.1). It states:

Read that carefully. The framework is asking you to prove—actively prove—that your controls work. Not just that they exist in a policy document. Not just that someone signed off on a checklist. It wants evidence that someone tested whether those controls hold up under pressure.

And in the points of focus accompanying CC4.1, the AICPA explicitly references penetration testing as one method for performing these evaluations. It also mentions independent certifications and internal audit assessments. But penetration testing is named directly, and auditors take note.

Beyond CC4.1, penetration testing can also support several other criteria:

CC6.1 focuses on logical and physical access controls. A pentest can validate whether your access restrictions actually prevent unauthorized entry into systems that store or process sensitive data.

CC7.1 requires you to monitor your systems for anomalies that could indicate security events. Active testing of your defenses helps demonstrate that your monitoring and detection capabilities actually catch malicious behavior.

A1.2, relevant if Availability is in scope, addresses the design and maintenance of environmental protections, software, and recovery infrastructure. A penetration test that includes availability-focused scenarios can provide evidence here as well.

None of these criteria mandate a pentest. But each one is significantly easier to satisfy—and significantly more convincing to an auditor—when you can point to real-world testing results.

What Auditors Actually Expect in 2026

Here's where theory meets reality.

Auditors in 2026 overwhelmingly expect to see penetration testing evidence as part of a SOC 2 engagement. This is especially true for Type II audits, where they need to assess whether your controls functioned effectively over time. A penetration test provides tangible proof that someone attempted to bypass your controls and documented what they found.

Several experienced auditors have described the dynamic this way: they're not just reviewing policy documents and configuration screenshots. They want to see that your organization proactively sought out weaknesses by simulating the kinds of attacks a real adversary would attempt. A clean pentest report, complete with scope documentation, methodology, findings, and evidence of remediation, is one of the strongest pieces of evidence you can hand to an assessor.

The practical reality is that if you show up without a penetration test, your auditor will almost certainly ask about it. You might be able to satisfy CC4.1 through other means—internal audit assessments, third-party certifications, or continuous monitoring data—but you'll need to make a convincing case. And for many organizations, especially SaaS companies handling customer data, a pentest is the path of least resistance and the highest signal to the auditor.

Think of it like building codes for a house. The inspector doesn't just want to see the blueprint—they want to see that someone stress-tested the foundation.

Scoping Your Pentest for SOC 2

If you're going to invest in a penetration test for your SOC 2 audit (and you should), the single most important thing is getting the scope right. An impressive-looking pentest that doesn't align with your SOC 2 system boundary is, from an audit perspective, close to useless.

Match Your System Description

Your SOC 2 report includes a system description that defines the boundaries of your audit—the infrastructure, applications, data flows, and services that are in scope. Your penetration test must cover the same ground.

If your system description references a customer-facing API, a web application, and a cloud-hosted database, your pentest scope needs to include all three. If the pentest covers only the web application while ignoring the API, that's a scope gap your auditor will flag.

Before engaging a testing provider, share your draft system description with them. A good provider will map the pentest scope directly to your SOC 2 boundary and note any areas of overlap or gaps.

Cover All Attack Surfaces

A well-scoped SOC 2 pentest typically includes several components:

External network testing examines your internet-facing infrastructure—web servers, mail servers, VPN endpoints, APIs, and anything else exposed to the public internet. This simulates what an outside attacker would encounter when trying to breach your perimeter.

Internal network testing simulates a scenario where an attacker has already gained a foothold inside your network, perhaps through phishing or a compromised endpoint. It evaluates whether your internal segmentation, access controls, and detection mechanisms prevent lateral movement toward sensitive systems.

Web application testing focuses on the custom applications your organization builds and maintains, especially those that handle customer data. Testers look for common vulnerabilities like injection flaws, broken authentication, insecure API endpoints, and business logic errors that automated scanners typically miss.

Cloud environment testing is essential if your infrastructure runs on AWS, Azure, or GCP. Testers assess IAM configurations, storage permissions, network security groups, and service-specific misconfigurations. The shared responsibility model means your cloud provider secures the underlying platform, but you're on the hook for everything you build on top of it.

Depending on your environment, you might also include wireless testing, social engineering assessments, or mobile application testing. The key is that every component in your system description has corresponding coverage in your pentest.

Timing Matters

For Type II audits, the timing of your penetration test can make or break its value as evidence. Ideally, your pentest should occur within the audit observation period or very close to it. A test conducted 14 months before the audit period ends tells the auditor very little about the current effectiveness of your controls.

Many organizations schedule their pentest in the first half of the audit period. This gives them time to receive the report, remediate any findings, conduct retesting, and still have the results fall within the observation window. If you're going through your first SOC 2 Type I, timing is more flexible since the audit is a point-in-time snapshot—but it should still be recent.

Common Mistakes That Derail Audits

Even organizations that invest in penetration testing can stumble on execution. Here are the mistakes that most commonly cause problems during SOC 2 assessments.

Relying Solely on Automated Scanning

Automated vulnerability scanners are useful tools, but they are not penetration tests. Scanners identify known vulnerabilities by matching signatures against a database. They cannot evaluate business logic flaws, test authentication bypass scenarios, chain multiple low-risk findings into high-impact exploits, or provide the kind of risk-contextualized analysis that auditors expect.

Auditors know the difference. A vulnerability scan report submitted in place of a penetration test is likely to trigger questions, delays, or a qualified opinion. Use scanning as a complement to pentesting—not a replacement.

Using Internal Teams Without Independence

Independence matters in audit. A penetration test conducted by your own engineering or security team—even a technically skilled one—lacks the third-party objectivity that auditors expect. The assessor needs to trust that the testing was thorough, unbiased, and free of conflicts of interest.

This doesn't mean your internal team can't participate. They can assist with scoping, provide access credentials, and be available to answer questions. But the actual testing and reporting should come from an independent, qualified third party.

Ignoring Remediation and Retesting

Identifying vulnerabilities is only half the job. Auditors want to see a complete story: what was found, what was fixed, and how you verified the fix.

If your pentest reveals a critical SQL injection vulnerability in a customer-facing application, the auditor wants to see more than just the original finding. They want a remediation ticket showing that your team addressed it, a timeline showing it was fixed promptly, and retest evidence confirming the vulnerability no longer exists.

A penetration test with unresolved critical findings is worse than no test at all from an audit perspective, because it documents known risks you haven't addressed.

Scope Misalignment

We mentioned this earlier, but it bears repeating because it's one of the most frequent reasons organizations receive qualified SOC 2 opinions. If your pentest scope doesn't match your system description, the auditor has no way to map the testing results to the controls they're evaluating.

Review your system description and your pentest scope document side by side before testing begins. Flag any discrepancies and resolve them up front.

Choosing the Right Testing Approach

SOC 2 doesn't prescribe a specific type of penetration test, which means you have flexibility in choosing the approach that best fits your environment.

Black box testing simulates an external attacker with no prior knowledge of your systems. The tester starts from zero, performing reconnaissance and attempting to breach your defenses just as a real threat actor would. This provides a realistic view of your external security posture but can be time-consuming.

Grey box testing gives testers limited information—perhaps a user account, API documentation, or network diagrams—to simulate a more informed attacker or a malicious insider. This approach is often the sweet spot for SOC 2 engagements because it efficiently covers both external and internal attack scenarios without spending excessive time on discovery.

White box testing provides full access to source code, architecture documentation, and admin credentials. This enables the deepest analysis but is more commonly associated with secure code reviews than traditional pentesting.

For most SaaS companies pursuing SOC 2, a grey box approach that includes external infrastructure, internal systems, web applications, APIs, and cloud configurations provides the strongest evidence at a reasonable cost. Your testing provider can help you determine the right balance based on your specific environment and the Trust Services Criteria you've included in your audit scope.

What Should Be in the Pentest Report?

Your penetration test report is the primary artifact your auditor will review. It needs to tell a clear, credible story. While there is no mandated format, a report that supports your SOC 2 audit should include the following elements.

An executive summary gives stakeholders a high-level overview of the engagement, the most important findings, and the overall risk posture. This is often what your auditor reads first.

A scope and methodology section describes the systems included in the test, the testing approach (black box, grey box, or white box), the tools and techniques used, and any limitations or exclusions. Methodology transparency is a basic quality threshold that auditors expect.

Detailed findings should describe each discovered vulnerability with enough context for someone to understand the risk. This includes a severity rating, a description of how the vulnerability could be exploited, evidence such as screenshots or proof-of-concept demonstrations, and the potential business impact.

Remediation recommendations provide actionable, prioritized steps for addressing each finding. The best reports don't just say "fix this"—they explain how to fix it and what the expected outcome should be.

Finally, retest results confirm that identified vulnerabilities have been addressed and verified. This closes the loop and gives your auditor confidence that the findings were taken seriously.

How Often Should You Test?

SOC 2 doesn't specify a frequency for penetration testing, but annual testing has become the accepted standard. At minimum, you should conduct a penetration test once per year, with the results falling within your audit observation period.

Beyond the annual cadence, you should also consider testing after significant changes to your environment. A major infrastructure migration, a new customer-facing application, a cloud provider change, or a fundamental shift in your architecture all introduce new risk that your previous pentest didn't evaluate.

Organizations with fast-moving development cycles—think daily deployments, microservices architectures, and continuous delivery pipelines—are increasingly adopting continuous or semi-continuous testing models. Rather than a single annual engagement, they run automated security scans continuously and layer periodic manual pentests on top. This approach not only supports SOC 2 but also gives development teams faster feedback on the security implications of their changes.

Beyond Compliance: Pentest as a Security Investment

It's easy to view penetration testing as a checkbox activity—something you do because the auditor expects it. But the real value goes far beyond the audit report.

A well-executed pentest gives you a realistic picture of how an attacker would approach your systems. It uncovers blind spots that internal teams—who are too close to the code and infrastructure to see them objectively—inevitably miss. It provides actionable intelligence that directly improves your security posture, reducing the likelihood and impact of a real breach.

For SaaS companies, where a single security incident can destroy customer trust and tank revenue, that's not just a compliance exercise. It's a core business investment.

The organizations that get the most value from penetration testing are the ones that treat it as an ongoing practice rather than a one-time event. They build relationships with their testing providers, integrate findings into their development and operations workflows, and use the results to drive continuous improvement in their security program.

Getting Started

If you're preparing for a SOC 2 audit and haven't yet engaged a penetration testing provider, here's a practical starting point:

First, finalize your system description and audit scope. You need to know the boundaries before you can scope a pentest against them.

Second, identify a qualified, independent testing provider with experience in SOC 2 engagements. They should be able to walk you through scope alignment, methodology selection, and report formatting that meets auditor expectations.

Third, schedule the engagement within your audit observation period, leaving enough time for remediation and retesting.

Fourth, build a remediation workflow before the test begins. Know who will own the findings, what your expected response times are for different severity levels, and how you'll track progress.

Fifth, review the final report with your auditor before the assessment fieldwork begins, or at least make sure it will be available when they need it.