SOC 2 Penetration Testing Requirements
Penetration testing is the process by which authorised testers simulate a cyber attack on a computer system, network or web application to evaluate security and identify exploitable weaknesses before malicious actors find them.
While the American Institute of CPAs (AICPA), the body that governs SOC2, doesn’t explicitly state that a penetration test is mandatory, auditors almost always look for one because it serves as an independent, technical proof that your security controls actually work in practice.
This guide sets out what the Trust Services Criteria (the professional standards used by auditors to evaluate the security, privacy and integrity of an organisations data management systems) actually require, what auditors and customers expect in practice, and how to scope, time and document a penetration test so it provides genuine value to your audit rather than sitting unused in a folder.
Key Takeaways
- SOC 2 does not name penetration testing as a mandatory control, but almost every auditor expects one regardless.
- CC4.1 explicitly lists penetration testing as an example of a way to evidence that your controls are working.
- A single pentest can generate evidence for five or more Trust Services Criteria at once.
- Type II auditors expect testing at least annually, timed to fall inside your observation period with room to remediate and retest.
- Keep your scope agreement, testing dates, findings, remediation tickets and retest results together as one evidence package.
Understanding SOC 2 Compliance
SOC 2 is an AICPA framework, and it is not a certification in the way ISO 27001 is. Although some frequently use the phrase to denote the document itself, the deliverable is technically an attestation report produced by a licensed CPA firm.
Organisations are evaluated against the five Trust Services Criteria:
- Security
- Availability,
- Processing Integrity
- Confidentiality
- Privacy
Security is mandatory for every audit, and the remaining four apply only where they have been scoped in, based on the commitments made to customers.
Organisations also choose between a Type I and a Type II report, and the choice changes what must be proven. A Type I report evaluates whether controls are designed correctly at a single point in time.
A Type II report goes further: it tests whether controls operated effectively across an observation period that typically runs three to twelve months, which requires continuous evidence rather than a single snapshot.
Many organisations complete a Type I first to unblock deals and surface gaps, then move to Type II once their control environment has stabilised.
SOC 2 does not prescribe a specific list of tools or activities. It is principles-based: organisations design controls that meet the criteria, and the auditor evaluates whether the evidence is sufficient.
This flexibility is precisely why penetration testing, despite not being named anywhere in the standard, remains one of the clearest ways to demonstrate that controls actually work.
What Is Penetration Testing
A penetration test, as mentioned earlier, is a controlled, hands-on assessment of an organisation’s own systems. A human tester, working as an adversary, rather than following a checklist as one would in vulnerability scanning, attempts to chain vulnerabilities together and exploit them rather than simply flagging that they exist.
| Vulnerability Scanning | Penetration Testing | |
|---|---|---|
| How it works | Automated, checks systems against known vulnerability databases | Manual, a human tester actively tries to exploit what they find |
| Depth | Broad coverage, surface-level | Narrower scope, tested in depth |
| Finds | Known, catalogued weaknesses | Known weaknesses plus chained and business-logic flaws scanners miss |
| Speed | Minutes to hours | Days to weeks |
| Typical SOC 2 role | Ongoing, often monthly or continuous | Point-in-time, usually annual |
Granted, vulnerability scanning is useful, and most mature security programmes run it continuously, but it answers a narrower question. A scan looks for potential open doors, while a penetration test proves whether someone can actually walk through them and compromise your data.
Does SOC 2 Require Penetration Testing?
Not explicitly. The AICPA’s Trust Services Criteria never use the words “penetration test” as a mandatory control. However, CC4.1’s point of focus names penetration testing directly, as an example of the ongoing or separate evaluations an organisation is expected to run. The table below maps a penetration test to the criteria auditors cite most often:
| Criterion | What It Covers | How a Pentest Provides Evidence |
|---|---|---|
| CC4.1 (Monitoring Activities) | Ongoing evaluations that check whether controls are present and functioning | Named directly in the criterion’s own point of focus |
| CC6.1 (Logical Access) | Restricting system access to authorised users | Tests authentication bypass and privilege escalation paths |
| CC6.6 (Threat Prevention) | Defending against malicious software and external threats | Confirms defences hold against adversarial technique, not just signatures |
| CC6.8 (Unauthorized Access) | Preventing and detecting unauthorised software or access | Surfaces business-logic and access flaws scanners typically miss |
| CC7.1 (Vulnerability Identification) | Detecting changes and configurations that introduce vulnerabilities | Generates a concrete, exploitable list tied to specific systems |
| A1.2 (Availability, where scoped) | System resilience and environmental protections | Tests whether exploited weaknesses could disrupt uptime |
| C1.1 (Confidentiality, where scoped) | Protecting confidential information | Simulates how an attacker might reach sensitive data |
How Penetration Testing Supports Audit Tests
Type I and Type II place different demands on a penetration test, reflecting the different things each report evaluates.
| Type I | Type II | |
|---|---|---|
| Tests | Control design at a single point in time | Control design and operating effectiveness over a period |
| Typical period | A snapshot date | 3 to 12 months |
| Pentest needs to have happened | Any time before the report date | Inside the observation window itself |
| Retest evidence | Findings addressed, remediation plan for the rest | Retest results documented alongside the original findings |
Most Type II auditors expect penetration testing at least annually, with additional rounds following significant infrastructure changes, major releases or cloud migrations.
Timing within the observation window matters as much as running the test at all. Scheduling should work backward from the evidence deadline rather than forward from kickoff, allowing time for scoping, testing, report review, remediation and a retest, since a critical finding delivered two days before the deadline leaves no realistic time to address it.
The report handed to the auditor matters too. At minimum, this should include a scoped executive summary, a stated methodology, findings mapped to the specific Trust Services Criteria they support, and remediation status including retest evidence for anything critical or high severity.
The scope agreement, testing dates, findings, remediation tickets, exceptions and retest status should be kept together as a single evidence package rather than scattered across tools, since this is what an auditor typically requests, not merely the final report.
Final Thoughts
SOC 2 will not fail an organisation for omitting a penetration test, but few other activities provide as much audit evidence for comparable effort. A single, properly scoped engagement generates evidence across half a dozen criteria, answers the question an auditor is likely to ask regardless, and pre-empts the same question from customers reviewing the report.
Palisade penetration testing and vulnerability assessments cover the external perimeter, web applications, APIs and cloud infrastructure that most SOC 2 boundaries include, scoped against your system description and mapped to the criteria your auditor is testing.
Where SOC 2 readiness itself is the gap, our security consulting team can help with the wider preparation, from compliance reviews to the evidence your auditor will request. If you are scoping a test against an upcoming audit window, book a free scoping call to find out how we can help your organization achieve its compliance goals.
