SOC 2 Type II and Penetration Testing

If you are racing a SOC 2 Type II deadline, the question that keeps coming up is rarely theoretical: do we need a penetration test, what does the report have to say, and when does it have to land? This page answers those questions in the terms leadership and compliance teams actually use — without inventing a requirement the AICPA Trust Services Criteria do not write down.

SOC 2 is an attestation against the AICPA’s Trust Services Criteria (TSC), performed by a licensed CPA firm. Type I speaks to control design at a point in time. Type II speaks to whether those controls operated effectively across a defined observation period — often three to twelve months. Penetration testing sits in the gap between what the criteria say and what auditors expect to see as evidence.

What the Trust Services Criteria actually say

The TSC describe control objectives. They do not publish a checklist item that reads “perform an annual penetration test.” Criteria commonly implicated by technical security testing include areas such as:

• Detection and monitoring of vulnerabilities — identifying configuration changes and susceptibilities to newly discovered issues, and responding appropriately.
• Ongoing and separate evaluations — selecting and performing evaluations to ascertain whether components of internal control are present and functioning.
• Logical access and system operations — restricting and monitoring access, and managing the system so it meets security commitments.

None of those criteria name a vendor, a methodology, or a calendar cadence for pentesting. That is intentional: SOC 2 is criteria-based and risk-based, not a prescription like PCI DSS Requirement 11.4.

So why does every readiness checklist mention a pentest? Because auditors need competent evidence that vulnerability management and security evaluation controls are not paper-only. An independent penetration test — scoped to systems that support the service commitments in your SOC 2 report — is one of the clearest forms of that evidence. Many firms treat it as expected practice for cloud SaaS and API businesses even when the TSC leave room for alternatives.

The practical takeaway: treat the pentest as evidence for operating effectiveness, not as a standalone “SOC 2 certification.” Confirm with your CPA firm, in writing, what they will accept for your control set and industry.

Auditor expectations versus literal requirements

Leadership teams often hear two conflicting messages:

1. “SOC 2 does not require a penetration test.”
2. “Your auditor will ask for a penetration test.”

Both can be true. The literal criteria leave method flexibility. Audit practice for technology service organizations has converged on independent technical testing because:

• Customer due-diligence questionnaires ask for it.
• Prior-year deficiencies and industry incidents raise the bar for what “reasonable” looks like.
• Automated vulnerability scanning alone does not exercise authenticated business logic, multi-tenant isolation, or chained exploitation paths.

Ask your auditor early:

• Will they accept an internal red-team or only a third party?
• Must the tester be independent of the engineering org that built the system?
• Do they expect application-layer testing, network-layer testing, or both?
• Is a grey-box authenticated test of the production-like staging environment enough?
• What severity of open findings will block or qualify the opinion?

Get answers before you sign a statement of work. Scoping to the wrong depth wastes calendar time you do not have.

What the penetration test report must contain

Your auditor is not grading the prose. They are looking for attributes of evidence: who tested what, when, how thoroughly, and what happened next. A report that supports SOC 2 typically includes:

• Scope statement — applications, APIs, environments, and trust boundaries in scope (and explicitly out of scope).
• Methodology — industry-accepted approach (for example alignment with NIST SP 800-115 or the OWASP Web Security Testing Guide), testing windows, and tools versus manual techniques.
• Authentication model — roles tested, whether MFA was in play, and whether testing was black-, grey-, or white-box.
• Findings with evidence — clear titles, severity, affected assets, reproduction steps, and screenshots or request/response samples.
• Remediation guidance — enough for engineers to fix without a second engagement just to interpret the finding.
• Dates — engagement start/end and report issuance date that sit inside (or clearly relate to) the Type II period.
• Tester identity — firm name and sufficient independence narrative for the auditor’s workpapers.

Many teams also attach an executive summary and, after fixes, a retest letter or updated report. The attestation letter some customers request is useful commercially; your CPA firm still wants the underlying technical report and remediation trail.

