Is an Annual Pentest Enough for SOC 2? What Auditors and SaaS Buyers Expect in 2026
You finished your first SOC 2 Type II. The report is clean. Then a prospect asks for the "latest pentest report," and your last engagement finished fourteen months ago - before the auth rewrite and the new multi-tenant billing API. The question that follows is the one this post answers: for SOC 2 penetration testing, is an annual third-party test still enough, or do auditors and enterprise buyers expect a tighter cadence in 2026?
Short answer: The AICPA Trust Services Criteria do not literally require a penetration test by name. In practice, most SaaS auditors and enterprise buyers treat a recent third-party pentest as practical evidence for vulnerability management and monitoring narratives - often discussed under CC7.1 and related access/monitoring criteria. A vulnerability scan is not a substitute. Annual testing is the floor for most SaaS Type II windows; growth, regulated, and high-velocity teams often move to semiannual or quarterly testing plus trigger-based tests after major changes. What closes both audit fieldwork and questionnaire asks is not the calendar alone - it is the evidence pack: full report, remediation log, Critical/High retest, and risk-acceptance records for deferred items.
This post is for SaaS CTOs, compliance owners, and founders renewing SOC 2 Type II who also field enterprise questions about the latest pentest. For when to get a first test as a startup, see penetration testing for startups. For how buyers ask across questionnaires vs attestations, see SOC 2 vs security questionnaires.
Is a penetration test required for SOC 2?
Not by name. Bastion (25 Feb 2026) and DSALTA (9 Mar 2026) both frame the same distinction: SOC 2 is principles-based. The Trust Services Criteria describe what you need to prove - not a checklist of named tools. You will not find "penetration test" mandated as a literal AICPA requirement.
Still expected in 2026. Auditors and buyers have converged on adversarial testing as the practical way to support vulnerability identification, unauthorized-access detection, and related monitoring stories. DSALTA maps pen testing most often to criteria such as CC7.1 (detection and monitoring of vulnerabilities), with related pressure on access and perimeter narratives (for example CC6.6 / CC6.8 in their framing). Bastion notes that even when the CPA will not fail you solely for skipping a pentest, enterprise buyers and security questionnaires routinely treat recent third-party testing as a hard gate.
Skip the test and you must still produce an alternative evidence story. For multi-tenant SaaS, that is rarely cleaner than a scoped grey-box engagement with remediation evidence.
Scan vs pentest: what auditors reject
| Assessment | What it does | What it does not do | SOC 2 / buyer use |
|---|---|---|---|
| Vulnerability scan | Finds known CVEs, missing patches, common misconfigs via automation | Business logic flaws, tenant isolation breaks, chained exploits, realistic auth abuse | Necessary hygiene; not a pentest substitute |
| Penetration test | Manual (plus tooling) adversarial testing against agreed scope | Continuous coverage by itself unless you buy a PTaaS/continuous model | De facto evidence buyers and many auditors expect for SaaS |
DSALTA and Bugstrix (updated 8 Jun 2026) both warn against submitting a Nessus/Qualys-style scan PDF labeled as a "pentest." Serious reviewers know the difference. Keep scans on a regular cadence for patch hygiene; keep a third-party pentest for the adversarial artifact.
How often should SaaS run SOC 2 penetration testing?
PCI DSS has explicit pentest cadence language if you are in scope - do not conflate that floor with SOC 2. SOC 2, ISO 27001, and HIPAA do not prescribe one universal schedule; auditors and risk profile fill the gap.
Stage-based guidance that matches DSALTA and Bugstrix:
| Stage / profile | Calendar cadence | Trigger-based adds |
|---|---|---|
| First Type II / early SaaS | At least 1x annual third-party test inside the observation window | Major launch, new auth surface |
| Growth SaaS (regular releases, PII) | Semiannual or quarterly common | Major releases, infra migrations, new payment/IdP integrations |
| Regulated / enterprise-facing / high-velocity | Quarterly to continuous (PTaaS) | Every significant attack-surface change |
| PCI DSS in scope | Follow PCI explicit rules (at least annual + after significant change) | Do not treat SOC 2 "annual" as covering PCI |
Annual is the floor, not always the target. If you ship weekly and your last test predates a major auth or tenancy change, the calendar box may be checked while buyer diligence still fails. Bugstrix notes that multi-tenant broken access control (IDOR, tenant isolation, privilege escalation across shared services) is a recurring critical class - and those boundaries change as the product changes. Automated scanners rarely find them; scoped manual testing does.
Timing inside the Type II observation window
Cadence without timing still fails audits. DSALTA's practical rule: a test from eighteen months ago draws scrutiny, especially if you shipped meaningful features since. For a Type II window covering a calendar year, a test early in that window (for example Q1/Q2 of the period) leaves months to remediate Critical/High findings and retest before fieldwork.
Running the engagement in the last weeks of the window leaves no remediation runway, and the report looks like theater instead of a control process.
Align the engagement to:
- The observation period you are currently in (not last year's window only).
- Your release and architecture calendar (auth rewrites, cloud migrations, new payment surfaces).
- Buyer questionnaire expectations for "latest" - often interpreted as within ~12 months, tighter for high-risk deals.
What evidence auditors and buyers actually want
The engagement is half the story. The pack that closes asks is the other half (DSALTA evidence checklist; Bastion remediation emphasis):
- Full third-party report - methodology (OWASP / PTES / NIST-style framing), dated scope, severity-rated findings, executive summary suitable for NDA sharing.
- Remediation tracking log - finding -> owner -> fix -> close date (Jira, Linear, GRC - timestamped and attributable).
- Retest / validation for Critical and High - vendor retest letter or documented internal validation that the exploit path is closed.
- Risk-acceptance records for deferred items - signed by an appropriate executive, with compensating controls noted.
- Written pentest policy - frequency, scope process, vendor requirements, and how findings feed vulnerability management (shows systematic, not ad hoc).
For multi-tenant SaaS, call out authorization and tenant-isolation testing in scope. Bugstrix flags broken access control across tenancy as a high-frequency critical class; buyers who understand SaaS will look for that language.
Share executive summaries under NDA via your company Trust page / Trust Center when that is how your GTM runs diligence - without turning this post into a Trust Center build guide.
A practical 2026 cadence checklist
Use this as an operating checklist, not legal advice:
- Written pentest policy reviewed in the last 12 months
- Scope covers customer-facing app/API, auth (including SSO/OAuth), admin surfaces, and multi-tenant isolation where relevant
- At least one third-party test inside the current Type II window
- Early-window timing so Critical/High can remediate and retest before fieldwork
- Trigger-based tests queued for major releases, cloud migrations, and new auth/payment integrations
- Scan program separate from pentest (do not conflate)
- Full report + remediation log + Critical/High retest + risk acceptances ready for auditor and NDA buyers
- If PCI is in scope, follow PCI cadence separately from the SOC 2 narrative
AI-enabled products may need additional model/prompt-specific testing on top of classic app testing; that is additive evidence, not a replacement for the baseline SOC 2 pack. For AI-company Type II context, see SOC 2 Type 2 for AI companies.
How this differs from Trust Center and questionnaire posts
Sibling posts on Workstreet cover adjacent jobs:
- Trust Center / trust page posts explain how to *host and share* artifacts under NDA. This post defines *what* the pentest artifact is and how often to refresh it.
- Questionnaire posts explain how buyers *ask* across portals and spreadsheets. This post explains the underlying evidence those asks point at.
- Penetration testing for startups covers *when to get the first test*. This post covers *cadence after you are already in a SOC 2 rhythm*.
Keep those lanes separate so searchers and AEO surfaces get a crisp answer without three posts restating the same outline.
What to tell sales while the test is in flight
Deals do not pause politely for your observation window. Give sales a clear interim answer: the date of the last closed report, the date the current engagement started, the scope headline (app, API, auth, tenant isolation), and whether Critical or High findings from the prior cycle are closed with retest evidence. That is usually enough to keep diligence moving. Put the same facts in the questionnaire answer bank so every portal form does not invent a different story.
If a buyer insists on findings under NDA before retest finishes, share the executive summary plus remediation tracker status - not an unfinished draft with open Critical paths.
Soft next step
For a scoped third-party engagement and remediation evidence that maps to SOC 2 and buyer asks, see Workstreet penetration testing. Keep the report in the same vulnerability-management program as your SOC 2 story. When questionnaires are the bottleneck, use security questionnaire automation. Deeper methods: the complete penetration testing guide.
