State of SOC 2 Penetration Testing — 2026.

Why this report exists

Two facts moved in opposite directions over the past 18 months. First, the share of Series A SaaS companies pursuing SOC 2 Type II as their first compliance milestone has continued to expand — driven by enterprise procurement, not regulation. Second, the published guidance on what a SOC 2 penetration test should cover has stayed almost stationary at the standards level. The AICPA Trust Services Criteria last updated their Points of Focus in 2022 [1]. The OWASP API Top 10 last updated to version 2023 [2]. PCI DSS reached v4.0.1 in June 2024 [3].

The gap between these two — a growing buyer population and a stable standards floor — has produced predictable confusion about what a SOC 2 pentest actually is in 2026. This report is our attempt to consolidate what we see across engagements, mapped against the standards. We follow a strict editorial rule: every quantitative claim links to a primary source. Where we cite our own engagement data, we label it as such and present it in ranges.

1. The compliance overlap is wider than buyers expect

Most Series A SaaS buyers we talk to in 2026 are not pursuing SOC 2 in isolation. The typical pattern is SOC 2 first, ISO 27001 within 18 months, with a healthy minority also carrying HIPAA (healthtech) or PCI DSS (any payment processing). Across our engagements, more than two-thirds of customers carry two or more frameworks simultaneously [CyberGuards engagement data, 2024-2026 — [NEEDS CG DATA VERIFICATION]].

What this means for pentest scope: the test itself is largely identical across frameworks, but the report mapping is not. The AICPA 2017 Trust Services Criteria specifically reference penetration testing in the Points of Focus for CC4.1 (Selects, develops, and performs evaluations) and again in the 2022 Revised Points of Focus for CC7.1 (Detection of vulnerabilities) [1]. ISO/IEC 27001:2022 Annex A lists controls 8.8 (Management of technical vulnerabilities), 8.29 (Security testing in development and acceptance), and 8.34 (Protection of information systems during audit testing) [4]. PCI DSS v4.0.1 Requirement 11.4 specifies external, internal, and segmentation testing with explicit cadence [3].

The practical effect: a single pentest engagement, properly scoped, can produce evidence for two or three frameworks. Buyers who pursue separate engagements for separate frameworks are paying for the same testing twice. The mapping work — tagging each finding to the relevant control in each framework — is the differentiator, not the testing depth.

Quick reference: what each framework expects from a pentest

2. The manual-vs-automated coverage gap has widened

The OWASP API Security Top 10 v2023 release moved categories around in a way that exposes the limits of automated testing more clearly than the 2019 version did [2]. Three of the top four categories — BOLA (API1), Broken Authentication (API2), Broken Object Property Level Authorization (API3) — are categories scanners detect poorly because they require business-context understanding of what each object means in the application.

The gap is widest on:

• BOLA (Broken Object-Level Authorization). A scanner can enumerate object IDs; it cannot determine which IDs the current user is authorized to access without semantic knowledge of the tenancy model. BOLA findings are the most common authorization category in our authenticated tests across the SaaS Series A cohort [CyberGuards engagement data — [NEEDS CG DATA RANGE]].
• Business-logic flaws. Race conditions in payment flows, abuse of multi-step approval workflows, time-of-check-to-time-of-use issues. These do not match any signature library and surface only with manual hypothesis-driven testing.
• Chained exploit paths. A medium-severity finding combined with another medium can produce a critical impact. Scanners report each finding in isolation; pentest reports synthesize the chain.
• Authorization at function-level (BFLA, OWASP API5). Whether a user can invoke an endpoint they should not, often a function only an admin should call.

The mature view in 2026: vulnerability scanning is necessary but not sufficient. The AICPA explicitly recognizes both forms of evidence under CC7.1, with most auditors treating scanning as supplementary and pentest as primary [1]. Buyers should hold these as separate budget lines, not substitutes.

3. Three scope patterns cover most engagements

The shape of Series A SaaS engagements has converged into three recurring patterns. We have written about these elsewhere on the site under pricing patterns; this report adds the durations and the most common deviations.

Pattern 01 — Single application or single API

A SaaS with one product surface, light API exposure, straightforward AWS or GCP footprint. Typical engagement: two to three weeks of testing plus reporting plus a retest window — four to five weeks end-to-end. This is the modal first-year SOC 2 pentest in 2026.

