SOC 220 April 2026 7 min read

SOC 2 Penetration Test Requirements: What Auditors Expect

Everything you need to know about SOC 2 penetration test requirements — frequency, scope, how to choose a vendor, and how to handle findings in your audit.

Key Takeaways

SOC 2 requires annual penetration testing under CC7.1 — this is universally expected even though it isn't explicitly named in the criteria.
The pen test must cover your in-scope systems — at minimum your production web application and external-facing APIs.
Infrastructure pen testing (cloud configuration review) is increasingly expected alongside application testing.
High and critical findings must be remediated and evidence of remediation provided to your auditor.
The pen test report and remediation tracking records are standard evidence items in every SOC 2 Type II audit.

In this guide

Why Penetration Testing Is Required for SOC 2
Scope of the Pen Test: What Must Be Tested
Choosing a Pen Test Vendor
Timing and Frequency Requirements
How to Handle Findings Before and After the Audit
Pen Test vs Vulnerability Scan: The Difference

Why Penetration Testing Is Required for SOC 2

CC7.1 requires that the entity monitors system components for vulnerabilities and detects security threats. The AICPA criterion doesn't use the words "penetration test," but in practice, auditors universally expect annual penetration testing as evidence of proactive vulnerability identification. A company that relies solely on automated vulnerability scanning without independent manual testing will receive an auditor comment on CC7.1.

The rationale is straightforward: automated scanners detect known vulnerabilities in known software components, but they cannot identify business logic flaws, chained attack vectors, authentication bypasses, or novel attack techniques. A qualified penetration tester applying manual techniques and attacker methodology identifies vulnerabilities that automated tools miss.

Enterprise customers reading your SOC 2 report also look for pen test evidence. Many customer security questionnaires specifically ask for your pen test frequency and most recent test date. A "Security criteria included in SOC 2 Type II" answer is insufficient — they want to know when the last pen test was conducted and how findings were addressed.

Scope of the Pen Test: What Must Be Tested

At minimum, the pen test must cover all external-facing surfaces of your in-scope system: the production web application, all authenticated and unauthenticated APIs, and administrative interfaces. For most B2B SaaS companies, this means an external application pen test covering the customer-facing product and its API.

Infrastructure penetration testing — reviewing your cloud configuration for misconfigurations, insecure defaults, and privilege escalation paths — is increasingly expected, especially for companies running on AWS or GCP. Cloud security assessments using tools like Prowler, ScoutSuite, or a manual cloud configuration review by a pen tester satisfy this expectation.

Internal network pen testing (assuming the attacker is already inside your network) and red team exercises are not universally required for SOC 2 but are looked upon favorably. For companies with sensitive customer data or those seeking high-security certifications, an internal pen test provides significantly stronger evidence than an external-only test.

Choosing a Pen Test Vendor

For SOC 2 purposes, the pen test must be conducted by a qualified third party — not your own security team. "Qualified" means OSCP, CEH, GPEN, or equivalent certification for the individual testers, or a firm with demonstrable experience in web application and cloud security testing.

Pen test costs for a typical B2B SaaS application: $5,000–$12,000 for an external application pen test, $8,000–$15,000 for an application plus cloud configuration review, $15,000–$30,000 for a comprehensive assessment including internal testing. Boutique pen test firms and independent OSCP-certified consultants are often more cost-effective than large security firms for focused assessments.

Ask for a sample report before engaging a pen test vendor. A good pen test report includes: an executive summary, a methodology section, findings described with CVSS scores and exploitation evidence, remediation recommendations, and an attestation letter suitable for sharing with customers and auditors. A report that is just a scanner output with no manual testing evidence will not satisfy auditor expectations.

Timing and Frequency Requirements

Annual penetration testing is the standard expectation for SOC 2. The test should be conducted within the observation period so that the report and remediation evidence fall within the period being audited. A pen test conducted 18 months before the observation period started is stale evidence.

For companies undergoing their first Type II audit with a 6-month observation period, the pen test must occur during those 6 months. For companies on 12-month annual audits, one pen test per year is sufficient. High-security environments (those handling financial data, health records, or serving regulated industries) may want to add a mid-year vulnerability assessment to complement the annual pen test.

