Your SOC 2 Report Isn't a Pentest: What Early-Stage SaaS Founders Get Wrong

Your SOC 2 Report Isn't a Pentest: What Early-Stage SaaS Founders Get Wrong

Most SaaS founders assume that once they have a SOC 2 report and a penetration test, they're covered. Then an enterprise prospect sends over a security questionnaire and starts asking questions about API security, new authentication controls, network segmentation, or mobile applications that were never included in the test. The surprise is that a SOC 2 report doesn't tell anyone what was actually tested. It only demonstrates that controls were assessed. Whether the penetration test evaluated the systems an attacker would target is a separate question entirely.

That's where many early-stage SaaS companies run into trouble. The pentest satisfies the audit requirements, but it doesn't necessarily validate the security of the product that customers are buying. In this guide, we'll look at what SOC 2 expects, where penetration testing's scope often falls short, and how to build a testing program that holds up to scrutiny from both auditors and enterprise security reviewers.

The controls most directly evaluated through pentesting are CC6.1 (logical access controls), CC6.6 (security of external-facing systems), and CC7.1 (detection of vulnerabilities and anomalies in production). A pentest report is the primary third-party evidence that auditors use to assess whether those controls hold under adversarial conditions. In practice, many auditors require a black-box external network penetration test covering the web application systems in scope. Some accept a network scan against a defined IP range, check the CC4.1 box, and move on.

The challenge is that auditors evaluate whether controls are present and operating as described. Determining whether every system an attacker might target was included in the assessment is often outside the scope of the audit itself.  Whether the IPs in the pentest report correspond to the systems described in your System Description or whether the application layer was tested at all is outside the scope of what most auditors are paid to verify.

Auditors are only evaluating whether an organization has evidence that controls were assessed and not whether every system an attacker might target was included in the assessment.

The Difference Between Pentest Scope and Attack Surface

One of the most common scoping mistakes SaaS teams make is assuming their pentest scope and attack surface are the same thing.

They're not.

Your pentest scope is what you've authorized a pentesting provider to assess. It's a business decision. It defines what is in bounds, what is excluded, and how much time will be spent evaluating each area. Your attack surface is everything an attacker can potentially reach. That includes web applications, APIs, mobile apps, cloud resources, third-party integrations, AI features, authentication systems, and administrative interfaces.

The gap between those two things is where security blind spots emerge. Before defining scope, inventory the systems described in your SOC 2 System Description and compare them against your actual attack surface. Tools such as Shodan, Censys, AWS Config, and Security Command Center can help identify exposed assets that may otherwise be overlooked.

A good pentest scope doesn't start with a budget. It starts with understanding what you're actually trying to protect.

For example, your pentest may include a production web application and a handful of IP addresses. Your attack surface may also include APIs, mobile applications, OAuth integrations, internal administrative tools, and AI-powered features. If those assets aren't included in the scope, they aren't being evaluated, regardless of whether they are exposed to attackers.

What Type of Penetration Test Is Best for SOC 2?

For most SaaS companies pursuing SOC 2, a grey-box application penetration test provides the most meaningful coverage. Unlike a black-box network test, grey-box testing evaluates authentication, authorization, APIs, session management, and other controls directly tied to SOC 2 criteria such as CC6.1, CC6.6, and CC7.1. It helps verify that the controls described in your System Description are functioning in practice. A black-box network scan tests your firewall. A grey-box application pentest tests your SOC 2 controls.

The Three Scoping Mistakes That Create Audit Gaps

Most SOC 2 pentest scope gaps result from reasonable-sounding decisions made without visibility into the audit implications.

1. Testing What You Know Is Solid

It's tempting to scope the pentest toward systems you're confident in and exclude anything you're less certain about. The most common version of this is testing the web application while excluding the mobile app, even though the mobile app is promoted as SOC 2 compliant and referenced in your System Description.

A simple rule: if a system appears in your SOC 2 System Description, you should assume it belongs in your pentest scope unless you have a documented reason to exclude it.

2. Shrinking Scope to Hit a Price Point

