SOC 2 does not explicitly require penetration testing, but in 2026, most auditors treat it as a de facto necessity for SaaS companies. Without documented pen test results, you risk failing the CC7.1 (vulnerability management) and CC6.8 (unauthorized software) controls. This guide explains what scope, frequency, and evidence your auditor will ask for — and how to prepare before your Type II window opens.

94% of SOC 2 auditors expect pen test evidence for Type II 1× minimum annual pen test frequency. Auditors want documented CC7.1 Trust Services Criteria, most often cited when pen tests are missing, 30 days is the typical auditor expectation to remediate critical findings

Why Pen Testing Is "Not Required" — But Still Expected

If you've read through the AICPA's Trust Services Criteria cover-to-cover, you won't find the words "penetration test" anywhere. This surprises many CTOs and founders who assume that compliance frameworks are purely prescriptive. SOC 2 is principles-based, not rules-based — meaning it defines what you need to prove, not the exact tools you use to prove it.

So, where does pen testing come from? It emerges from the intersection of several controls — primarily around vulnerability identification, risk assessment, and unauthorized access detection — that auditors have learned, through years of practice, cannot be reliably demonstrated without adversarial testing.

⚠ AUDITOR REALITY CHECK Skipping pen testing doesn't guarantee audit failure, but it puts your organization in a position where you must provide an alternative body of evidence that satisfies the same spirit of the controls. In practice, very few early-stage SaaS companies can do this. Most auditors will issue an exception or qualified opinion rather than pass a company with no adversarial testing on record.

The shift happened gradually over the past decade. As high-profile SaaS breaches multiplied and enterprise buyers started demanding more rigorous compliance evidence, auditing firms updated their internal playbooks. By 2026, asking "Do you do pen testing?" is as routine for a SOC 2 auditor as asking "Do you have a change management policy?" It's simply expected.

The Trust Services Criteria That Trigger Auditor Scrutiny

Understanding which specific criteria a pen test satisfies helps you frame your evidence correctly. The following SOC 2 Trust Services Criteria are the most directly addressed by penetration testing:

TABLE: SOC 2 Trust Services Criteria

💡 PRO TIP: When presenting pen test results to your auditor, map findings directly to Trust Services Criteria using a cross-reference table. This saves time during fieldwork and signals that your security team understands the compliance context — not just the technical one.

What Should Be In Scope for Your SOC 2 Pen Test

One of the most common audit failures isn't the absence of a pen test — it's a pen test with a scope that's too narrow to satisfy auditor expectations. Here's what an adequate scope looks like for a SaaS startup in 2026:

External Network and Application Layer

At minimum, your SOC 2 pen test must cover your externally facing attack surface: web application endpoints, APIs, authentication mechanisms (including OAuth flows, SSO integrations, and API key management), and any customer-facing admin portals. If you run on AWS, GCP, or Azure, your cloud perimeter configuration — S3 bucket policies, IAM misconfigurations, open security groups — must be included.

Internal Network and Privilege Escalation

Auditors increasingly expect internal network testing for companies that operate their own infrastructure or have significant employee access to production data. This tests whether an attacker who compromises a single low-privilege account can escalate to administrative access — a scenario that has driven some of the most damaging SaaS breaches in recent years.

Cloud Configuration and Infrastructure-as-Code

For cloud-native SaaS startups, infrastructure misconfiguration is often the highest-risk vector. A qualified pen test should include a review of your Terraform, CloudFormation, or Pulumi configurations against cloud security benchmarks (CIS, NIST 800-53) and an assessment of active exploitation attempts.

Social Engineering and Phishing Simulation

While not universally required, auditors at larger firms increasingly ask whether you've tested human-layer controls — specifically, whether employees would click on phishing emails or disclose credentials under pretextual scenarios. For companies handling sensitive health, financial, or personal data, this is quickly becoming a baseline expectation.

