Your SOC 2 Report Isn't a SOC 2 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

Your pentest scope is what you authorize a testing provider to assess. Your attack surface is everything an attacker can reach. These are not the same thing, and the gap between them is where real risk accumulates.

Before defining scope, inventory every system in your SOC 2 System Description and compare it against what is externally reachable. Tools like Shodan, Censys, AWS Config, and Google Security Command Center help identify exposed assets that are easy to miss.

Common assets that drift out of pentest scope while staying on the attack surface:

• APIs added after the last scope definition
• Mobile applications listed in the System Description but not included in testing
• OAuth integrations and third-party SSO connections
• AI features and model inference endpoints added in the past 12 months
• Administrative interfaces reachable from outside the production network

If an asset appears in your System Description and is omitted from your pentest scope, that gap should be documented, with a compensating control or a risk acceptance statement. "We didn't test it" is not a risk decision.

What Type of Pentest Is Right for a SaaS SOC 2?

For most SaaS companies, a grey-box application penetration test provides the most meaningful coverage. Unlike a black-box external network test, grey-box testing targets the controls SOC 2 specifically requires: authentication flows, authorization logic, API endpoints, session management, and cloud resource configuration.

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. Scoping What You Know Is Solid

The most common version of this is testing the web application while excluding the mobile app, even when the mobile app is referenced in the System Description and marketed as SOC 2 compliant. The rule is straightforward: if a system appears in your SOC 2 System Description, it belongs in scope unless you have a documented reason for the exclusion and your auditor is aware of it.

2. Shrinking Scope to Hit a Budget

Pentest pricing is largely driven by scope complexity and time. Scope reduction to control cost is a legitimate risk decision. The problem is that most teams making that trade-off do not know which exclusions are audit-safe and which create material coverage gaps. If budget constraints force you to narrow scope, document every exclusion explicitly in your pentest report. Your auditor needs to see that the decision was deliberate, not an oversight.

3. Reusing Last Year's Scope without reviewing it

Over 12 months, a typical SaaS company accumulates new API endpoints, third-party OAuth integrations, expanded cloud infrastructure, and AI features that process customer data. Applying last year's scope to this year's audit without reviewing it against your current System Description is one of the most common sources of SOC 2 coverage gaps.

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 pentest scoped to your SOC 2 System Description includes:

• Production environment, all tiers: web application, API layer, and database access paths.
• Authentication and session management: SSO configurations, multi-factor authentication enforcement, OAuth integrations, and token handling.
• Cloud infrastructure: IAM policies, storage permissions, network segmentation, and publicly exposed resources. Include a secure cloud review where your cloud infrastructure appears in the System Description.
• Internal access paths to customer data: paths labeled "internal only" that touch customer data are relevant to CC6.1.
• ‍Mobile applications, if your mobile app is listed in your System Description as a covered service, it belongs in scope.
• AI features and integrations: model inference endpoints, prompt injection surfaces, and data isolation boundaries between tenants.

Every exclusion from this list needs a documented rationale. A freemium environment hosted in a separate AWS account with no reference in the System Description is defensibly excludable. An API layer that processes customer data and is referenced in your System Description is not excludable without a documented compensating control. Unsure whether your current scope would satisfy an auditor or an enterprise security review? Review our SOC 2 penetration testing guide.

Vanta, Drata, and the Compliance Tooling Layer

If your team uses Vanta or Drata to manage SOC 2 compliance, your pentest report needs to produce evidence that maps directly to the controls those platforms track. Pentest reports that list generic vulnerability categories without mapping them to specific Trust Services Criteria create manual work for your compliance team and can slow your audit cycle.

Software Secured's Portal automatically maps each vulnerability identified in a pentest to the relevant SOC 2 Trust Services Criterion, including CC4.1, CC6.1, CC6.6, and CC7.1. That mapping syncs with Vanta and Drata, giving your compliance team audit-ready evidence without requiring them to manually interpret the pentest report.

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.