Pentest pricing is largely driven by scope complexity and time. Reducing the scope to bring the quote down is a common decision. The problem is that most founders making that trade-off don't know which exclusions are audit-safe and which create material coverage gaps. A narrower scope for budget reasons is a valid risk decision, but it needs to be documented. If your pentest excludes your API layer to save money, that exclusion should appear explicitly in your pentest report, and your auditor should be aware of it.

3. Reusing Last Year's Scope

Reusing a prior-year pentest scope without reviewing it against your current System Description is one of the most common sources of audit gaps. Over 12 months, the typical early-stage SaaS company accumulates new SaaS integrations, third-party OAuth connections, additional API endpoints, expanded cloud infrastructure, and AI features that handle customer data.

Defining Out-of-Scope Assets Explicitly

Every exclusion from your pentest scope should have a documented business or technical rationale. If an asset appears in your System Description but is excluded from testing, document the compensating controls or alternative assessment methods used to evaluate risk.

For example, a freemium environment hosted separately from production and not referenced in the System Description may be reasonably excluded. The key is that exclusions are deliberate and documented.

What a SOC 2-Aligned Pentest Scope Actually Looks Like

A SOC 2-aligned pentest scope should include:

• Production environment, all tiers: web, API, and database access paths
• Authentication and session management: SSO, MFA enforcement, OAuth integrations, and token handling
• Cloud infrastructure configuration: IAM policies, storage permissions, and network segmentation. Assess with a secure cloud review where required
• Internal access paths to customer data: even paths designated "internal only" (if they touch customer data, they're relevant to CC6.1)
• Mobile, if promoted as SOC 2 compliant: reference your System Description; if mobile is in it, it belongs in scope
• AI features and integrations handling customer data: model inference endpoints, prompt injection surfaces, and data isolation boundaries between tenants

 Unsure whether your current scope would satisfy an auditor or an enterprise security review? Review our SOC 2 penetration testing guide.

Frequently Asked Questions

My auditor accepted our network scan last year. Why does scope matter now?

Many auditors accept a network scan because it satisfies the letter of CC4.1; a third-party evaluation was performed. That doesn't mean it evaluates whether your controls are actually functioning. As enterprise buyers issue more rigorous vendor security questionnaires and as your product's attack surface grows, the gap between what your report covers and what a buyer wants to verify widens. Scope determines what your pentest can actually defend. In fact, organizations that initially satisfy SOC 2 requirements with a network scan often find that, after several years with the same audit partner, expectations evolve. By years two or three, auditors may expect a more comprehensive penetration test to support the organization's ongoing security commitments.

How do we handle assets that are legitimately out of scope, like a freemium tier or a mobile app we're still building?

Document the rationale for every exclusion explicitly in your Risk Registry. A freemium tier hosted in a separate AWS account with a subset of Enterprise features and no reference in the SOC 2 System Description is defensibly excludable, if you write it down. A mobile app that appears in your System Description as a covered service is not excludable without a compensating control or an explanation that your auditor can review. "We didn't test it" is not a risk decision; it's an absence of one.

Who should define the pentest scope: our security team, the pentest vendor, or our auditor?

The scope should be defined collaboratively between your security team (or whoever owns your System Description) and your penetration testing vendor. Your auditor should be consulted before the pentest if you're uncertain whether a proposed scope covers the assets referenced in your System Description. Auditors rarely define the scope themselves, but they will tell you whether a scope document is likely to satisfy audit requirements. The vendor's job is to test what you authorize. Your job is to authorize the right things.

If Your Pentest Wouldn't Catch a Breach, It Shouldn't Satisfy Your Auditor

There is a gap between what auditors require and what CC4.1 intends. Auditors will accept a pentest report that covers a narrow IP range and call it CC4.1 evidence. That doesn't mean your controls were tested. It means a report was submitted.

A grey-box application SOC 2 penetration test scoped to your actual System Description doesn't just satisfy the audit. It tests whether the controls your SOC 2 report claims are actually working against the authentication flows, API endpoints, cloud configurations, and application features an attacker would actually target.

A SOC 2 report proves you have controls. A properly scoped penetration test proves they work.