Does SOC 2 Require a Penetration Test? What the Criteria Actually Say

Does SOC 2 require a penetration test? Not by name. The criteria never say “perform a penetration test,” and plenty of vendor blogs that claim otherwise are repeating an expectation, not quoting the text. But if you write a pentest into your controls and then skip it, your auditor will notice. This post separates what the framework says from what auditors and customers expect, so you can budget the right test at the right time.

One thing up front. NoMoreBreach is a testing firm, not a CPA or audit firm. We don’t issue SOC 2 reports or certifications, and we can’t tell you what your auditor will accept. Treat this as a plain reading of the source documents, and confirm the details with your audit firm.

The short answer: no, not as a named requirement

The SOC 2 criteria are the AICPA’s Trust Services Criteria (TSC), published as TSP Section 100. They contain no criterion that says “perform a penetration test.” They set no frequency, no methodology, and no tester qualification for one.

Pentesting does appear, as an example. It sits inside a “point of focus” under criterion CC4.1, which covers monitoring activities. We quote it below.

So why do most teams do one anyway? Three reasons:

1. It is the most direct evidence for CC4.1’s “separate evaluations,” and it supports CC7.1, the criterion on detecting vulnerabilities.
2. If your system description lists a pentest as a control, a Type 2 auditor tests that control like any other.
3. Customer security reviews often ask for pentest evidence separately from your SOC 2 report. That is our observation from the field, not a statistic.

“SOC 2 requires an annual pentest” is an expectation many auditors and customers hold. It is not text in the criteria.

How a SOC 2 report actually works

SOC 2 is an attestation report issued by a CPA firm. It is not a certification, so “SOC 2 certified” is the wrong phrase. The AICPA describes the TSC as criteria “for use in attestation or consulting engagements.”

Two distinctions matter for budgeting.

Criteria versus points of focus

The criteria are what the auditor evaluates against. Points of focus are illustrative characteristics. The AICPA’s TSC text says some “may not be suitable or relevant,” and that “use of the trust services criteria does not require an assessment of whether each point of focus is addressed.”

The AICPA re-issued the TSC in 2022 as “With Revised Points of Focus.” EY’s summary of that revision says the criteria did not change, and that every point of focus need not be met.

Type 1 versus Type 2

• A Type 2 report covers the design and operating effectiveness of controls “throughout a specified period.” It includes “a detailed description of tests of controls performed by the service auditor and the results of those tests.”
• A Type 1 report addresses the same subject matter but “does not contain an opinion on the operating effectiveness of controls nor a detailed description of tests of controls.”

The key mechanic: you write the controls in management’s description of your system. The auditor evaluates whether they meet the criteria and, for Type 2, whether they operated across the period. “Is a pentest required?” is the wrong question. Ask instead: what did we commit to, and can we evidence it?

Where a SOC 2 penetration test appears in the criteria

Here is the exact language. These quotes come from the AICPA’s 2017 Trust Services Criteria. Point-of-focus wording was revised in 2022, so we attribute these to the 2017 criteria, and the current edition may differ in wording. The official AICPA download needs a free account. The quotes below were checked against the March 2020 edition (a third-party-hosted copy of the AICPA PDF, not an AICPA link).

CC4.1: where pentesting is named

The criterion: “The entity selects, develops, and performs ongoing and/or separate evaluations to ascertain whether the components of internal control are present and functioning.”

The point of focus, “Considers Different Types of Ongoing and Separate Evaluations”: “Management uses a variety of different types of ongoing and separate evaluations, including penetration testing, independent certification made against established specifications (for example, ISO certifications), and internal audit assessments.”

Pentesting is listed alongside ISO certification and internal audit. It is one option among several, not a mandate.

CC7.1: where it is not

The criterion: “To meet its objectives, the entity uses detection and monitoring procedures to identify (1) changes to configurations that result in the introduction of new vulnerabilities, and (2) susceptibilities to newly discovered vulnerabilities.”

The point of focus, “Conducts Vulnerability Scans,” says the entity “conducts vulnerability scans designed to identify potential vulnerabilities or misconfigurations on a periodic basis and after any significant change in the environment and takes action to remediate identified deficiencies on a timely basis.”

That names vulnerability scans, not pentests. A pentest supports CC7.1, but it is not what that point of focus describes.

What the criteria do not say

They give no pentest frequency, scope, methodology, or tester credential. Any “annual” figure comes from your auditor, your customers, or your own policy.

The honest grey zone

Can a startup pass SOC 2 without a pentest? The criteria permit it if other evaluations satisfy CC4.1 and CC7.1. Whether your auditor accepts a given set of evidence is their professional judgment. Ask your audit firm early. Don’t rely on a blog, including this one.

What your auditor will test once a pentest is a control

Once your control description says you do something, it is a control. In a Type 2, the auditor’s tests and results for each described control appear in the report. Promise an “annual third-party penetration test with tracked remediation,” and the auditor will look for evidence that it happened, within the period, as described.

What auditors commonly request (industry practice, not AICPA text):

• The report or a summary, with test dates inside the audit period
• Scope that matches the system in your SOC 2 description: the production app, its APIs, and the supporting cloud infrastructure, not just the marketing site
• Findings tracked to remediation: tickets, and documented risk acceptance where you chose not to fix
• Retest evidence for fixed high-severity findings

Here is what that looks like on paper. Illustrative mock-up, not from a real report. The wording is fictional and is not the AICPA’s format or any audit firm’s.

ILLUSTRATIVE MOCK-UP - NOT FROM A REAL REPORT

