Short answer
SOC 2 does not universally require a penetration test. The Trust Services Criteria describe outcomes for controls, not one mandatory test for every service organization. A pentest becomes relevant when it addresses an identified risk, supports a control you claim, satisfies an auditor's evidence request, or meets a customer commitment.
The distinction matters. A sales promise that every SOC 2 audit needs a pentest is inaccurate. So is treating a pentest as unrelated to the audit. The right question is: which risk or control objective will this test support, and what evidence will the auditor need?
AICPA describes SOC 2 as an examination of controls relevant to security, availability, processing integrity, confidentiality, or privacy. Its published Trust Services Criteria provide criteria for evaluating those controls. They do not prescribe one identical control set for every company. See the official AICPA SOC 2 resource center and the Trust Services Criteria.
SOC 2 Type I vs Type II: where the pentest fits
Type I and Type II reports examine the same kind of control system but answer different timing questions. That changes how a pentest record is used.
| Report | What it addresses | How pentest evidence can help | Common mistake |
|---|---|---|---|
| Type I | Control design and implementation as of a specified date. | Shows that the security-testing control exists, has a defined scope, produced a report, and has an owner for remediation. | Booking a test after the evidence date. |
| Type II | Control design plus operating effectiveness over a specified review period. | Shows the control ran on schedule, findings were triaged, fixes were tracked, and retests were completed where required. | Writing “annual pentest” into the control, then missing the stated cadence during the period. |
AICPA's illustrative Type II report includes tests of controls and their results. This is why the operating record matters, not only the final pentest PDF. Keep the scope approval, testing dates, findings, tickets, exceptions, and retest status together. The AICPA illustrative SOC 2 report description explains the parts of that example report.
When penetration testing is relevant to SOC 2
A pentest is most defensible when it traces to a specific reason. Use the following triggers in planning conversations with your auditor, compliance lead, and test provider.
Your risk assessment identifies an attack path
Internet-facing applications, administrative interfaces, multi-tenant APIs, or sensitive data flows may warrant validation beyond configuration review and automated scanning.
Your control says you perform one
Once a control statement commits to a frequency or trigger, Type II testing can examine whether it operated as written. Avoid boilerplate that your team cannot sustain.
A customer or contract asks for independent testing
Enterprise security reviews often ask for the date, scope, provider independence, critical findings, remediation status, and an executive summary.
The system changed materially
A new authentication model, major API, cloud migration, tenant isolation change, or acquisition can justify testing before the next calendar-based cycle.
How to define a SOC 2 penetration test scope
Begin with the system boundary in your SOC 2 description, then select the parts that can be meaningfully attacked. “Test the platform” is not a scope. A useful scope identifies assets, identities, environments, exclusions, and safety limits.
1. Map the system boundary to testable assets
- Production web applications and customer-facing domains
- REST, GraphQL, or internal APIs used by the product
- Cloud accounts, exposed services, and identity configuration
- Administrative portals and support tooling
- Mobile clients, desktop clients, or agent endpoints
- Source repositories and infrastructure code, when authorized
2. Supply identities that expose real authorization boundaries
For a multi-tenant SaaS product, provide at least two ordinary users in different tenants plus each meaningful privileged role. That lets the tester attempt horizontal access, vertical privilege escalation, and cross-tenant actions without guessing which roles exist.
3. Choose an access model that matches the objective
Black-box testing covers what an outsider can discover. Gray-box testing adds representative credentials and limited context. White-box testing includes source code, architecture, or deep configuration access. Our black, gray, and white box comparison shows what each method can and cannot establish.
4. Write safety constraints into the rules of engagement
- Approved domains, IP ranges, repositories, and cloud accounts
- Testing window, rate limits, and operational contacts
- Prohibited actions such as destructive payloads or denial of service
- Handling requirements for customer data and credentials
- Stop conditions and an emergency communication path
- How proof is captured and securely transferred
What the pentest report and evidence package should contain
A report is useful to engineering when it proves the issue and useful to assurance teams when it proves the process. The package should make both stories easy to follow.
| Evidence | Question it answers |
|---|---|
| Authorization and scope | Who approved testing, against which assets, and when? |
| Methodology and coverage | What techniques, roles, endpoints, and limitations applied? |
| Executive summary | What was the overall risk and what requires management attention? |
| Technical findings | Can an engineer reproduce the condition and understand its impact? |
| Severity rationale | How were exploitability, technical impact, and business context weighed? |
| Remediation record | Who owns the fix, what changed, and was the issue retested? |
| Exceptions | Which risks were accepted, deferred, or covered by another control? |
Maintain a controlled executive summary or attestation-style letter that states the date, provider, scope category, and high-level remediation status without exposing exploitable detail. Agree with counsel, your auditor, and the tester on what can be shared.
When to schedule the test and retest
Schedule backwards from the evidence date, not from the audit kickoff. Leave time for scoping, access setup, testing, report review, remediation, and confirmation testing. A critical finding delivered two days before an evidence deadline leaves no credible remediation window.
- Confirm with the auditor. Ask which control or risk the test supports, the acceptable testing date, and the evidence they expect.
- Freeze scope. Record assets, roles, access model, exclusions, and rules of engagement before testing begins.
- Run and review. Validate findings with the tester so impact and reproduction steps are accurate.
- Remediate by risk. Fix urgent attack paths first and document owners and dates for remaining work.
- Retest the fix. A closed ticket is not confirmation. Preserve the retest result alongside the original finding.
SOC 2 pentest planning checklist
The auditor or compliance owner has confirmed why the test is needed.
The SOC 2 system boundary has been mapped to named assets.
Representative tenants and user roles are available for testing.
The team has selected black, gray, white, or combined access.
Rules of engagement include data handling and stop conditions.
The report format includes scope, methodology, evidence, severity, and limitations.
Remediation owners and service-level targets are agreed before results arrive.
A retest window fits before the intended audit evidence date.
Frequently asked questions
Is penetration testing required for SOC 2?
Not as a universal, explicitly prescribed test. The organization selects controls to address its risks and commitments, and the service auditor evaluates those controls. A pentest may still be expected because of the risk assessment, a stated control, an auditor request, or a customer contract.
Does SOC 2 Type I require penetration testing?
Type I does not create a separate blanket pentest requirement. If penetration testing is part of the control design being examined, a completed report and remediation record can help demonstrate that the control is suitably designed as of the report date.
Does SOC 2 Type II require annual penetration testing?
SOC 2 itself does not set one annual frequency for every organization. If your documented control says that a pentest occurs annually, or after defined changes, the auditor can test whether that control operated during the review period. Write a cadence you can support and that matches risk.
Is a vulnerability scan enough for SOC 2?
A scan and a penetration test answer different questions. A scanner finds known patterns across many assets. A pentest attempts to validate exploitability, authorization failures, business logic problems, and attack paths. The evidence needed depends on your control design and risk assessment.
Should the pentest be black box, gray box, or white box?
For most SaaS products, a combined gray-box and white-box scope gives useful coverage of authenticated roles, tenant boundaries, APIs, and source-assisted investigation. Add black-box coverage when the objective includes the public attack surface or detection and response.
Primary sources
- AICPA: SOC 2 Trust Services Criteria resources
- AICPA: 2017 Trust Services Criteria with revised points of focus
- AICPA: illustrative SOC 2 Type II report
This guide is educational, not an audit opinion. Confirm the final control design, evidence period, and testing expectations with your licensed service auditor.