Most common scope deviations: an API surface is "out of scope" on paper but is reachable from the test user account. We confirm or expand scope explicitly during the scoping call rather than discovering the surface mid-test.

Pattern 02 — Web plus API plus cloud configuration

The most common Series A SOC 2 Type II scope we see. A real API surface, multi-tenant boundaries that need validation, AWS or GCP footprint with IAM trust relationships. Three to four weeks of testing, five to six weeks end-to-end.

Most common scope deviations: cloud configuration review depth varies more than buyers expect. A read-only IAM role on a 50-resource AWS account is a 2-day review; the same role on a 500-resource account is a different engagement. Cloud scope should be quoted against resource count, not on a flat "AWS in scope" basis.

Pattern 03 — Full system boundary

Multi-product, multi-environment, internal and external scope. Service providers under PCI DSS 11.4.6 fall here, as do most Series B and later platforms. Quoted per engagement after scoping.

Most common scope deviations: social engineering scope. We include social engineering only when the auditor specifically requires it — most do not. The Pattern 03 engagement should not become a red-team engagement by accident.

4. Three readers, one report

A pentest report is unusual among security deliverables in that it has three audiences with non-overlapping needs:

1. The auditor. Wants the report scoped, dated, control-tagged, and signed. Will spot-check findings against the methodology. Most often does not read every finding.
2. The engineer. Wants reproduction steps, evidence, and remediation guidance specific to their stack. The executive summary is not for them.
3. The GTM team. Wants the executive summary to share in security questionnaires and the attestation letter to drop into the trust center. Does not read findings.

In 2026 the buyer expectation is one report serving all three. The era of separate "auditor report" and "engineering report" deliverables is over for Series A SaaS budgets. The report format that wins in this market has six distinct artifacts inside a single document: executive summary, scope statement, methodology reference, severity-ranked findings with evidence, control-mapping appendix, and attestation letter. Buyers should ask for a redacted sample under NDA on the scoping call before signing.

5. The retest gap has quietly become the differentiator

This is the most underweighted line in a typical engagement letter. Two patterns we see:

• Retest as a separate quoted engagement — the legacy pricing model. The buyer signs a $40,000 pentest, fixes findings, and is then quoted $10,000-$15,000 for retest. The total cost is the relevant number, but the original quote anchors expectations.
• Retest included in the engagement — the model converging in 2026 for boutique firms. One round of remediation verification is part of the base engagement at no incremental cost; results are appended to the original report so the auditor reads the finding and its closure together.

The compliance impact: a SOC 2 audit field-work date is fixed by the auditor. If retest is a separate engagement that requires re-quoting and re-scheduling, the calendar pressure between report delivery and audit fieldwork is severe. Open findings without retest evidence at audit time generate follow-up requests from the auditor.

The competitive implication: the pricing model is migrating. By 2027, buyers who get quoted with retest billed separately will increasingly perceive it as a bait-and-switch structure. The bundled-retest engagement is becoming table stakes for the Series A through Series C SaaS segment.

Closing — what to take from this

Three concrete reads:

1. If you carry two or more frameworks (SOC 2 + ISO, or SOC 2 + PCI), do not buy separate pentests for each. Buy one engagement, mapped to all of them.
2. Hold vulnerability scanning and penetration testing as separate budget lines. The AICPA recognizes both; auditors treat them differently. Conflating them produces an evidence gap.
3. On every engagement letter, check three things: scope is locked in writing, retest is included or transparently priced, and the report deliverable lists six sections (not three).

We refresh this report annually. If you spot a citation that needs an update or a section we should add for the 2027 edition, email [email protected].

Sources

1. AICPA-CIMA, 2017 Trust Services Criteria with Revised Points of Focus 2022. https://www.aicpa-cima.com/resources/download/2017-trust-services-criteria-with-revised-points-of-focus-2022
2. OWASP, API Security Top 10 — 2023 edition. https://owasp.org/API-Security/editions/2023/en/0x00-header/
3. PCI Security Standards Council, PCI DSS v4.0.1 (June 2024). https://www.pcisecuritystandards.org/document_library/?category=pcidss&document=pci_dss
4. ISO/IEC 27001:2022 — Information security management systems. https://www.iso.org/standard/27001

Items marked [NEEDS CG DATA] are placeholders for aggregate engagement data from CyberGuards' 2024-2026 customer cohort. They will be filled with anonymized ranges in the next quarterly refresh and do not appear as quantitative claims until verified.