Does SOC 2 explicitly require a penetration test?

No. The AICPA Trust Services Criteria do not use the words 'penetration test' anywhere in the standard. However, criteria CC7.1 and CC4.1 require organizations to identify vulnerabilities through testing and monitoring. In practice, every SOC 2 auditor interprets this as requiring a third-party penetration test.

What happens if I skip the pentest for my SOC 2 audit?

Your auditor will almost certainly flag it as a gap. Without a penetration test, you cannot demonstrate that you have tested your controls against real-world attack scenarios. This typically results in a qualified opinion or exceptions noted in your SOC 2 Type II report, which enterprise customers and prospects will scrutinize.

What should a SOC 2 penetration test report include?

A SOC 2 pentest report should include an executive summary, detailed methodology, scope definition mapping to Trust Services Criteria, findings classified by severity with CVSS scores, evidence of testing, remediation guidance and a retest summary confirming fixes. The report must be conducted by an independent third party.

How often do I need a penetration test for SOC 2?

SOC 2 Type II covers a review period of 6 to 12 months. Most auditors expect at least one penetration test per audit period. For SaaS companies with frequent releases, we recommend testing annually at minimum and after any major architectural change.

Does SOC 2 Require a SaaS Pentest?

The Short Answer

No, SOC 2 does not require a penetration test. The word "penetration" does not appear in the AICPA Trust Services Criteria. But if you show up to your SOC 2 audit without one, your auditor will flag the gap. Every CPA firm we work with treats a third-party pentest as a de facto requirement. The distinction between "required by the standard" and "required by the auditor" matters only in theory.

What the Trust Services Criteria Actually Say

The relevant criteria live in two places. Understanding exactly what they say helps you build the right testing program instead of guessing at what your auditor wants.

CC4.1: Monitoring Activities: The entity selects, develops and performs ongoing and/or separate evaluations to ascertain whether the components of internal control are present and functioning. This is where auditors expect to see evidence of security testing, including penetration testing, as proof that your controls work under adversarial conditions.
CC7.1: System Operations Monitoring: The entity uses detection and monitoring procedures to identify changes to configurations that result in new vulnerabilities, and susceptibilities to newly discovered vulnerabilities. Auditors interpret this as requiring proactive vulnerability identification. A penetration test satisfies this criterion directly.
CC7.2: Security Incident Monitoring: The entity monitors system components for anomalies that are indicative of malicious acts, natural disasters and errors. While not directly about pentesting, a pentest report demonstrates that you have tested your detection capabilities against simulated attacks.

The language is deliberately broad. The AICPA designed it that way so organizations can choose controls appropriate to their environment. But that flexibility creates ambiguity, and auditors resolve ambiguity conservatively. A penetration test is the clearest evidence you can provide.

Why Auditors Flag You Without One

SOC 2 auditors evaluate whether your controls are designed effectively and operating as intended over the review period. A vulnerability scan shows you checked for known issues. A penetration test shows you attempted to break the controls and they held. That distinction matters to auditors because it maps directly to the "operating effectiveness" requirement in a Type II report.

Here is what typically happens when a SaaS company enters its first SOC 2 audit without a pentest:

SOC 2 Audit Outcomes: With vs. Without a Penetration Test
Scenario	Auditor Response	Impact on Report
Third-party pentest with remediation evidence	Clean pass on CC4.1 and CC7.1	No exceptions noted
Vulnerability scan only, no pentest	Gap identified, additional evidence requested	Possible exception or qualified opinion
No security testing at all	Control deficiency flagged	Exception noted in report
Internal pentest, no third-party validation	Independence concern raised	Auditor may request external retest

An exception on your SOC 2 report is not fatal. But enterprise customers read these reports carefully. An exception related to security testing signals that you have not validated your own controls, and that is a difficult conversation to have during a sales cycle.

What Your Pentest Report Needs to Include

Not every penetration test report satisfies a SOC 2 auditor. We have seen companies submit automated scan output labeled as a "pentest" and get rejected. Your report needs specific elements to pass audit review.

Independence: The test must be performed by an independent third party. Internal security teams testing their own systems does not satisfy the auditor's requirement for objectivity. The testing firm should have no operational role in managing your infrastructure.
Scope Aligned to TSC: The scope should explicitly reference which Trust Services Criteria the testing addresses. A report that says "we tested the web application" is insufficient. It needs to confirm that testing covered the systems and controls relevant to your SOC 2 boundary. See our guide on what to include in SaaS pentest scope for details.
Methodology Documentation: The report must describe the testing methodology, tools used, testing timeframe and tester qualifications. Auditors want to verify that the test was systematic rather than ad hoc.
Findings with Severity Ratings: Every finding should include a severity classification (Critical, High, Medium, Low, Informational) with CVSS scores. Auditors use severity ratings to assess whether identified vulnerabilities represent control failures.
Remediation Evidence: If the pentest identified vulnerabilities, the report should include evidence that findings were remediated and retested. Open critical or high findings at audit time will draw scrutiny. For a complete checklist, see our SOC 2 pentest checklist for CPAs.

Pentest vs. Vulnerability Scan: The Auditor Knows the Difference

A vulnerability scan runs automated tools against your systems and produces a list of known issues. A penetration test uses those same tools as a starting point, then applies manual techniques to chain vulnerabilities together, test business logic flaws and attempt to bypass controls in ways that automated tools cannot.

SOC 2 auditors understand this distinction. Submitting a Nessus or Qualys report and calling it a penetration test will not pass review. Your auditor will ask pointed questions about manual testing, methodology and tester qualifications. If you cannot answer them, the auditor treats it as a gap.

Timing Your Pentest for SOC 2

Your penetration test needs to fall within the audit review period. For a SOC 2 Type II report covering January through December, a pentest conducted the previous November is outside the window. The auditor needs evidence that testing occurred during the period under examination.

We recommend scheduling your pentest in the first half of the review period. This gives you time to remediate findings and conduct retesting before the audit fieldwork begins. If your review period ends in December, schedule the pentest for Q2 or Q3. This approach gives your engineering team a realistic runway to address findings without rushing fixes in the final weeks before audit.

What SaaS Companies Specifically Need

SaaS applications carry risks that traditional on-premises software does not. Your SOC 2 pentest should cover the attack surface that matters to your customers and your auditor.

At minimum, the pentest scope for a SaaS company should include multi-tenant data isolation testing, API security assessment, authentication and authorization review, session management testing and an evaluation of third-party integrations. These areas map directly to the Trust Services Criteria and address the questions your enterprise customers will ask when they review your SOC 2 report.

For a detailed breakdown of SaaS-specific testing methodology, see our complete guide to SaaS penetration testing. For scoping specifics, read what to include in SaaS pentest scope.

The Bottom Line

SOC 2 does not require a penetration test in the literal text of the standard. Every SOC 2 auditor expects one. Treating it as optional is a gamble that costs more in audit delays, report exceptions and lost deals than the test itself. Schedule it early in your review period, use an independent firm, and make sure the report maps findings to Trust Services Criteria. That is what passes audit.

Wondering what a pentest will actually cost? View transparent pricing from $1,500.

If you need a SOC 2-ready penetration test for your SaaS application, we deliver reports that auditors accept without pushback.