← Back to Blog
SOC 2

Do You Need a Penetration Test for SOC 2? Here's How to Know in 5 Minutes

SOC 2 never mentions "penetration test." But your auditor will ask about it anyway — and if you cannot produce evidence of one, you will spend the rest of your audit explaining why. Here is the full truth about what SOC 2 requires, when a pentest is non-negotiable, and what NullStrike delivers so you never face that question unprepared.

Sujal Meghwal, NullStrike Security May 2026 9 min read SOC 2 · Compliance · Penetration Testing

You have been told SOC 2 is the gate to enterprise sales. You have been told you need a penetration test. But when you read the actual SOC 2 criteria documents, the phrase "penetration test" does not appear once. So what is going on?

The answer is nuanced but not complicated. SOC 2 requires evidence that your security controls work under adversarial conditions. Penetration testing is the most efficient way to produce that evidence. Skip it and you will spend your audit on the back foot — explaining why you did not, instead of showing why your controls are solid.

In This Guide

  1. The Short Answer: Do You Need One?
  2. What SOC 2 Actually Says About Security Testing
  3. The Three Criteria That Drive Auditor Questions
  4. What Happens If You Skip the Pentest
  5. What Your SOC 2 Pentest Must Cover
  6. Type I vs Type II: Does It Change the Answer?
  7. How NullStrike Delivers SOC 2 Penetration Testing
  8. Timing Your Test Around the Audit Window

1. The Short Answer: Do You Need One?

For almost every company pursuing SOC 2 Type II for the first time or maintaining an existing certification, the practical answer is yes. Here is the decision tree:

You Need a Pentest If:

  • You are targeting enterprise customers
  • Customers send you a security questionnaire
  • Your product stores sensitive user data
  • You process financial or health data
  • Your auditor has asked about active testing
  • You have had a major architecture change
  • This is your first SOC 2 Type II audit
  • You want a clean opinion without findings

Edge Cases Where It May Not Block You:

  • Very early SOC 2 Type I (design only)
  • Extremely limited data scope (low sensitivity)
  • You have equivalent testing evidence from another framework
  • Your auditor has explicitly agreed in writing
The Real Risk of Skipping

Even if an auditor allows you to pass without a pentest, the absence will appear in the management letter or as a noted exception. Enterprise procurement teams review these letters. A noted exception on active security testing can kill deals just as effectively as a failed audit.

2. What SOC 2 Actually Says About Security Testing

SOC 2 is based on the AICPA Trust Services Criteria (TSC). The criteria are principles-based, meaning they describe what must be true without prescribing exactly how to achieve it. This is intentional — the framework is designed to apply to organizations of different sizes across different industries.

The word "penetration test" does not appear in the TSC because the AICPA does not mandate a specific testing technique. What the criteria do mandate is evidence of operational effectiveness. In the security category, that means demonstrating that your controls are not just in place but that they actually work when someone tries to break them.

That is the gap penetration testing fills. It is not required by name, but what it produces — evidence of adversarial testing, documented findings, and verified remediation — is exactly what satisfies the criteria that cover your external attack surface, your access controls, and your security monitoring.

3. The Three Criteria That Drive Auditor Questions

CC6.1 — Logical Access Controls

Requires that the organization implements and evaluates access security measures over protected information assets. Auditors look for evidence that these controls have been tested under adversarial conditions, not just documented. A penetration test that attempts to bypass access controls and documents the results is the strongest evidence you can provide for CC6.1.

CC6.6 — Logical Access from External Sources

Covers how you protect against threats from outside your system boundaries — meaning your internet-facing applications, APIs, and external-facing infrastructure. This is the criterion most directly addressed by a web application and API penetration test. If your product has a login page, an API, or any externally accessible service, CC6.6 requires you to demonstrate those are protected under adversarial conditions.

CC7.1 — System Monitoring and Change Management

Addresses whether your detection and monitoring procedures identify new vulnerabilities introduced by changes. Penetration testing validates that architectural changes, new features, or infrastructure updates have not introduced exploitable paths that your monitoring would not otherwise catch. This criterion is often the one that surprises founders — changes you made in the past 12 months are scope for auditor scrutiny.

