Does SOC 2 Require Penetration Testing?
Technically, no. SOC 2 doesn’t list penetration testing as an explicit requirement. But practically, almost every SOC 2 auditor expects it.
SOC 2 is built around Trust Service Criteria (TSC), not prescriptive checklists. The criteria describe outcomes your organization needs to achieve: protecting against unauthorized access, identifying vulnerabilities, monitoring for security events. How you meet those criteria is up to you. Auditors evaluate whether your chosen controls are sufficient and operating effectively.
Penetration testing shows up in this framework because it directly addresses several criteria that are hard to satisfy otherwise. CC7.1 requires you to detect vulnerabilities in your environment. CC4.1 requires ongoing monitoring and evaluation of your control environment. A pen test independently validates both.
Most auditors will ask for a penetration test report during a Type II engagement. Some won’t require it, but they’ll note its absence, and your report will be weaker for it. If your competitors include pen test results in their SOC 2 reports and you don’t, customers notice the gap.
Trust Service Criteria That Map to Penetration Testing
SOC 2’s Trust Service Criteria are organized by category. Several map directly to what a penetration test evaluates.
| Trust Service Criteria | What It Covers | How Pen Testing Addresses It |
|---|---|---|
| CC4.1 | COSO Principle 16 — ongoing monitoring and evaluation | Independently validates that controls are working as designed |
| CC7.1 | Identification of vulnerabilities and changes that could impact the system | Active testing identifies vulnerabilities before attackers do |
| CC7.2 | Monitoring system components for anomalies | Test results show whether monitoring and alerting controls catch attack activity |
| CC3.2 | Risk assessment — identifies and analyzes risks | Pen test findings feed directly into the risk register |
| CC6.1 | Logical access security controls | Testing validates authentication, authorization, and access control implementation |
CC7.1 is where penetration testing fits most naturally. The criterion asks whether you identify vulnerabilities through ongoing activities, and pen testing is one of the clearest ways to demonstrate that.
Don’t overlook CC7.2 though. If your tester generates suspicious traffic during the engagement and your monitoring tools don’t alert on it, that’s a finding that matters to your auditor. A good pen test doubles as a test of your detection capabilities.
What Auditors Want to See in Your Report
The pen test itself isn’t enough. Auditors care about the documentation trail around it.
Scope Alignment
Your pen test scope should align with your SOC 2 system boundary. If your SOC 2 describes a SaaS platform running on AWS with a React frontend and a Python API backend, the pen test should cover those components. Testing an isolated staging environment that doesn’t match your production architecture won’t satisfy the auditor.
Testing Methodology
Auditors want to see that testing followed a recognized methodology: OWASP, PTES, or NIST SP 800-115. The report should describe the approach, not just list findings.
Clear Findings and Severity Ratings
Each finding needs a severity rating (critical, high, medium, low, informational), a description of the vulnerability, proof of exploitation or proof of concept, and a remediation recommendation. CVSS scores help but aren’t strictly required.
Remediation Evidence
This is where many organizations fall short. Your auditor will ask what you did about the findings. Having a pen test report that shows 12 high-severity findings with no evidence of remediation raises more questions than not having a report at all.
Keep records of your remediation work: tickets in your issue tracker, pull requests that fixed the vulnerabilities, and a retesting letter from your provider confirming the fixes.
Testing Frequency
Annual testing is the floor for SOC 2. If your audit period is 12 months, you need at least one pen test within that period. More frequent testing after major releases or infrastructure changes strengthens your posture and your audit.
Scoping a SOC 2 Penetration Test
Start with your SOC 2 system description. This defines the boundaries of what’s in scope for your audit, and your pen test should match.
Application Layer
If your SOC 2 covers a customer-facing application, web application penetration testing should be in scope. Authentication flows, role-based access controls, API endpoints, session handling, and customer data access patterns all need testing.
Multi-tenancy is particularly important here. If your application serves multiple customers from shared infrastructure, the pen test should specifically attempt cross-tenant data access. A tenant isolation failure would be one of the most significant findings in a SOC 2 context.
Cloud Infrastructure
Most SaaS companies undergoing SOC 2 audits run on public cloud infrastructure. Cloud penetration testing covers IAM misconfigurations, storage permissions, network segmentation, secrets management, and container or serverless security. Your auditor will want to see that these were tested, not just scanned.
External Network
External network penetration testing identifies what’s reachable from the internet: forgotten subdomains, exposed admin panels, open ports, and development environments that shouldn’t be public. These findings map directly to CC6.1 because they represent access paths that your controls should have prevented.
Internal Network
If your SOC 2 system boundary includes corporate infrastructure (an office network, VPN access, employee workstations), then internal network penetration testing should be part of the scope. This tests what an attacker with internal network access could achieve, including lateral movement between systems and privilege escalation to sensitive data stores.
SOC 2 Type I vs Type II: What Changes for Pen Testing
SOC 2 Type I evaluates controls at a point in time. Type II evaluates them over a period, usually 6 to 12 months.
For Type I, a single pen test performed around the time of the audit is usually sufficient. You’re demonstrating that controls exist and are designed correctly.
For Type II, auditors want to see that controls operate effectively over the entire audit period. That means your pen test should fall within the audit window, not before it started. If the audit covers January through December, a pen test from the previous November doesn’t count.
Evidence of remediation within a reasonable timeframe (30 to 90 days for high-severity findings) demonstrates that your vulnerability management process works. If you had a major infrastructure change mid-period, a second pen test covering the new environment strengthens the audit.
Most organizations pursuing SOC 2 are going for Type II, since that’s what enterprise customers ask for. Plan your pen testing schedule around your audit period from the start.
Common Findings That Impact SOC 2 Audits
Some pen test findings carry more weight in a SOC 2 context than others. Findings that map directly to Trust Service Criteria will get auditor attention.
Access Control Failures
Broken access controls are the most common and most impactful category. Horizontal privilege escalation (accessing another user’s data) and vertical privilege escalation (accessing admin functions as a regular user) directly undermine CC6.1. Multi-tenant isolation failures are particularly damaging because they mean one customer could access another customer’s data.
Authentication Weaknesses
Missing MFA enforcement, weak password policies, session tokens that don’t expire, and password reset flows that leak information. These map to CC6.1 and CC6.3 (registration and authorization processes).
Logging and Monitoring Gaps
If the pen tester runs brute-force attacks, SQL injection attempts, or port scans against your infrastructure and nothing generates an alert, that’s a control failure your auditor will note under CC7.2.
Encryption Issues
Unencrypted data in transit or at rest is a problem for CC6.7. This includes TLS misconfigurations, missing HSTS headers, and API responses sent over unencrypted channels.
Unpatched Software
Outdated software with known CVEs maps to CC7.1. If your pen test identifies published exploits in your software stack, it shows your patch management process isn’t working.
How DarkPoint Handles SOC 2 Pen Testing
DarkPoint has performed penetration testing for SOC 2 compliance across SaaS companies, fintech platforms, healthcare applications, and B2B startups. Our team knows what auditors expect and how to structure engagements accordingly.
Every engagement is scoped to match your SOC 2 system boundary. We review your system description before testing begins to make sure nothing in scope for the audit gets missed during the pen test.
Our reports include methodology descriptions, finding severity ratings with CVSS scores, proof-of-concept evidence, and remediation guidance that maps to the affected Trust Service Criteria. Auditors can trace each finding to the relevant criterion without guesswork.
Remediation retesting is included with every engagement. Once your team fixes the findings, we validate those fixes and issue a retesting letter you can provide to your auditor. This closes the loop that auditors care about most.
For organizations preparing for their first SOC 2 audit, we offer combined engagements that cover web application testing, cloud penetration testing, and external network testing in a single scope. This is more efficient than running separate tests with different providers and keeps the reporting consistent for your auditor.
If your SOC 2 includes social engineering controls, we also provide phishing engagements that test employee awareness and your incident response process under CC7.2 and CC7.4.
For more on how we approach compliance-related testing, see our guide on PCI DSS 4.0 penetration testing requirements. If you’re a SaaS company starting the SOC 2 process, our post on penetration testing for SaaS companies covers the application-specific testing that typically makes up the bulk of a SOC 2 pen test engagement. And if this is your first time scoping a test, how to prepare for a penetration test walks through the full process from scoping to remediation.
Bottom Line
SOC 2 doesn’t spell out “you must do a pen test” in those exact words. But every serious auditor expects one, enterprise customers look for pen test evidence in your SOC 2 report, and the Trust Service Criteria map directly to what a pen test validates. Treating it as optional puts your audit at risk and weakens your report compared to competitors who include it.
The key is alignment: match your pen test scope to your system boundary, test within your audit window, remediate findings on a documented timeline, and get retesting confirmation. That’s what turns a pen test from a checkbox into real audit evidence.
Ready to align your pen testing with SOC 2 requirements? Contact us to scope an engagement that covers your system boundary and gives your auditor exactly what they need.