A question that comes up in almost every SOC 2 project is whether a penetration test is required. Strictly speaking, SOC 2 does not mandate one - but in practice, most auditors and nearly all enterprise buyers expect an annual penetration test as evidence that your vulnerability-management program actually works. Understanding this distinction, and how a pen test fits the criteria, helps you plan and budget correctly.
This guide explains the role of penetration testing in SOC 2, how it maps to the criteria, what scope and cadence to choose, and how to handle the findings so they strengthen rather than undermine your report.
Required versus expected
SOC 2 is principles-based, so it does not list a penetration test as a hard requirement the way a prescriptive standard might. What it does require is that you identify and remediate vulnerabilities and manage the security of your systems. A penetration test is the most common, most credible way to demonstrate that you do this, which is why auditors look for one and buyers ask about it. The honest framing is that a pen test is not technically mandatory, but operating without one leaves a conspicuous gap in the evidence that supports several criteria, and most companies treat it as a practical requirement.
How a pen test maps to the criteria
A penetration test primarily supports the Security criteria around vulnerability management, monitoring, and risk mitigation. The test report demonstrates that you proactively sought out weaknesses, and the evidence that you remediated the findings within your defined timelines demonstrates that the underlying control - your vulnerability-management process - operates effectively. The auditor is less interested in a perfect, finding-free report than in seeing that you test regularly, prioritize what you find, and fix it on a schedule. A report with findings you have remediated is stronger evidence than no report at all.
Free resource
SOC 2 Readiness Kit
A practical checklist + policy starter pack to fast-track your audit.
What scope to test
Match the penetration test scope to your SOC 2 boundary. For most SaaS companies that means testing the in-scope applications and the supporting infrastructure - the externally reachable surface that customers and attackers interact with. Where relevant, scope can extend to internal networks, APIs, mobile apps, and cloud configuration. The goal is for the test to cover the systems your report claims to protect, so that the assurance the pen test provides aligns with the assurance the report asserts.
How often to test
The widely accepted cadence is at least annually, plus retesting after any significant change to the in-scope environment - a major release, a new architecture, or a substantial infrastructure shift. Annual testing aligns naturally with the annual SOC 2 cycle and gives you a fresh report to support each year's audit. For higher-risk or rapidly changing environments, more frequent testing strengthens both your security posture and your evidence, but annual is the baseline expectation.
Who should perform the test
A penetration test should be performed by a qualified, independent testing provider rather than the team that built the system, because independence is what gives the result credibility - the same principle that underlies the SOC 2 attestation itself. Auditors and buyers place more weight on a test conducted by a reputable third party with a clear methodology than on an internal scan. Choose a provider whose scope, methodology, and reporting are rigorous enough that the resulting report stands up to scrutiny.
Handling the findings
What matters most is not the existence of findings but how you handle them. Triage findings by severity, remediate them within the timelines your vulnerability-management policy commits to, and keep evidence of the remediation - tickets, retest results, and closure dates. This turns a pen-test report from a list of problems into proof of a working control. A report full of unaddressed findings is a liability; the same report with documented, timely remediation is exactly the evidence the auditor wants to see.
Pen testing versus vulnerability scanning
It is worth distinguishing a penetration test from automated vulnerability scanning, because both have a role and they are not interchangeable. Scanning is continuous and automated, catching known issues across your environment frequently and cheaply; a penetration test is a periodic, in-depth, human-led assessment that probes for exploitable weaknesses a scanner would miss. A mature program runs both: continuous scanning for breadth and an annual penetration test for depth. Together they give auditors strong evidence that vulnerability management operates on an ongoing basis.
Budgeting for penetration testing
A penetration test is a distinct line item in your SOC 2 budget, separate from the audit fee and any compliance tooling. Costs vary with scope and the provider, but it is a recurring annual expense you should plan for from the start rather than treating as an afterthought. Because buyers expect it and auditors look for it, it is rarely worth skipping; the more useful question is how to scope it efficiently so it covers what your report claims without testing systems that are out of scope.
Sharing pen-test results with customers
Enterprise buyers increasingly ask not only whether you run a penetration test but to see evidence of it during due diligence. You generally do not share the full, detailed pen-test report, which can contain sensitive technical findings, but a summary or attestation letter from the testing provider confirming that a test was performed and findings were remediated is commonly provided under NDA. Having this ready alongside your SOC 2 report streamlines security reviews, because vulnerability management is one of the most frequent areas buyers probe, and a clear answer with supporting evidence removes a common point of friction in the sales process.
Penetration testing across frameworks
A penetration test does double duty across the frameworks you are likely to pursue. The same annual test that supports your SOC 2 vulnerability-management evidence also supports requirements in ISO 27001, and is often expected for PCI DSS and by security-conscious customers regardless of any framework. Planning a single, well-scoped annual test that satisfies multiple needs avoids paying for redundant testing and keeps your evidence consistent across programs. As with controls and policies, building the penetration-testing cadence with reuse in mind is part of how a mature compliance program avoids duplicating cost as it adds frameworks.
Timing your penetration test in the SOC 2 cycle
Where the penetration test sits in your timeline matters. Running it during the readiness phase, before the observation window opens, gives you time to remediate findings so the report reflects a managed, closed-out posture rather than open issues. Scheduling it too late - near the end of the period or just before fieldwork - leaves no room to fix what it finds, and unremediated findings weaken the evidence. The practical pattern is to test early enough to remediate within your committed timelines, then keep the report and remediation records on hand for the auditor and for customer due diligence throughout the year.
How ISpectra incorporates pen testing
ISpectra plans penetration testing into your SOC 2 roadmap from the outset - coordinating a qualified independent test scoped to your boundary, ensuring findings are remediated within policy, and capturing the evidence the auditor needs. This keeps the vulnerability-management criteria well supported and is part of how we deliver a Type 1 within two months and a Type 2 within four without gaps in the evidence. Knowing where it fits helps you scope SOC 2 compliance correctly.
Free consultation
Need help with SOC 2?
Talk to our certified compliance team — we’ve supported 200+ audits.