✅ SCOPE CHECKLIST MINIMUM External web app and APIs · Authentication controls · Cloud configuration · Admin portals · Third-party integrations · Internal privilege escalation (if on-prem or hybrid). This scope satisfies most SOC 2 Type II auditors in 2026.

How Often Should SaaS Startups Run Pen Tests for SOC 2

The short answer: at least once per year, with additional tests triggered by significant change. But frequency alone doesn't satisfy auditors — it's the relationship between your testing cadence and your rate of product and infrastructure change.

TABLE: Penetration Testing Frequency by Company Stage

A key nuance auditors check: Does your pen test cover the period under audit? For a SOC 2 Type II report covering January 1 – December 31, a pen test completed in February of that same year is ideal. A pen test from 18 months ago will draw scrutiny — especially if you've shipped significant product features since then.

Evidence Auditors Actually Want to See

Beyond penetration testing, auditors evaluate comprehensive evidence across all SOC 2 controls — understanding the complete evidence framework helps position your pen test results correctly."

Completing a pen test is only half the battle. What ultimately satisfies your auditor is a clean, traceable evidence trail that demonstrates you not only tested your systems, but acted on what you found. Here's exactly what auditors typically request during fieldwork:

1. The Full Penetration Test Report

A professional pen test report should include: methodology (e.g., OWASP, PTES, NIST), scope definition, a dated executive summary, a full list of findings with severity ratings (Critical / High / Medium / Low), proof-of-concept screenshots or payloads, and remediation recommendations. Reports from reputable vendors will follow this structure — but always verify before engaging.

2. A Remediation Tracking Log

This is where most startups fall short. The report proves you found vulnerabilities. The remediation log proves you fixed them. Auditors want a dated record showing each finding, the person responsible for remediation, the fix applied, and the date closed. This can live in Jira, Linear, Notion, or a dedicated GRC platform — as long as it's timestamped and auditable.

3. Retest or Validation Evidence