Auditors evaluating these criteria do not just look at documentation of the control design. They look for evidence that the controls have been tested and shown to work. For CC6.6 specifically, the most common question is: "What evidence do you have that your external-facing applications cannot be exploited to access controlled data?" Penetration test reports answer that question directly.

4. What Happens If You Skip the Pentest

Companies that go into a SOC 2 audit without penetration testing evidence typically experience one of three outcomes:

Beyond the audit itself, there is the practical risk: you do not know what you do not test. A SOC 2 audit without penetration testing means you are asserting that your controls work without having verified it under real-world attack conditions. The next thing that verifies it could be an actual attacker.

5. What Your SOC 2 Pentest Must Cover

SOC 2 does not prescribe penetration test scope — but the Trust Services Criteria point clearly to what needs to be tested. For most SaaS companies, a SOC 2-oriented penetration test should cover:

Scope Tip

Define scope based on your trust boundary — everything that a malicious external actor or a malicious insider could reach to access customer data is in scope. For most SaaS products, this means the web app, the API, and the cloud environment hosting them. Your auditor will ask what was in scope, so document this clearly before testing begins.

6. Type I vs Type II: Does It Change the Answer?

SOC 2 Type I audits assess whether controls are suitably designed at a point in time. SOC 2 Type II audits assess whether controls were operating effectively over a period of time (typically 6–12 months).

For Type I: You may be able to complete it without a penetration test, particularly if you are in an early phase and the audit window is short. However, if you plan to pursue Type II (which most enterprise customers require), starting with no penetration test evidence means your Type II period begins with a gap. You will need to test before the Type II window closes, and doing it late means you have less time to remediate findings before evidence collection ends.

For Type II: A penetration test conducted during or before the audit period is standard expectation. If you have had no testing during the 12-month observation window, you cannot produce evidence of operational effectiveness for CC6.6 and CC7.1. This creates a structural gap that is very hard to close after the fact.

Practical Recommendation

If you are about to start your Type I, schedule your first penetration test to run concurrently or immediately after. This gets findings documented and remediated within the evidence window, and positions you perfectly for the Type II audit 6–12 months later.

7. How NullStrike Delivers SOC 2 Penetration Testing

The NullStrike SOC 2 Approach

Most penetration testing firms deliver a report. NullStrike delivers a report structured to answer auditor questions directly. Every finding is mapped to the relevant SOC 2 Trust Services Criteria so your auditor can trace from control to test evidence without asking you to do additional documentation work.

Before testing begins, we scope the engagement based on your Trust Services Criteria in scope (Security is always mandatory; Availability, Confidentiality, Privacy, and Processing Integrity are optional add-ons that expand scope). We then design testing to produce evidence for each criterion that has external attack surface implications.

What the engagement includes:

8. Timing Your Test Around the Audit Window

Timing matters more than most founders realize. Here is the critical path for getting penetration testing done without creating audit problems:

Get a SOC 2 Penetration Test Scoped in 24 Hours

Tell us your audit window, which Trust Services Criteria are in scope, and what your product stack looks like. We will send you a scope proposal within 24 hours — written to satisfy your specific auditor's expectations, not a generic template.

Book Free Scoping Call View Sample Report

Summary

SOC 2 does not say "penetration test required." But the Trust Services Criteria for CC6.1, CC6.6, and CC7.1 require evidence of adversarial testing that virtually no other activity produces as efficiently. Companies that skip penetration testing face audit findings, qualified opinions, or deal-killing exceptions in their management letters.

The most efficient path through a SOC 2 Type II audit is a penetration test conducted 3–4 months before your audit report is due, scoped to your system boundaries, and reported in a way that maps findings to Trust Services Criteria. That is exactly what NullStrike is built to deliver.

Related Reading

SOC 2
SOC 2 Penetration Testing Requirements Explained
Compliance Tools
Vanta & Drata Penetration Testing Requirements
Compliance
What SOC 2, ISO 27001, PCI DSS & HIPAA Actually Require