Get a free check
Get my free check
  • Free
  • No card
  • Your signed OK first
Articles

Does SOC 2 require a pentest?

Nov 7, 2026 · 8 min read · SOC 2

No. The AICPA’s Trust Services Criteria, which SOC 2 examinations are measured against, don’t mandate a penetration test or any other specific control. Penetration testing appears as one example in a “point of focus” under criterion CC4.1, and the criteria state that their use “does not require an assessment of whether each point of focus is addressed.” In practice, many enterprise customers ask for a recent pentest anyway, and if you skip one your auditor will want to see what you do instead.

On this page9 sections

What do the SOC 2 criteria say about penetration testing?

The criteria mention penetration testing once, as an example of how a company might monitor its controls. It sits under CC4.1, a monitoring criterion that reads: “The entity selects, develops, and performs ongoing and/or separate evaluations to ascertain whether the components of internal control are present and functioning.”

Under CC4.1, the 2017 Trust Services Criteria (as updated in March 2020) list this 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.

The AICPA republished the criteria with revised points of focus in 2022. Drata quotes the revised wording of the same point of focus, which lists penetration testing alongside vulnerability scans, security assessments, internal audit and third-party assessments as evaluations that “may” be included “depending on the entity’s objectives.”

Points of focus are guidance about what a criterion looks like in practice. The criteria document says they “represent important characteristics of the criteria” and “may assist” management and the auditor, and then: “Some points of focus may not be suitable or relevant to the entity or to the engagement to be performed.” The sentence that settles the question comes right after: “Use of the trust services criteria does not require an assessment of whether each point of focus is addressed.”

Vulnerability scanning gets its own point of focus under CC7.1 (system operations): “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 is also a point of focus, not a mandated control.

Why do so many people say SOC 2 needs a pentest?

Because the people reading your SOC 2 report often expect one. Mike DeKock, a CPA who works on SOC reports, writes on the Cloud Security Alliance blog that there are “no explicit requirements for penetration testing (or any controls) within a SOC 2 report,” and in the same piece that penetration testing “is the most common requirement we hear as the last component to close a deal with an enterprise customer (along with having a SOC 2 report).”

Drata’s GRC team makes the same split. Their post opens with “Penetration tests are technically not a requirement for SOC 2 compliance,” then spends most of its length on what it calls tradition: “Many organizations expect or require (through contractual obligations) their vendors to periodically conduct penetration tests.” If others in your market include pentests in their SOC 2 reports, Drata says, “your customers and prospects may expect you to have conducted them as well.”

There is also a simple case where a pentest stops being optional. DeKock’s first question is whether any customer contract requires one: “If yes, then it’s required.” That requirement comes from your contract, not from SOC 2.

What will your SOC 2 auditor look for?

Your auditor checks whether the controls you picked are enough to meet each criterion for your risks, and a pentest is one common way to show that for CC4.1. Drata describes the auditor’s job as evaluating “the sufficiency in the selection of controls” as well as how they are designed and, often, whether they operate effectively.

If you choose not to run a pentest, the question moves to what you do instead. Drata writes that auditors “will likely scrutinize your decision-making process and assess your selection of alternative evaluations against your risk assessment,” and that “the onus is on you to demonstrate how your selected controls are sufficient.” The alternatives it lists for smaller teams include vulnerability scanning, regular code reviews, red-team exercises and dynamic application security testing (DAST).

The criteria also leave the shape of a pentest to you. Per Drata, if you do include one, you choose the frequency, the type (external or internal, black-box or white-box) and the scope (web application, network and so on). Ask your auditor early which evaluations they expect to see for CC4.1 in your environment, before you buy anything. Their answer for your system matters more than any vendor blog, this one included.

What enterprise customers and security questionnaires ask

Enterprise security reviews often ask about penetration testing directly, separate from whether you have a SOC 2 report. Drata’s post lists what can happen when buyers expect a pentest and your report doesn’t show one: longer security questionnaires and requests for extra artifacts, a prospect demanding “an ad-hoc penetration test under a tight deadline as a prerequisite to close a deal,” or losing a competitive deal to a vendor who has one.

The same post ends with the customer who prompted it. After reviewing their recent security questionnaires, “virtually all of them included a question about their most recent penetration testing,” and they commissioned an external test during their SOC 2 observation period. That is one company’s experience, but it matches the CSA piece’s point about enterprise deals.

If you’re preparing for your first enterprise review, be ready to say when your last test was, who ran it, what was in scope, and whether high-severity findings were fixed. The security questionnaire guide goes through which answers a pentest letter supports and which it doesn’t.

Is a vulnerability scan enough for SOC 2?

Sometimes, depending on your risks, your auditor and your customers. The criteria don’t rank evaluations, and Drata names vulnerability scanning and DAST as alternatives some smaller organizations choose instead of a pentest.

The difference shows up in what each one can find. A scanner checks for known issues and misconfigurations, and the CC7.1 point of focus covers running scans periodically and after significant changes. A penetration test has a person trying to break the application’s own rules, such as whether one customer can read another’s records or whether a paid feature can be reached without paying. A scanner has no way to know those rules, so it won’t report when they break. You can also do both: scans on a schedule, and a pentest before an audit window or a large enterprise deal.

What a pentest letter of attestation states, and what it doesn’t

A letter of attestation is a short summary of a pentest that you can share with customers and your auditor without handing over the full report. It is evidence that testing happened. It isn’t a SOC 2 report, which is an assurance report issued by a CPA under the AICPA’s SOC framework.

Shipmate’s sample letter shows what ours contains:

  • Scope: each target tested (web app, API routes and server actions, source at a named commit, database policies, payment integration) and the environment, plus what was out of scope.
  • Dates: testing window, when fixes were merged, and the retest date.
  • Method: manual testing and source review, automated checks verified by hand, a two-account test for cross-user access, and the severity scale used.
  • Findings and status: each finding with its severity and its status at retest (fixed and retested, accepted risk, or open).

It also states its limits. The letter covers only the listed scope and dates; a pentest is time-boxed and doesn’t show an application is free of vulnerabilities; and in the sample’s words, “This letter is not a certification, a SOC 2 report or an audit opinion. Whether it meets a customer’s, auditor’s or framework’s requirements is for that party to decide.”

That last line is worth checking for in any letter you buy. A vendor can describe what it tested. Whether that satisfies your auditor or a customer’s review is their decision, and a letter that claims otherwise is overselling.

What to ask before you buy a pentest for SOC 2

Before you sign, confirm the test will produce evidence your auditor and customers can use. A short list to bring to any vendor:

  1. Does the scope match the system described in your SOC 2 report? A test of the marketing site doesn’t cover the app.
  2. Is there a retest after fixes, and does the letter show each finding’s status at retest?
  3. Will you get both a full report (for you and your auditor) and a shareable letter (for customers)?
  4. Does the letter state dates, scope and method plainly, and say what it is not?
  5. Does the test cover the application’s own logic, such as access between accounts, roles and billing, or only known-vulnerability checks?
  6. If you’re in a Type 2 observation period, does the testing date fall inside it? Ask your auditor whether that matters for your report.

Where Shipmate fits

Shipmate’s Pentest tier is a fixed-price review for apps built on Next.js, Supabase and Stripe, often with AI coding tools. It includes manual testing and source review, fix pull requests, a retest, and a letter of attestation in the format above. The letter is evidence of testing for your SOC 2 auditor and enterprise security reviews; it is not a certification, and your auditor and customers decide what it satisfies. Testing starts only with written permission from the app’s owner.

Sources