SOC2 requires penetration testing. But the standard is intentionally vague about what "penetration testing" means — it does not specify scope, methodology, depth of testing, or anything beyond the general expectation that you perform security assessments. This ambiguity creates a predictable outcome: organizations with compliance-oriented (rather than security-oriented) advisors run the narrowest test that satisfies the auditor, check the box, and move on. The problem surfaces not during the SOC2 audit — which they pass — but during the enterprise vendor review, where procurement teams with real security expertise look at the pentest evidence package and immediately spot a test that was scoped to protect against audit failure rather than actual security failure.
TL;DR: SOC2 auditors accept almost any pentest report from a recognized firm. Enterprise procurement teams look harder: they check the date, the scope, the finding severity distribution, and the remediation evidence. A well-scoped annual test with real findings and documented remediation closes more enterprise deals than a narrow clean report. Scope your pentest for the customer review, not just the audit.
What SOC2 Actually Says About Penetration Testing
The SOC2 Trust Services Criteria (TSC) CC7.1 addresses detection and monitoring of security threats. It requires that an organization "uses detection and monitoring procedures including performance of penetration tests and vulnerability assessments." The language does not specify:
- Which systems must be in scope
- What methodology must be used (black box, gray box, white box)
- What frequency beyond the implied annual cadence
- What severity of findings must be present or addressed
- Whether the test must be against production or can target non-production environments
This is intentional — the AICPA designed SOC2 to be framework-agnostic and adaptable to organizations of different sizes and types. The flexibility that makes SOC2 broadly applicable also makes it easy to satisfy with a minimal, compliance-only pentest.
What Auditors Actually Accept
In practice, SOC2 auditors sampling the penetration testing control typically verify: that a penetration test was performed during the period under audit, that it was conducted by a recognized third-party firm (not internal staff), that there is a report documenting findings, and that critical or high findings were addressed. They do not evaluate the adequacy of the scope, the quality of the testing methodology, or whether the tested systems represent the actual risk surface.
This means auditors routinely accept: tests scoped only to an external IP range (no application testing), tests performed on staging or QA environments, tests that cover a single application when the company operates ten, and tests that focus on infrastructure scanning with minimal manual testing. The auditor's job is to verify the control exists and was operated — not to evaluate its effectiveness.
What Enterprise Procurement Actually Evaluates
Enterprise vendor risk managers and security architects reviewing your SOC2 package look at penetration test evidence with significantly more scrutiny than your auditor. They have frameworks for evaluating vendor security evidence, and an obviously narrow pentest is a red flag that triggers either rejection or an escalated review.
| Evidence Factor | What Auditors Check | What Enterprise Procurement Checks |
|---|---|---|
| Test date | Was it within the audit period? | Is it within 12-18 months? Has the product changed significantly since? |
| Scope statement | Is there a scope statement? | Does scope include the application we'll use? Does it include the API? Admin interfaces? |
| Testing firm | Is the firm recognized? | What is the firm's reputation? Do they do real manual testing or automated scanning? |
| Findings severity | Were criticals/highs addressed? | A test with zero findings in a broad scope is suspicious — were findings suppressed or was scope too narrow? |
| Remediation evidence | Is there a remediation attestation? | What specific findings were found? What was fixed? When? |
| Methodology | Not typically reviewed | Was this automated scanning or manual testing? Was authentication tested? |
What Scope Actually Provides Security Value
A pentest scoped for genuine security value — rather than minimal audit compliance — covers the following:
Production systems, not staging
Staging environments frequently have different configurations than production — different access controls, different data, different integrations. Testing staging tells you about staging. If your production environment has different authentication settings, third-party integrations, or data access patterns, a staging test misses the most important attack surface.
Full application coverage including recent changes
Every new feature shipped since the last pentest is unreviewed attack surface. An annual pentest that covers the same scope as the prior year misses everything that changed. The scope document should explicitly include new functionality shipped in the prior twelve months.
Authentication and authorization mechanisms
Authentication bypass and broken authorization (BOLA, BFLA) are consistently among the highest-severity findings in web application tests. These require manual, multi-account testing that automated vulnerability scanners don't provide. If your pentest methodology doesn't include explicit authorization testing, it isn't finding the most impactful vulnerabilities.
API endpoints, including undocumented ones
Modern SaaS applications have extensive API surfaces — often larger than the frontend interface. API endpoints that are not in official documentation are frequently under-tested and over-permissioned. A scoped pentest that excludes the API is not testing what enterprise integrations actually use.
Building a SOC2 Evidence Package That Closes Enterprise Deals
The pentest evidence you include in your vendor security package should tell a complete story: here is what we tested, here is what we found, and here is what we fixed. A well-constructed package includes:
- Executive summary. A one-to-two page summary with scope, methodology, finding severity distribution, and overall risk rating. This is what procurement teams read first.
- Scope statement. Explicit enumeration of what was tested: which applications, which APIs, which environments, which authentication flows. The more specific, the more credible.
- Finding severity distribution. A table showing how many critical, high, medium, low, and informational findings were identified. Zero findings across all severity levels in a broad-scope test is suspicious. Finding something and fixing it demonstrates a functional security process.
- Remediation evidence. For each critical and high finding: the finding description, the fix applied, and the date remediated. Some organizations provide a retest attestation confirming fixes were verified.
Lorikeet Security's pentest reports are structured to serve dual audiences — your internal security team's remediation workflow and your enterprise customer's vendor review process. The goal is a report that passes both tests.
Get a pentest scoped for real security — not just audit compliance.
Lorikeet Security's SOC2-aligned penetration testing covers production systems, APIs, authentication, and authorization mechanisms — providing evidence that satisfies auditors and impresses enterprise procurement teams.
