SOC 2 Penetration Testing Requirements 2026: What Auditors Actually Expect

Does SOC 2 Require Penetration Testing?

SOC 2 does not explicitly mandate penetration testing in its written criteria — but in 2026, auditors overwhelmingly expect it. Under CC4.1 of the AICPA Trust Services Criteria, organizations must demonstrate ongoing risk identification and that security controls are present and functioning. A scoped, third-party penetration test is the most accepted evidence for satisfying that expectation. Without one, expect your auditor to ask for it.

Table of Contents

1. What CC4.1 Actually Means in Practice
2. What SOC 2 Auditors Expect to See in a Pentest Report
3. Scope: What Must Be Tested
4. Timing: When to Run the Test
5. What Disqualifies a Pentest
6. How SecurityWall's SOC 2 Pentest Works
7. Book a SOC 2 Pentest Consultation

What CC4.1 Actually Means in Practice

The AICPA's Trust Services Criteria CC4.1 states that an organization must:

"...use a variety of types of ongoing and separate evaluations to ascertain whether the components of internal control are present and functioning."

In plain English: you need evidence that your security controls are actually working not just documented. Penetration testing is the clearest, most auditor-accepted form of that evidence for the security category (CC series criteria).

In practice, CC4.1 maps to three auditor expectations:

1. You identified your risks. A scoped pentest demonstrates that you've actively tried to find exploitable weaknesses across your attack surface not just theorized about them in a risk register.

2. You tested whether controls hold. Firewalls, authentication mechanisms, access controls, and encryption are only meaningful if they resist real-world attack attempts. A pentest validates that.

3. You responded to findings. Auditors want to see that vulnerabilities were remediated and retested not just logged. A report with open critical findings and no retest evidence is a red flag, not a green light.

CC4.1 is not the only criteria touched by a pentest. A well-scoped engagement also supports CC6.1 (logical access), CC6.6 (external threats), CC7.1 (system monitoring), and CC9.1 (risk mitigation) making pentesting one of the highest-leverage activities in your SOC 2 preparation.

What SOC 2 Auditors Expect to See in a Pentest Report

Not all pentest reports satisfy SOC 2 auditors. Here's specifically what they look for, mapped to the Trust Services Criteria:

Methodology and Tester Qualifications

Auditors want to see that testing was performed by a qualified, independent third party not your internal team. The report should document the testing methodology (e.g., OWASP, PTES, NIST SP 800-115), tester credentials, and the dates of engagement. Vague methodology sections are a common reason auditors request supplemental evidence.

Scope Coverage (Tied to CC6.6 and CC6.1)

The scope must cover all systems that store, process, or transmit in-scope data. Web applications, APIs, cloud infrastructure, internal networks, and authentication systems are all expected to be addressed. Auditors will cross-reference your scope against your system description if systems appear in the description but not in the pentest scope, expect a finding.

Findings with Business Impact Context (CC7.1)

Each vulnerability should be documented with a severity rating, evidence of exploitability (screenshots, proof-of-concept details), and clear business impact language. CVSS scores alone are insufficient auditors want to understand what an attacker could actually do if they exploited the vulnerability.

Remediation and Retest Evidence (CC4.1)

This is the section most organizations fail on. Auditors need to see that critical and high findings were remediated within a reasonable timeframe, a retest was performed to confirm fixes hold, and the retest was documented not just verbally confirmed. An open critical finding with no retest evidence will typically result in an auditor exception or a qualified opinion.

Executive Summary and Risk Rating

A document-level risk rating (Overall: High / Medium / Low) and an executive summary make it easy for auditors to assess posture at a glance. Reports that require the auditor to read every finding to form an opinion create friction and slow down the review.

Scope: What Must Be Tested

SOC 2 pentest scope should follow your system boundary the systems described in your System Description document. If it's in the boundary, it should be in the pentest.

In practice, for most SaaS and cloud-native companies this means:

Web Applications — Your core product, admin panels, customer portals, and any web interface that accesses in-scope data. This includes authentication flows, session handling, authorization logic, and data exposure risks.

APIs — REST, GraphQL, and internal microservice APIs are frequently the highest-risk attack surface in modern stacks. API testing must go beyond automated scanning it requires manual testing of business logic, authentication bypass, and data exposure chains.

Cloud Infrastructure — AWS, GCP, and Azure misconfigurations are among the most commonly exploited vectors in real-world breaches. IAM policies, S3 bucket exposure, Lambda function permissions, and network security group rules should all be in scope.

Internal Network and Privileged Access — If your auditors are assessing CC6.1 (logical access controls), they expect to see testing of internal segmentation, privileged account exposure, and lateral movement potential.

