DEFINITION: What penetration testing for SOC 2 compliance actually means
Penetration testing for SOC 2 compliance is security testing conducted to produce evidence that an organisation identifies and addresses vulnerabilities in its systems, satisfying the monitoring and risk mitigation expectations within the SOC 2 Security criteria. It is not a separately named requirement within the SOC 2 framework. It is the most direct and widely accepted method of demonstrating that a control expectation is being met in practice rather than only described in policy.
This distinction matters commercially. A company that understands it is buying evidence of ongoing vulnerability management, rather than buying a document called a pentest report, will scope its testing programme very differently and will pass audits with considerably less friction.
What SOC 2 actually requires, stated accurately
SOC 2 is an attestation framework developed by the AICPA and built on Trust Services Criteria. The Security criteria, which is mandatory in every SOC 2 engagement, includes common criteria addressing the identification of vulnerabilities, the monitoring of system components for anomalies, and the evaluation and remediation of identified security events.
SOC 2 does not prescribe a specific testing methodology, a testing frequency, or a required provider certification. What it requires is that an organisation can demonstrate its stated controls operated effectively across the audit period, which for a SOC 2 Type II report is typically three to twelve months.
That phrase, "across the audit period," is the most commercially significant detail in the entire framework for any company choosing a testing model. A single test conducted on one date within a twelve month audit window produces evidence for that date. It does not inherently demonstrate that the control operated throughout the period.
What ISO 27001 actually requires, stated accurately
ISO 27001 is a certifiable international standard for information security management systems. Its Annex A includes a control addressing the management of technical vulnerabilities, which requires that information about technical vulnerabilities be obtained in a timely manner, that exposure be evaluated, and that appropriate measures be taken.
Like SOC 2, ISO 27001 does not mandate penetration testing by name, nor does it specify a required frequency. What it requires is a demonstrable, operating process for identifying and addressing vulnerabilities, supported by evidence that the process runs continuously as part of a management system rather than as an isolated annual event. ISO 27001 also requires continual improvement of the management system, which auditors assess by looking for evidence that identified issues lead to documented corrective action and verification.
Where the annual testing model creates audit friction
Three specific problems arise when a company attempts to satisfy either framework using a single annual engagement.
- Period coverage gaps: A SOC 2 Type II audit assesses whether controls operated effectively throughout the review period. A test conducted in month two of a twelve month period leaves ten months during which the organisation cannot evidence that the vulnerability identification control was operating.
- Missing remediation evidence: Both frameworks care about what happened after a vulnerability was found. When retesting is commissioned separately or skipped, the organisation can evidence that it found issues but cannot evidence that fixes were verified, which is the part auditors examine most closely.
- Stale scope: Systems introduced after the annual test are not covered by it. An auditor reviewing an asset inventory against a testing scope will identify systems that were never assessed during the period.
Your Last Pentest Is Already Out of Date
Every week you ship without continuous testing is a week a vulnerability goes unseen. See what Capture The Bug finds in your first engagement.
Book a demo
For companies preparing a SOC 2 Type II or an ISO 27001 certification audit, the fastest way to identify evidence gaps is to review the specific audit period and scope directly. Book a demo with Capture The Bug and walk through what evidence a continuous programme would produce for a specific audit.
How continuous testing maps to both frameworks
Continuous penetration testing produces four evidence artefacts that map directly to what both frameworks assess.
- A dated finding record spanning the full audit period, demonstrating that vulnerability identification operated continuously rather than on a single date.
- Documented remediation verification, showing each finding tracked from discovery through fix to confirmed retest, which addresses the corrective action expectations in both frameworks.
- Scope currency, with new systems and endpoints entering testing coverage as they are introduced rather than waiting for an annual cycle.
- Severity assessment and prioritisation records, demonstrating that identified vulnerabilities were evaluated rather than simply logged.
A continuous penetration testing service generates these artefacts as a byproduct of normal operation, which is why the evidence assembly burden at audit time is substantially lower than reconstructing a narrative from a single historical report.
What auditors actually examine in a pentest report
Auditors assess penetration testing evidence against four practical questions, and understanding these prevents companies from over-investing in report presentation while under-investing in what is actually reviewed.
- Scope definition: Does the report state clearly which systems were tested, and does that scope align with the systems in the audit boundary?
- Testing dates: When was the testing performed, and does that timing provide coverage across the audit period rather than a single point within it?
- Methodology evidence: Does the report demonstrate a structured testing approach conducted by qualified personnel, rather than undocumented output?
- Remediation status: For each finding, is there evidence of what action was taken and whether the fix was verified?
Report length and visual polish are not assessment criteria. A concise report addressing these four points satisfies an auditor more completely than an extensive document that omits remediation verification, which is why a penetration testing service that tracks findings through to verified closure produces stronger audit evidence than one that stops at discovery.
What this means for your roadmap
The accurate statement is that neither SOC 2 nor ISO 27001 requires penetration testing by name, and any provider claiming otherwise is overstating the frameworks to make a sale. What both frameworks require is demonstrable, operating, continuous vulnerability management with evidence of remediation. A single annual test can contribute to satisfying that requirement. It rarely satisfies it completely, because it produces point-in-time evidence for a period-based assessment. A continuous penetration testing service aligns the shape of the evidence with the shape of the requirement, which is the practical reason companies pursuing both certifications increasingly move to this model.
Plan Your Annual Pentesting Strategy the Right Way
Learn how modern SaaS companies structure pentesting across the year to reduce risk, stay compliant, and avoid last-minute panic before audits.
FAQ
Does SOC 2 require a penetration test?
SOC 2 does not name penetration testing as a mandatory requirement. The Security criteria requires that an organisation identify vulnerabilities, evaluate them, and take appropriate action. Penetration testing is the most widely accepted method of evidencing that this control operated effectively, which is why most auditors expect to see it.
Does ISO 27001 require penetration testing?
ISO 27001 does not mandate penetration testing by name. Its Annex A control on technical vulnerability management requires timely identification of vulnerabilities, evaluation of exposure, and appropriate action. Penetration testing is standard practice for evidencing that this control operates, though the standard permits other approaches that achieve the same outcome.
How often should penetration testing be conducted for SOC 2 Type II?
Neither the framework nor the AICPA specifies a frequency. Because a Type II report assesses whether controls operated effectively throughout a period of typically three to twelve months, testing that provides coverage across that full period produces stronger evidence than a single test conducted on one date within it.
What do auditors look for in a penetration test report?
Auditors examine four things: whether the scope aligns with the audit boundary, when testing was performed relative to the audit period, whether the methodology demonstrates structured testing by qualified personnel, and whether each finding shows evidence of remediation and verification. Report length and presentation quality are not assessment criteria.
Can one testing programme produce evidence for both SOC 2 and ISO 27001?
Yes. Both frameworks assess overlapping concerns around vulnerability identification, evaluation, and remediation. A single continuous testing programme, scoped to cover the systems within both audit boundaries and reported with findings mapped to each framework's relevant control, produces evidence usable for both without requiring separate engagements.
