Is a Penetration Test Required for SOC 2?

TL;DR

The bottom line: SOC 2 auditors don't require penetration testing, but your customers do. For B2B SaaS companies pursuing enterprise deals, pentests are effectively mandatory because buyers expect and often require them. Your application is the widest attack surface and most visible target for attackers. A SOC 2 report without a pentest can feel like checkbox compliance. Grey box testing is recommended for most startups, with annual testing aligned to your audit cycle.

Auditors Don't Require Pentests, But Customers Do

SOC 2 is a descriptive framework, not a prescriptive checklist. The Trust Service Criteria define what your security program should achieve, but they don't mandate specific tools or assessments. From a pure audit perspective, nothing in SOC 2 explicitly requires a penetration test. Your auditor will not fail you for skipping one.

But here's the reality: your customers will.

Enterprise buyers, especially their security teams, expect to see a recent penetration test report alongside your SOC 2 certification. For many, it's a hard requirement in their vendor security questionnaires, and they won't sign a contract without it. This makes pentesting effectively mandatory for most B2B SaaS companies pursuing enterprise deals, even though auditors don't require it.

The goal of a SOC 2 report is to demonstrate the security measures implemented around your application's security, availability, and privacy. Your application is what customers actually use. It's either put directly into the hands of their users as a web application or consumed by their services through an API. It represents the most direct touchpoint, the widest attack surface, and the most visible target for anyone attempting to compromise your service.

An enterprise customer reviewing a SOC 2 report without a pentest may see coverage across many areas, but it raises immediate questions. Why would a company invest in compliance certification but skip the one assessment that actually tests whether their defenses work?

Why Penetration Tests Provide Real Value

Pentests deliver both external and internal value. Beyond satisfying customer requirements, this is where organizations find the most compelling and critical security issues.

Direct value from penetration testing:

• Product quality improvement: Pentests uncover vulnerabilities that automated tools miss, directly strengthening application security posture
• Development process improvement: Security feedback helps engineering teams build more secure code, identifying patterns and anti-patterns
• Developer experience improvement: Engineers learn from pentest findings, building security awareness that benefits future projects

Enterprise Buyers Require It

When a CISO at a prospective customer receives your SOC 2 report, they'll review the controls and auditor's opinion, but that's only part of their evaluation. The next request is almost always: "Can you share your penetration test report?" Pentest reports are separate documents from the SOC 2 report itself, typically shared via security questionnaires or trust portals.

If you don't have one, the deal often stalls. Many enterprise security questionnaires explicitly require evidence of annual penetration testing. For most enterprise buyers, it's not a "nice to have" in their evaluation criteria, it's a requirement that must be satisfied before procurement can proceed.

Experienced security leaders know that a pentest is one of the few ways to verify that security controls actually work in practice. A SOC 2 report states that access controls exist. A pentest verifies whether the application actually enforces them, whether a determined attacker can escalate privileges, access other tenants' data, or bypass authentication entirely.

A pentest answers these questions. A checklist does not.