Authentication and Session Management — MFA implementations, password policies, OAuth flows, and token handling are directly relevant to CC6.1 and CC6.3. These must be specifically tested, not assumed to be covered by web app testing.

Timing: When to Run the Test

Timing is one of the most commonly misunderstood aspects of SOC 2 pentest compliance.

The audit period matters. Your pentest must fall within or close to your SOC 2 audit period. A test conducted 18 months before your audit review is unlikely to satisfy auditors environments change, and stale results don't demonstrate current control effectiveness.

The recommended window is 3–6 months before your audit. This gives you enough time to remediate critical findings, complete retesting, and present a clean report to auditors without rushing.

For SOC 2 Type II, recurrence matters. A Type II audit covers a period of time (typically 6–12 months). Auditors increasingly expect evidence of ongoing security monitoring throughout that period not just a single snapshot test at the start. This is one of the strongest arguments for a continuous PTaaS model alongside a formal annual pentest.

Don't test before major architecture changes. If you've migrated cloud providers, launched a new product, or significantly changed your infrastructure, a pentest performed before those changes may not cover your current attack surface. Timing your test after major changes ensures results are accurate.

What Disqualifies a Pentest

Auditors have seen everything. These are the scenarios that result in rejection or supplemental evidence requests:

Automated scanner reports submitted as pentests. Vulnerability scan output (Nessus, Qualys, Tenable) is not a penetration test. If your report doesn't show evidence of manual exploitation, chained vulnerabilities, or tester commentary on business logic it will be identified as a scan, not a test.

Tests performed outside the audit period. Results older than 12 months, or tests performed before the audit period began, will typically not satisfy auditors for the period under review.

Missing retest evidence. If critical or high findings appear in your report with no documented remediation or retest, auditors cannot confirm that controls are functioning. This is one of the most common reasons organizations receive qualified SOC 2 opinions.

Scope gaps that don't match the system description. If your system description includes a customer-facing API but the pentest scope only covers the web application, the mismatch will be flagged.

Internal team testing. Independence matters in audit. A pentest performed by your own engineering or security team even if technically competent lacks the independence auditors expect from a third-party assessment.

No methodology documentation. A report that summarizes findings without explaining how testing was conducted, what tools were used, and what was out of scope gives auditors nothing to verify. Methodology transparency is a basic quality threshold.

How SecurityWall's SOC 2 Pentest Works

SecurityWall's penetration testing practice is structured around audit requirements not just vulnerability discovery.

Every SOC 2 pentest engagement includes:

Scoping aligned to your system boundary. We map your pentest scope directly to your System Description before testing begins, ensuring no gaps between what auditors review and what was tested.

Human-led testing across your full stack. Web applications, APIs, cloud infrastructure, internal network, and authentication systems are all covered by certified testers not just automated tooling. Our testers hold OSCP, CEH, and CREST credentials.

Real-time findings on the SLASH platform. Rather than waiting for a final PDF at engagement close, your security team sees findings as they're discovered on SLASH allowing remediation to begin immediately and reducing the window between discovery and fix.

Retest included. Critical and high findings are retested as part of every engagement. Retest evidence is documented in the platform and exportable for auditor review.

Audit-ready report format. Our reports are structured with auditors in mind: executive summary, methodology documentation, findings mapped to Trust Services Criteria, severity ratings with business impact context, and a clear remediation status section.

Proven with real auditors. One of our clients a SaaS company undergoing their first SOC 2 Type II audit had their SecurityWall pentest report accepted by their auditor without supplemental evidence requests. The engagement covered their web application, API layer, and AWS infrastructure, with all critical findings remediated and retested before the audit window closed.

For organizations that need ongoing assurance throughout a Type II audit period, SLASH extends the pentest into a continuous PTaaS model with persistent monitoring, recurring testing cycles, and live risk posture reporting that auditors can review at any point in the audit period.

Learn more about our broader SOC 2 compliance services and how we support organizations from gap assessment through audit.

Also relevant: SOC 2 Penetration Testing Requirements for Dutch SaaS Companies a deeper look at how these requirements apply in EU-regulated contexts.

Bottom Line

SOC 2 doesn't print "penetration testing required" anywhere in its criteria. But in 2026, showing up to an audit without a credible, scoped, third-party pentest with remediation evidence is a risk most organizations can't afford to take.

What auditors actually expect: a qualified, independent third-party test; scope that matches your system boundary; findings with business impact context and severity ratings; documented remediation and retest evidence; and a report date that falls within or near the audit period.

Get those five things right, and your pentest becomes a compliance asset. Get them wrong, and it becomes an auditor conversation you don't want to have.