If your in-scope surface includes a web app, API, and mobile clients, the report should reflect that — not a network scan that never logged in. See web application, API, and mobile application testing for how those surfaces are usually covered.

Timing versus the Type II audit window

This is where most deadline pain lives.

Type I can sometimes lean on a recent point-in-time test as design evidence. Type II needs evidence that controls operated during the period. A penetration test completed three weeks after the observation period ends does not prove the control ran inside the period.

Work backward:

1. Lock the observation period end date with your auditor.
2. Reserve time for scoping, kickoff, testing, draft report, remediation, and retest.
3. Schedule testing early enough that critical and high findings can be fixed and evidenced before period end — or accept that open items will appear in management responses and may affect how comfortable the auditor is.

A workable pattern for a first Type II:

• Month 1–2 of the period: policy and control design freeze; vendor selected; scope agreed with auditor.
• Mid-period: penetration test executed against systems that match the SOC 2 system description.
• Immediately after draft report: triage, fix, retest.
• Before period end: remediation tickets closed with dates, owners, and verification notes the auditor can sample.

If you are already late, be honest with the firm: a compressed test that starts two weeks before period end may still help if findings are limited and remediation is fast — but it is a risk, not a plan. Do not assume a “soft” verbal yes from sales; confirm with the engagement partner or manager.

Remediation and retest

SOC 2 care is about the control loop, not the PDF.

1. Triage — map each finding to an owner, severity, and affected control (for example vulnerability management or change management).
2. Fix — patch, config change, code change, or compensating control with a documented rationale if you accept residual risk.
3. Verify — retest by the original tester where possible; attach evidence to the ticket.
4. Retain — keep the original report, retest addendum, and ticket history for the auditor’s sample.

Open critical findings with no remediation plan are the ones that create awkward management comments. Medium and low findings can often remain open with a tracked backlog if your risk treatment process is real. Your auditor’s tolerance varies; ask.

Retest windows should be priced and scheduled up front. A report that ends with “remediation recommended” and no follow-up leaves the operating-effectiveness story incomplete.

How to brief your CPA firm and your security vendor

Give both parties the same facts:

• Observation period start and end dates.
• Draft system description (what products, environments, and subprocessors are in the report).
• In-scope applications and whether production or staging will be tested.
• Any prior-year findings or customer commitments that raise the bar.
• Whether the report will also be shown to enterprise security questionnaires.

Ask the pentest provider for a scope that maps cleanly to that system description. Ask the auditor whether segmentation, admin panels, and support tooling are in the SOC 2 boundary — if they are, they belong in the test.

A realistic leadership checklist

• Confirm with the CPA firm whether a third-party penetration test is expected for your control set.
• Align scope to the SOC 2 system description, not to marketing pages.
• Put the engagement on a calendar that leaves room for remediation inside the Type II window.
• Prefer authenticated, role-based testing over scan-only packages.
• Require a report with dates, methodology, evidence, and a retest path.
• Store artifacts where the audit team can retrieve them without Slack archaeology.

Common failure modes under deadline

These patterns show up repeatedly when Type II timing is tight:

• Scope drift — the system description lists Admin, support tooling, and a customer portal; the pentest only covered the marketing site.
• Environment mismatch — staging lacks auth providers, feature flags, or tenant data shapes that exist in production, so findings do not transfer.
• Scan-labeled-as-pentest — a vulnerability scan PDF presented as penetration testing fails auditor scrutiny when questions turn to privilege escalation and business logic.
• Undocumented remediation — engineers fixed issues in Slack but left no ticket dates, owners, or verification the auditor can sample.
• Late retest — fixes land after the observation period; the original open findings remain the only dated evidence inside the window.

Avoiding those five usually matters more than buying extra testing days.

Soft next step

If you are under a Type II deadline and need a scoped web, API, or mobile test with a report auditors can work from, start a conversation with enough lead time for remediation — not just for the test days themselves. Bring your observation dates and system description; the rest of scoping gets simpler from there.