For Critical and High-severity findings, auditors increasingly expect evidence of retesting: either a formal retest report from your pen testing vendor confirming the fix, or internal validation evidence (e.g., a security engineer's screen recording of a failed exploit attempt post-fix).

4. Risk Acceptance Records for Unresolved Findings

If a finding couldn't be fixed within the audit period — due to business constraints or a compensating control — you need a formal risk acceptance document signed by an appropriate executive (typically the CTO or CISO). Without this, unresolved findings become automatic exceptions in your audit opinion.

5. A Written Penetration Testing Policy

Your penetration test should be described in a formal policy that specifies: testing frequency, scope definition process, vendor requirements, and how findings feed into your vulnerability management workflow. Auditors use this to assess whether testing is systematic or ad hoc — two very different signals.

5 Pen Testing Mistakes That Derail SOC 2 Audits

Mistake 1: Running the Test Too Late in the Audit Period

If your 12-month audit window ends in December but your pen test runs in November, you've left yourself almost no time to remediate findings before the auditor starts fieldwork. Best practice: Schedule your annual test in Q1 or Q2 of your audit period, giving yourself 6–9 months to close findings before review.

Mistake 2: Using an Automated Scan Instead of a Manual Test

Vulnerability scans (Nessus, Qualys, AWS Inspector) and penetration tests are not the same thing. Automated scanners identify known CVEs in your infrastructure. Manual pen testing uses human creativity to chain vulnerabilities, test business logic, and simulate real attacker behavior. Auditors know the difference — and a scan report submitted as a pen test report is a red flag that triggers deeper scrutiny.

Mistake 3: Scoping Out Key Systems to "Keep It Cheap"

It's tempting to reduce testing costs by scoping out older services, internal tools, or "non-critical" APIs. Auditors — especially those who specialize in SaaS companies — know this trick well. If your scope definition visibly excludes systems that touch customer data, expect pushback.

Mistake 4: No Remediation Evidence for Critical Findings

Discovering a Critical finding and closing the ticket without documented evidence of the fix is surprisingly common. Even if the vulnerability is genuinely gone, without evidence, it might as well still exist in your audit. Always capture screenshots, pull request links, or configuration exports that prove the fix.

Mistake 5: Selecting a Vendor Without SOC 2 Context Experience

Not all penetration testing firms understand compliance auditing. A vendor experienced in enterprise red team engagements may produce reports that are technically excellent but structured in a way that doesn't map cleanly to the Trust Services Criteria, forcing you to do additional translation work before your audit. Ask vendors: "Have you supported SOC 2 Type II audits before? Can you map findings to TSC controls?" Avoiding these penetration testing pitfalls is part of broader pre-audit preparation that separates smooth audits from problematic ones.

Choosing the Right Pen Testing Vendor for SOC 2

The penetration testing market has matured significantly, and SaaS startups now have options ranging from traditional boutique consultancies to automated PTaaS (Penetration Testing as a Service) platforms. Here's a quick comparison framework:

TABLE: Pen Testing Vendor Types

Regardless of vendor type, always verify: testers' OSCP/GPEN/CEH certifications, a sample report showing TSC mapping, a clear scope of work with a signed rules-of-engagement document, and a retest policy included in the engagement fee.

Your Pre-Audit Penetration Testing Checklist

Use this checklist in the 90 days before your SOC 2 Type II audit fieldwork begins. Every item should be documented and ready for auditor review. This penetration testing checklist complements our comprehensive SOC 2 readiness checklist, which covers all control families required for certification.

☑ Written pen testing policy on file, reviewed within the last 12 months

☑ Scope definition document signed off by CTO and covering all customer-facing systems

☑ Pen test completed within the audit period by a qualified third-party vendor

☑ All Critical findings remediated with documented evidence of fix

☑ All High findings remediated or risk-accepted with signed acceptance document

☑ Remediation log exported from your GRC or ticketing system, dated and attributed

☑ Retest report from vendor confirming Critical and High fixes (or internal validation screenshots)

☑ TSC control mapping cross-referencing pen test findings to CC6.6, CC7.1, CC6.8

⚠ Evidence fed into your vulnerability management program and linked to risk register (recommended)

⚠ Next test scheduled and vendor re-engaged (shows continuous commitment to auditor)

Frequently Asked Questions

Is penetration testing required for SOC 2?

SOC 2 does not explicitly mandate penetration testing in its Trust Services Criteria. However, the vast majority of auditors treat it as a practical necessity, especially for SaaS companies handling sensitive data. Without documented pen test results, auditors typically flag gaps in your risk management and vulnerability management controls — most often under CC7.1.

How often should a SaaS startup run penetration tests for SOC 2?

For a SOC 2 Type II audit, most auditors expect at least one full penetration test per year, with additional tests triggered by major product releases or infrastructure changes. High-growth startups that process sensitive financial or health data often conduct semiannual testing to stay ahead of auditor scrutiny.

What evidence do auditors want from a penetration test?

Auditors typically ask for the full pen test report (methodology, scope, findings, severity ratings), a remediation log detailing how each finding was addressed, a retest or validation report confirming the fixes, and an executive summary showing the risk posture over time. Missing the remediation log is the single most common evidence gap we see at DSALTA.

Can I use a vulnerability scan instead of a penetration test for SOC 2?

No. Vulnerability scans and penetration tests are fundamentally different. Scans identify known CVEs automatically — penetration tests use human expertise to chain vulnerabilities and simulate real attacker behavior. Auditors are well aware of the distinction, and submitting a scan report in place of a pen test will trigger additional scrutiny or an audit exception.

What if we have unresolved findings at the time of the audit?

Unresolved findings are acceptable if they are formally risk-accepted. This requires a documented risk-acceptance document signed by an appropriate executive, noting the compensating controls in place and the business rationale for deferring remediation. This is far better than having unresolved findings with no documentation.

Ready for Your SOC 2 Type II Audit?

DSALTA helps AI-powered SaaS companies build audit-ready compliance programs — including pen testing vendor coordination, remediation tracking, and TSC evidence mapping. Schedule a free readiness review and know exactly where your gaps are before your auditor does.