CONTROL (as written in management's system description)
  CC4.1-03  An independent third party performs a penetration test of the
            production application, APIs and supporting cloud environment
            at least annually. Findings rated high or critical are tracked
            in the ticketing system and remediated or formally risk-accepted.

SERVICE AUDITOR'S TEST (Type 2)
  - Inspected the penetration test report dated within the review period
    and compared its stated scope to the system description.
  - Inspected tickets for high/critical findings for evidence of
    remediation, retest, or documented risk acceptance.

RESULT
  Version A: No exceptions noted.
  Version B: Exception noted. Test was performed 14 months after the
             prior test; two high findings had no ticket or acceptance.

Version B is not a “failed pentest.” It is a failed control. The cause is writing “annually” and then not doing it, or not tracking the fixes. Write controls you will actually operate.

A note on Type 1. It is point-in-time and carries no opinion on operating effectiveness. A pentest done before a Type 1 still shows the control is designed and in place. It also gives you a baseline to fix against before the Type 2 window opens.

PCI DSS 11.4, HIPAA penetration testing, and ISO 27001 compared

Here is how SOC 2 compares with the other frameworks buyers ask about.

PCI DSS 11.4: the one hard requirement

PCI is the only framework in the table where a pentest is a hard, written requirement. Cite PCI DSS v4.0.1, not “4.0,” and not a vendor summary.

• Tester rules. The tester must be a “qualified internal resource or qualified external third party,” with “organizational independence of the tester.” They do not need to be a QSA or ASV.
• Methodology. PCI’s guidance names OSSTMM and OWASP penetration testing programs among industry-accepted approaches. It does not name NIST SP 800-115.
• Multi-tenant service providers. Requirement 11.4.7 says you must support your customers’ external pentesting. Fintech infrastructure startups should read it.
• SAQ A is different. A merchant on SAQ A (fully outsourced redirect or iframe checkout) has quarterly scans but no 11.4 pentest. Which SAQ applies is decided with your acquirer or payment brand, so don’t self-select from a blog post.

PCI SSC also ran a request for comments on the standard in mid-2026. As of this writing, v4.0.1 remains the published version, per PCI SSC’s own blog.

HIPAA penetration testing: proposed, not law

This is where vendor blogs get it most wrong. Several call a HIPAA pentest “mandatory” or the new rule “final.” Neither is true.

Today’s Security Rule asks for a risk analysis and a “periodic technical and nontechnical evaluation” (45 CFR 164.308). It applies to business associates too (164.302), and it lets you scale your approach to your size, complexity, and risk (164.306).

In January 2025, HHS published a proposed rule that would add vulnerability scans every six months and penetration testing every 12 months by a qualified person. As of 20 October 2026, a Federal Register search for that rule’s identifier returns only the proposal. No final rule has been published.

If you are a business associate, treat the proposal as a strong direction of travel and a sensible thing to get ahead of. It is not current law, and agency timeline projections are not deadlines.

How to scope one pentest that serves the auditor, your customers, and reality

The smart move isn’t “do the minimum the auditor accepts.” It’s to buy one test that satisfies the auditor, answers your customers’ security reviews, and shows what an attacker would actually see. Here is how to scope it.

• Scope to your SOC 2 system boundary, not your homepage. That means the production web app, its APIs (authenticated, with at least two roles or tenants so authorization flaws can be tested), the cloud control plane, and your internet-facing attack surface.
• Time it inside the audit window, early enough to fix and retest high-severity findings before the period closes.
• Insist on remediation tracking and retest. PCI 11.4.4 says “penetration testing is repeated to verify the corrections.” For SOC 2, retesting is what turns findings into evidence that your control operated.
• Get a clear answer on independence. PCI requires it. For SOC 2, it is what makes the test credible as a “separate evaluation.” An internal team can test, but you need a clean answer to “who checked their work?”
• Ask for a methodology you can name. Examples: the OWASP Web Security Testing Guide (current stable version 4.2), NIST SP 800-115, or OSSTMM.

Trade-offs worth being honest about

• Scanner versus pentest. A vulnerability scan maps directly to the CC7.1 point of focus and costs less. It does not find authorization and business-logic flaws, such as IDOR, where changing an ID in a request returns another customer’s data. Many teams need both: scans continuously, a pentest periodically.
• Annual versus change-driven. SOC 2 sets no cadence. PCI and the HIPAA proposal both pair 12 months with “after significant change” or the risk analysis. If you ship a major new product surface mid-year, that is a reason to test again, whatever the calendar says.
• Breadth versus depth. A fixed budget spread across every asset produces shallow results. Prioritize systems that hold customer data and your authentication and authorization paths.
• Report versus summary letter. Customers often want more than a one-page letter. Plan to share a redacted report or executive summary under NDA. See our sample report for what a full technical report looks like. If you also want a short pentest summary letter for quick questionnaires, ask for one, but it is a summary of our testing, not an attestation in the AICPA sense.

A two-minute self-check

1. Does your SOC 2 control list promise a pentest? At what frequency, and will you actually meet it inside the audit period?
2. Does the pentest scope match the system in your SOC 2 description (app, APIs, cloud), or just the public website?
3. Do you have tickets showing every high or critical finding was fixed and retested, or formally risk-accepted?
4. Do you take card data in a way that puts you under full PCI DSS rather than SAQ A? If so, 11.4 is not optional.
5. Are you a HIPAA business associate? Plan for the proposed 12-month pentest, even though it isn’t law yet.

Planning a SOC 2 Type 1 or Type 2? Book a scoping call. We’ll map a pentest to your actual system boundary and audit window, so the report works for your auditor and for the customer questionnaire that comes next.

Not sure what your external surface looks like before the auditor or a customer asks? Start with the free external attack-surface snapshot. It needs no access and costs nothing.

NoMoreBreach is a testing firm, not a CPA or audit firm. We don’t issue SOC 2 reports or certifications, and we don’t say what your auditor will accept.