SOC 2 has become the de facto standard for SaaS companies proving their security posture to enterprise customers. But when it comes to penetration testing, there's confusion: Is it required? What do auditors expect? How often should you test?

This guide clarifies the role of penetration testing in SOC 2 compliance, what auditors actually look for, and how to structure your testing program for Type II success.


Does SOC 2 Require Penetration Testing?

The short answer: Not explicitly, but effectively yes.

SOC 2 is based on the AICPA's Trust Services Criteria (TSC). Unlike , which prescribes specific security controls, SOC 2 is principles-based. It describes security objectives without mandating how you achieve them.

However, several Trust Services Criteria strongly imply penetration testing:

CC4.1

Risk Assessment

The entity identifies and assesses risks to the achievement of objectives. Penetration testing is a primary method for identifying security risks in practice.

CC7.1

Security Testing

The entity conducts evaluations of controls to determine their effectiveness. Regular security testing, including penetration testing, demonstrates control evaluation.

CC7.2

Incident Identification

The entity monitors system components for anomalies and indicators of compromise. Penetration testing validates that monitoring controls would detect real attacks.

The Practical Reality

While penetration testing isn't explicitly required, auditors almost universally expect it. During audit interviews, controls like "we conduct annual penetration testing" are standard evidence for CC4.1 and CC7.1. Organizations without penetration testing often receive qualified opinions or control gaps.


Type I vs Type II: Testing Requirements

Understanding the difference between SOC 2 Type I and Type II is crucial for planning your penetration testing program:

SOC 2 Type I

What it covers: Design of controls at a specific point in time

Audit period: Single date (snapshot)

Penetration Testing Implications

  • One completed penetration test is typically sufficient
  • Test must be recent (within 12 months)
  • Demonstrates you have a testing control

SOC 2 Type II

What it covers: Operating effectiveness of controls over a period

Audit period: 6-12 months

Penetration Testing Implications

  • Must demonstrate testing occurred during the audit period
  • Annual testing minimum; more frequent is better
  • Auditors may sample multiple test reports if available
  • Evidence of remediation and retesting strengthens the report

The key difference: Type II auditors want to see that your penetration testing control actually operated during the audit period, not just that it exists on paper.


What SOC 2 Auditors Look For

During your Type II audit, the auditor will request evidence of your penetration testing program. Here's what they evaluate:

Testing Policy

A documented policy stating penetration testing frequency, scope requirements, and remediation expectations.

Required

Test Execution Evidence

Proof that testing occurred during the audit period. Typically the full penetration test report with dates clearly visible.

Required

Scope Coverage

Evidence that testing covered production systems, not just test environments. Scope should align with your system description.

Required

Tester Qualifications

Confirmation that testers are qualified (certifications, company reputation, or independence from your org).

Expected

Remediation Tracking

Evidence that findings were tracked, prioritized, and remediated. Jira tickets, remediation plans, or retest evidence.

Expected

Retest Verification

Evidence that critical/high findings were verified fixed through retesting, not just marked as "resolved."

Strengthens Report

Frequency and Scope Recommendations

While SOC 2 doesn't prescribe exact testing frequency, here's what best practice looks like:

Testing TypeMinimum FrequencyBest Practice
External Penetration TestAnnually
Internal Penetration TestAnnually (if applicable)Annually for internal networks/VPNs
Web Application TestingAnnuallyAfter each major release
API Security TestingAnnuallyContinuous (integrated with CI/CD)
Vulnerability ScanningQuarterlyWeekly or continuous

Scope Should Include:

All production applications in your system description
External-facing infrastructure (load balancers, APIs, CDNs)
Authentication and authorization mechanisms
Any customer-facing portals or dashboards
Third-party integrations processing customer data

Often Overlooked:

Admin panels and internal tools with production access
CI/CD pipelines and deployment infrastructure
Third-party SaaS integrations (SSO providers, payment processors)

Preparing Your Penetration Testing Evidence

To streamline your SOC 2 audit, organize your penetration testing evidence in advance:

1

Document Your Policy

Create a formal penetration testing policy that specifies annual testing, scope requirements, qualified tester criteria, and remediation timelines. Auditors will request this first.

2

Retain Full Reports

Keep complete penetration test reports for at least two years. Executive summaries alone aren't sufficient—auditors may request technical details.

3

Track Remediation

Use a ticketing system (Jira, Linear, etc.) to track findings from initial report through remediation. Export ticket history as audit evidence.

4

Document Retests

For critical and high findings, obtain formal retest evidence showing the vulnerability was verified fixed. A note in your ticketing system isn't enough.

5

Verify Tester Credentials

Request and retain evidence of your penetration testing provider's qualifications: company certifications (, SOC 2), individual tester certifications, or demonstrated experience.


Common SOC 2 Audit Findings Related to Pentesting

Auditors frequently identify these gaps in penetration testing programs. Avoid them:

Testing Conducted After Audit Period

The penetration test was completed after the audit observation period. For a Type II report covering January-December, a test conducted in January of the following year doesn't count.

Scope Mismatch

The penetration test covered different systems than those described in the SOC 2 system description. Your pentest scope should explicitly map to your SOC 2 scope.

No Evidence of Remediation

Critical findings were identified but there's no documentation showing they were addressed. Auditors expect to see remediation tracking, not just the pentest report.

Vulnerability Scan Presented as Pentest

An automated vulnerability scan report was submitted as penetration testing evidence. Auditors know the difference—pentesting requires manual testing and exploitation validation.

Internal Staff as Testers Without Independence

Penetration testing was conducted by the same team responsible for building or operating the systems. Auditors expect organizational independence between testers and system owners.


Streamlining SOC 2 Pentesting with ManticoreAI

Traditional penetration testing makes SOC 2 compliance unnecessarily difficult. Long lead times mean scrambling before audits, retesting requires new engagements, and coordinating evidence collection is manual and error-prone.

ManticoreAI simplifies SOC 2 penetration testing:

48-Hour Results

Get audit-grade results in days, not weeks. No more rushing before your audit period ends.

Audit-Ready Reports

Reports include everything auditors expect: methodology, scope, tester qualifications, findings, and evidence. Learn more about .

Unlimited Retesting

Verify remediation instantly. Generate retest evidence for every finding without scheduling new engagements.

CREST Validation

All findings validated by CREST-certified consultants. Auditors recognize and accept CREST credentials.

Continuous Evidence

Platform tracks all testing activity, findings, and remediation. Export complete audit evidence packages on demand.

Test After Changes

Run tests after major releases without procurement delays. Demonstrate continuous testing, not just annual.


Building a SOC 2-Ready Pentesting Program

Penetration testing for SOC 2 isn't just about checking a box—it's about demonstrating that your security controls actually work. The key takeaways:

  • Test annually at minimum, but more frequent testing strengthens your report
  • Align scope with your SOC 2 system description
  • Use qualified testers with recognized credentials
  • Track and remediate findings with documented evidence
  • Verify fixes through retesting, not just status updates
  • Time tests within your audit period—timing matters for Type II

With the right penetration testing partner, SOC 2 compliance becomes a natural outcome of good security practice rather than an annual scramble.

Get SOC 2-Ready Pentesting in 48 Hours

ManticoreAI delivers audit-grade penetration testing with CREST validation, unlimited retesting, and reports auditors accept without question.