After a major code release or infrastructure change, consider a targeted re-test of the changed components. Major changes that introduce new attack surface — a new API, a new authentication flow, a new cloud service — should be tested before they are available to customers if possible, and within the observation period in any case.

How to Handle Findings Before and After the Audit

Pen test findings are classified by severity: Critical, High, Medium, and Low. SOC 2 auditors expect all Critical and High findings to be remediated within a committed timeframe (typically 30–90 days). Medium findings should have a remediation plan with a target date. Low findings can be accepted with risk documentation.

Provide your auditor with three documents: the pen test report (from the vendor), a remediation tracking record showing each finding's status, and remediation evidence for closed findings (re-test results or configuration change screenshots). If any High or Critical findings remain open at audit time, prepare a management response explaining the delay and the compensating controls in place.

Do not attempt to conceal pen test findings from your auditor. Auditors view transparency about findings and remediation more favorably than a report with no findings (which suggests either a very limited scope or inadequate testing). A rigorous pen test that finds real issues, followed by documented remediation, is evidence of a mature security program.

Pen Test vs Vulnerability Scan: The Difference

Vulnerability scanning is automated detection of known vulnerabilities in software components — running tools like Nessus, Snyk, Dependabot, or AWS Inspector against your systems. It is fast, continuous, and excellent at finding CVEs in known software versions. It cannot find business logic flaws, chained vulnerabilities, or novel attack paths.

Penetration testing is manual, adversarial simulation of an attacker attempting to exploit your systems. A human tester uses automated tools plus manual techniques to find and prove exploitability of vulnerabilities — including those that scanners miss. The output is a narrative report describing how an attacker could compromise your systems and the evidence of exploitation.

SOC 2 requires both. Continuous vulnerability scanning (Snyk, Dependabot) satisfies the ongoing monitoring component of CC7.1. Annual penetration testing satisfies the independent assessment component. Neither substitutes for the other. A company with excellent continuous scanning but no pen test will still receive an auditor comment.

Frequently Asked Questions

How often do SOC 2 pen tests need to happen?

Annual penetration testing is the universal expectation. For a 12-month observation period, one pen test conducted during that period is sufficient. Some auditors and enterprise customers ask for semi-annual tests for high-sensitivity environments, but this is not a universal requirement. The annual test must be conducted by a qualified third party — internal security team self-assessments do not satisfy CC7.1.

Can we do a bug bounty program instead of a pen test?

A bug bounty program can complement but not replace an annual penetration test for SOC 2 purposes. Bug bounties are crowd-sourced and opportunistic — they don't provide the systematic, scoped assessment that auditors expect. The pen test report must have a defined scope, a defined methodology, and an attestation from a qualified tester. Bug bounty reports lack this structure. Include bug bounty findings in your vulnerability tracking to supplement pen test evidence.

Does the pen test report need to be shared with customers?

The full pen test report typically contains sensitive exploit details — it should not be shared publicly. The standard practice is to provide customers with: (1) a reference to the pen test in your SOC 2 report (confirming it was conducted), (2) a summary letter from the pen test firm confirming the test was conducted, the scope, the testing period, and the overall finding severity distribution, and (3) the full report under NDA to customers with strong contractual requirements.

What happens if the pen test finds a critical vulnerability right before our audit?

Disclose it to your auditor immediately and document your remediation plan. A critical finding discovered and promptly remediated is not disqualifying — it demonstrates your security testing found a real issue and you responded appropriately. A critical finding that you knew about and failed to remediate, or that you attempted to hide from the auditor, is a serious problem. Auditors appreciate transparency and evaluate your response maturity, not just the absence of vulnerabilities.

Should we do the pen test before or after starting the observation period?

Do the pen test during the observation period so that the report date falls within the audit window. Conducting the pen test before the observation period starts means it is technically outside the period being audited. However, remediating major pen test findings before the observation period starts is smart — fix known vulnerabilities first, then start the observation period with a cleaner baseline. A common approach: conduct a pre-audit pen test, remediate all high/critical findings, then start the observation period and conduct the formal in-scope pen test 6 months in.