If you sell software to mid-size or enterprise customers, a SOC 2 report has probably become a sales requirement. And almost as soon as you start a SOC 2 project, someone asks: "Do we need a penetration test?" The honest answer is "not by name — but in practice, yes." This guide explains why, what auditors actually look for, and how to scope a SOC 2 pentest that helps you pass without paying for things you don't need.
Does SOC 2 require a penetration test?
SOC 2 is an attestation framework from the AICPA built on the Trust Services Criteria (TSC). The criteria describe outcomes — for example, that you identify and assess risks, monitor your controls, and detect and respond to vulnerabilities — rather than prescribing specific tools. Penetration testing is therefore not mandated by name.
However, several Common Criteria are most convincingly evidenced with a penetration test:
- CC4.1 — the organisation selects, develops and performs ongoing and/or separate evaluations of its controls. The points of focus explicitly mention that evaluations may include penetration testing.
- CC7.1 — the organisation uses detection and monitoring procedures to identify configuration changes and newly discovered vulnerabilities.
- CC3.2 / CC3.4 — risk identification and assessment, including risks from changes to the system.
Most CPA firms will therefore ask for a recent penetration test report as evidence. Even if your auditor would accept alternatives, your customers' security teams almost always ask for a pentest summary or attestation letter alongside your SOC 2 report. In practice, skipping the test creates more friction than it saves.
SOC 2 Type I vs. Type II: does it change the pentest?
| Type I | Type II | |
|---|---|---|
| What it attests | Controls are suitably designed at a point in time | Controls operated effectively over a period (typically 3–12 months) |
| Pentest timing | Before the Type I date, so findings can be shown as known and tracked | Inside the observation window, with remediation and retest also inside it |
| What auditors look at | That a testing process exists and is planned | That the test happened, findings were triaged, and fixes were verified |
For Type II, the pentest is less about the number of findings and more about demonstrating a working process: test → triage → fix → retest → document.
What should a SOC 2 pentest cover?
Start from your SOC 2 system description. Whatever is inside that boundary is a candidate for testing. For a typical SaaS company that means:
- The production web application — authenticated, grey-box testing with an account for each user role. Multi-tenant isolation (can tenant A see tenant B's data?) is the single most important test for SaaS.
- Public and internal APIs used by the app, mobile clients or integrations — with emphasis on object-level authorization (BOLA) and function-level authorization.
- The cloud environment (AWS, Azure or GCP) — IAM privilege escalation paths, exposed storage, security groups, secrets management and logging.
- External network perimeter — internet-facing hosts, admin panels, VPN endpoints.
- Mobile apps, if customers use them to access in-scope data.
Internal corporate networks, physical offices and social engineering are rarely required for SOC 2 unless they are inside the system boundary or your risk assessment identifies them as significant.
What auditors want to see in the report
- Tester independence — an external firm, or an internal team independent of the system's developers
- Test dates, scope and in-scope assets that clearly map to the SOC 2 system boundary
- A documented methodology (OWASP WSTG, PTES, NIST SP 800-115)
- Risk-rated findings with evidence
- Remediation status, ideally with a retest report showing critical and high findings closed
- An executive summary or attestation letter you can share with customers under NDA
A practical SOC 2 pentest timeline
- Weeks 1–2: Scope and bookShare your system description and architecture diagram with 2–3 vendors. Get fixed-price proposals.
- Weeks 3–4: PrepareCreate test accounts for every role, allow-list tester IPs, freeze major deployments to the test environment.
- Weeks 5–6: TestingTypically 5–15 tester-days for a single SaaS application plus API and cloud.
- Weeks 7–10: RemediateFix critical and high findings first; document risk acceptance for anything you won't fix.
- Weeks 10–12: Retest and closeGet the retest report and attestation letter. Upload to your compliance platform as evidence.
How much does a SOC 2 penetration test cost?
For a typical early-stage SaaS product (one web app, its API, one cloud account), expect roughly US$6,000–$20,000 with established Western firms and less with strong India-based providers. Costs rise with the number of user roles, API endpoints, tenants and cloud accounts. See our full penetration testing pricing guide.
Common mistakes to avoid
- Buying a scan instead of a test. An automated scan report rarely satisfies auditors or enterprise customers. See VA vs. pentest.
- Testing too late. If the test lands in the last week of your Type II window, you can't show remediation.
- Scope mismatch. Testing the marketing site instead of the product your SOC 2 covers.
- No multi-tenant testing. Customers care most about whether other tenants can reach their data.
- Ignoring low findings forever. Track them in your risk register; auditors notice repeat findings year after year.
Compliance platforms and pentests
If you use a compliance automation platform, your pentest report becomes one piece of evidence among many. These platforms often partner with testing firms, but you are free to use any qualified provider — just make sure the report contains the elements above so it uploads cleanly as evidence.
Frequently asked questions
Is a penetration test mandatory for SOC 2?
Not by name. The Trust Services Criteria describe outcomes, but the points of focus for CC4.1 list penetration testing as a type of evaluation, and most auditors and customers expect an annual third-party test.
How often should a SOC 2 pentest be done?
At least annually, and after significant changes to the in-scope system. For Type II, schedule it early enough in the observation window to remediate and retest.
Can we use any pentest firm for SOC 2?
Yes. There is no approved-vendor list. Choose an independent, qualified firm whose report documents scope, methodology, findings and remediation status.
Ready to scope your SOC 2 test? Request a fixed-price quote, or see our web application testing service.