Auditors View Them Favorably (But Won't Require Them)

To be clear: your SOC 2 auditor will not fail you for skipping a penetration test. It's not a required control. However, auditors increasingly recognize pentests as strong evidence for the Security trust service criteria, particularly controls around vulnerability management (CC6.1, CC7.1). A clean pentest report, or one showing that vulnerabilities were identified and fixed, supports the control environment in ways that policies and procedures alone cannot.

Many auditors specifically ask whether organizations conduct regular security assessments. Having a pentest report ready simplifies that conversation significantly. But remember: even if your auditor doesn't require it, your customers almost certainly will.

Types of Penetration Tests

Not all pentests are equivalent. Understanding the differences helps organizations choose the right approach for their situation.

Black Box Testing

In a black box test, the tester has no prior knowledge of the target systems. They approach the application the way an external attacker would, starting with only publicly available information.

Why not black box (alone)?

Black box testing is valuable for:

• Large, mature companies with established security programs
• Testing detection and monitoring team capabilities
• Validating perimeter controls and external defenses

But early-stage startups usually don't need:

• SOC detection simulation
• External-only threat modeling

The priority for startups is fixing core product security first. Grey box testing addresses this directly, while black box testing spends time on reconnaissance that could be directed toward finding application-level vulnerabilities.

Best for: Large enterprises with complex on-premise infrastructure, mature security programs, or organizations that need to test their security operations center's detection capabilities.

Grey Box Testing

Grey box testing provides the tester with partial information: user credentials, basic architecture documentation, and context about the application's functionality. This simulates an attacker who has gained initial access or an insider with limited privileges.

Grey box testing is the recommended approach for startups. This is where organizations find the best balance between cost, coverage, and realistic threat modeling.

Advantages:

• More efficient than black box testing
• Testers can focus on finding meaningful vulnerabilities rather than spending days on reconnaissance
• Catches both external and internal issues
• Cost-effective for the depth of coverage

Considerations:

• Requires upfront coordination to provide access and documentation

Best for: Most SaaS startups preparing for SOC 2 or pursuing enterprise customers. Grey box testing provides the most value for the investment.

White Box Testing

White box testing gives the tester full access: source code, architecture diagrams, database schemas, internal documentation, and admin-level access. This combines active penetration testing with code-level security review, providing the most comprehensive assessment possible.

Advantages:

• Deepest level of coverage
• Can identify vulnerabilities that wouldn't be found through external testing, including logic flaws and code-level issues

Considerations:

• Most expensive and time-consuming
• Requires significant internal coordination
• Results can be overwhelming for codebases with significant technical debt

Best for: Organizations handling highly sensitive data (healthcare, finance) or those who have addressed surface-level vulnerabilities and want a deep analysis of their security architecture.

Automated Vulnerability Scanning

Tools like Nessus, Qualys, and similar scanners automatically probe systems for known vulnerabilities. While valuable, these are not penetration tests.

What they do: Identify known CVEs, missing patches, misconfigurations, and common security issues. Fast and inexpensive to run.

What they don't do: Find business logic flaws, test access control enforcement, identify application-specific vulnerabilities, or simulate actual attack chains.

Automated scanning is table stakes. Every organization should run regular vulnerability scans. However, calling a Nessus report a "pentest" will raise concerns with any serious security team. These tools complement manual testing but do not replace it.

How to Scope a Pentest for SOC 2

Organizations preparing for SOC 2 should approach penetration testing systematically.

Start with Grey Box

For most startups, a grey box pentest provides the best value. This approach offers thorough coverage of application security without paying for days of reconnaissance. Provide the tester with:

• Test user accounts at different permission levels
• Basic architecture documentation
• A list of in-scope and out-of-scope systems
• Areas of particular concern

Focus on Your Application

The SaaS application is where customer data lives. That's where the pentest should focus. Testing corporate network infrastructure is less relevant for SOC 2 purposes unless the organization is also pursuing ISO 27001 or has specific customer requirements.

Key areas to test:

• Authentication and session management
• Authorization and access controls
• Multi-tenant data isolation
• API security
• Input validation and injection vulnerabilities
• Business logic flaws
• File upload handling
• Rate limiting and abuse prevention

Time It Right

Schedule the pentest before the SOC 2 audit period begins. This allows time to remediate findings and demonstrate a mature security posture. Rushing a pentest during the audit window, only to discover critical issues, creates problems with auditors.

For most startups, annual pentests are sufficient. Organizations making significant changes to application architecture or handling particularly sensitive data may need more frequent testing.

Choose a Qualified Provider

Not all pentest providers deliver the same quality. Enterprise customers will ask about pentester credentials, so selection matters.

Relevant certifications: CREST, OSCP, OSCE, or similar credentials demonstrate technical competence. These matter to customer security teams.

Years of experience: Customers will ask about pentester backgrounds. Depending on the target market, look for at least five years of experience in offensive security. Many enterprise customers expect eight to ten years.

SaaS experience: A provider who understands multi-tenant architectures and cloud environments will find more relevant issues than someone focused on traditional network penetration testing.

Clear methodology: Providers should explain their approach, not just run automated tools. Common frameworks include OWASP Testing Guide, PTES (Penetration Testing Execution Standard), and NIST SP 800-115. Quality providers map their methodology to these standards.

Actionable reporting: Findings should include reproduction steps and remediation guidance, not just vulnerability descriptions. Reports need to be useful for development teams.

Country of origin: Enterprise customers often scrutinize where pentesters are based. NATO-based pentesters with strong English skills are generally preferred. This limits fraud risk and ensures well-written reports that pass security reviews. Some industries and customers have explicit requirements about pentester geography.

Avoid low-quality options: It's easy to find cheap pentesters on freelance platforms or services that run automated tools and compile the output into a report with "penetration test" at the top. Neither option builds real security, and neither passes serious security reviews. These reports get rejected regularly. If the pentest matters for your business, do it right.

Avoid providers who promise to "certify" applications or guarantee clean reports. A good pentest should find issues. That's the purpose.

Plan for Retesting

After remediating critical and high-severity findings, schedule a retest to verify the fixes work. Most pentest providers offer retesting at a reduced rate. Documented evidence that vulnerabilities were identified, fixed, and verified is exactly what enterprise security teams want to see.

Consider AI-Specific Testing

Applications that include AI or LLM features should have pentests that cover AI-specific attack vectors:

• Prompt injection: Can attackers manipulate the AI's behavior through crafted inputs?
• Jailbreaking: Can users bypass AI guardrails and safety measures?
• Data exfiltration: Can the AI be tricked into revealing training data or sensitive information?
• Workflow manipulation: Can attackers use the AI to perform unauthorized actions?

There's no bulletproof defense against all AI attacks, but organizations can implement defenses for critical workflows and demonstrate that they've been tested. Enterprise customers increasingly expect AI security to be part of security assessments, especially when AI features handle sensitive data or perform consequential actions.

Plan for Remediation

A pentest report full of unaddressed findings creates more problems than it solves. Budget time and resources for remediation. Enterprise customers want to see not just that a pentest was conducted, but that findings were fixed.

Prioritize findings based on severity and exploitability. Critical and high-severity issues should be addressed immediately. Medium and low issues can be addressed over time but should be tracked and scheduled.

What Bastion Clients Do

At Bastion, we help startups navigate the compliance landscape without overspending on security theater. For penetration testing, the approach is straightforward:

We coordinate grey box pentests as part of our managed compliance services. Instead of shopping for pentest vendors, negotiating scope, and determining what to test, we handle it. Results feed directly into SOC 2 evidence collection, and we help prioritize remediation based on what matters for the audit and for customers.

This isn't about checking a box. It's about building a security program that actually protects customer data and holds up under scrutiny from enterprise security teams.

SOC 2 Penetration Testing: Key Takeaways

SOC 2 auditors don't require a penetration test. But your customers do.

This distinction matters. You can technically pass a SOC 2 audit without ever running a pentest. Your auditor won't fail you for it. But when you hand that SOC 2 report to an enterprise prospect's security team, the first question will be: "Where's the pentest report?" If you don't have one, the deal may not close.

A grey box pentest is the most effective approach for most SaaS startups. It provides thorough coverage at a reasonable cost, and the results give enterprise buyers confidence that security claims are more than documentation.

Organizations preparing for SOC 2 should plan for a pentest, schedule it early, remediate findings, and keep the report ready. Not because your auditor requires it, but because your customers will.

Preparing for SOC 2 and need help scoping a penetration test? Talk to our team about how Bastion's managed compliance services include coordinated security assessments that map directly to your audit requirements.