Does SOC 2 Require a Penetration Test? What Auditors and Buyers Actually Ask For

The question usually arrives in a spreadsheet. Row 84 of an enterprise security questionnaire: "Provide your most recent third-party penetration test report." The deal is waiting on the answer, and the founder is trying to work out whether SOC 2 even required one.

Short answer: SOC 2 does not strictly require a pentest. PCI DSS does. ISO 27001 does not name one but expects the evidence a pentest produces. HIPAA may soon require it. And the buyer asking in row 84 does not care which framework you cite.

The audit decides whether a pentest is mandatory. The sales cycle decides whether you need one.

SOC 2 penetration testing: a point of focus, not a rule

SOC 2 is built on the AICPA Trust Services Criteria. Penetration testing appears under CC4.1, the monitoring criterion, as one example of a "separate evaluation" alongside internal audit and ISO certification. Points of focus show how a criterion might be met. They are not requirements of their own. CPA firm Linford & Co puts it plainly: a pentest is not required to meet the criteria.

CC7.1 adds vulnerability scanning, periodically and after significant change. That is a scanner job, and a separate activity from a pentest.

In practice the gap closes fast. You design your own controls in SOC 2, and "we test the application for exploitable flaws at least once a year and after major changes" is the control most auditors expect to see. If you leave it out, you are left defending why monitoring is sufficient without it. And your customers will ask for the report regardless of what your auditor accepted.

What the other frameworks say

FRAMEWORK        PENTEST?               CADENCE
---------        --------               -------
PCI DSS 4.0.1    Required (11.4)        12 months + after
                                        significant change,
                                        retest after fixes
DORA             Required for in-scope  Yearly testing;
                 financial entities     TLPT every 3 years
                                        if designated
SOC 2            Point of focus         Expected yearly
                 (CC4.1)                in practice
ISO 27001:2022   Not named; usual       Set by your risk
                 evidence for A.8.8     treatment
                 and A.8.29
HIPAA (today)    Not named              "Periodic evaluation"
HIPAA (proposed) Would be required      12 months; scans
                                        every 6 months
NIST 800-53      CA-8, High baseline    Org-defined
NIS2             Risk-based testing     Org-defined

PCI DSS is the strictest. Version 4.0.1 took over from 4.0 at the end of 2024, and its future-dated requirements became mandatory on 31 March 2025. Requirement 11.4, reproduced in Microsoft's PCI guidance, wants a documented methodology, internal and external tests at least every 12 months and after significant change, application-layer testing for the flaws listed in 6.2.4, and a retest proving that exploitable findings were fixed. The tester must be organizationally independent. Service providers test segmentation every six months.

ISO/IEC 27001:2022 leaves the method to you. Annex A 8.8 covers managing technical vulnerabilities and 8.29 covers security testing during development and acceptance. The ISO 27002 guidance, summarized by ISMS.online, points to code review, scanning and penetration tests. A certification auditor will want to see that the controls you selected actually run. A pentest report is the most common proof.

HIPAA is in motion. Today's Security Rule (45 CFR 164.308) asks for a risk analysis and periodic evaluation without naming a method. The January 2025 proposed rule, summarized by Faegre Drinker, would add a penetration test every 12 months and vulnerability scans every six. It is not final. HHS's regulatory agenda now lists it as a long-term action with an estimated July 2027 date. Health-tech buyers are already asking as if it passed.

In the EU, DORA Article 24 requires financial entities to test systems supporting critical functions at least yearly, and Article 26 adds threat-led testing every three years for designated firms. If you sell to a bank, that reaches you through the contract, not the regulation.

The buyer is the real auditor

Security review is where B2B deals stall. G2's 2026 buyer behavior research found 39% of software buyers named IT security review as the biggest delay after choosing a vendor, rising to half among enterprise buyers. The Cloud Security Alliance's CAIQ, one of the standard questionnaires, asks directly whether independent third parties run penetration tests on a regular schedule.

A buyer's security team reads the report differently from your auditor. They want to know it covered the product they are buying, that it is recent, and that the serious findings are closed. A two-year-old PDF about an app you rewrote does not answer any of those.

What evidence to hand over

PCI's requirements are a good template even if you never touch card data, because they describe what makes a report credible to anyone.

PENTEST EVIDENCE PACK

[1] Who tested
    Independent of the team that built it.
    A named person signs the report.

[2] What was in scope
    The addresses and repositories tested match
    the product the buyer is evaluating.

[3] When
    Dated within the last 12 months, and after
    your last major change.

[4] How
    Methodology stated: what was tested, from
    where, with what access.

[5] What was found
    Findings ranked by severity, each with proof
    it was exploitable.

[6] What you did about it
    Remediation per finding, and a retest showing
    the high and critical ones are closed.

[7] Kept on file
    Results and remediation records held at least
    12 months.

Items 1 and 6 are where startups lose credibility. An internal engineer testing their own code is not independent. A findings list with no proof of remediation reads like an open issues list. Run the test early enough to fix what it finds, then run it again.

Scope deserves care too. Georgia Weidman's Penetration Testing treats pre-engagement and scoping as part of the test, not paperwork before it. A report is only evidence for the systems named in it. If the buyer's data lives in an API that was not in scope, the report does not cover their risk.

Where GhostProbe fits, and where it does not

GhostProbe tests web applications and APIs on staging or preproduction addresses you own, with optional source review. It is a strong fit for SOC 2, ISO 27001 and buyer questionnaires, where what matters is an independent, recent, human-signed test of the product. It does not test internal networks, segmentation, or production. If you are a PCI service provider that needs network-layer and segmentation testing of the cardholder data environment, you still need an engagement that covers those.

The Pentest job is $1,490 for up to four addresses, with up to 2 GitHub repositories if you want the source read too. Recon is $490 for one address. Every finding is reproduced by a security engineer, ranked, paired with a fix, and the dossier carries their name. Packs of 6 or 12 runs make the retest after remediation, and the test after your next big release, part of the plan instead of a new purchase order.

Have the report ready before row 84 arrives.