Is a Pentest Required for SOC 2? What Auditors Expect (2026)
The Short Answer: Not Required on Paper, Required in Practice
SOC 2 is a principles-based framework, not a prescriptive checklist. The AICPA's Trust Services Criteria never say "you must conduct a penetration test." What they do contain, in CC4.1 and CC7.1, are requirements for ongoing and/or separate evaluations (CC4.1 does not require separate ones) and for vulnerability detection. In practice, a pentest is the most common way to evidence both.
Commercial reality compounds this. Enterprise procurement teams now routinely request Type II reports with pentest evidence before signing contracts. If your report period skips a pentest, the conversation shifts to "why not?", which is an uncomfortable place to be in a procurement review. The theoretical wiggle room exists, but using it costs more in lost deals than a pentest ever would.
What the Trust Services Criteria Actually Say
Three TSCs drive the auditor expectation around SOC 2 penetration testing requirements.
CC4.1: Monitoring Activities
CC4.1 governs how you evaluate whether controls actually operate, through ongoing and/or separate evaluations; it does not require separate ones. The AICPA's points of focus describe separate evaluations as performed periodically to provide objective feedback, and list penetration testing among the types of evaluation management may use. In practice, a pentest is the separate evaluation auditors most often expect: it confirms that authentication, access restrictions, and segmentation hold under adversarial conditions, which automated scanning alone rarely demonstrates.
CC7.1: System Operations
CC7.1 requires detection and monitoring procedures to identify vulnerabilities, and its points of focus describe vulnerability scans run "on a periodic basis and after any significant change." Automated scans cover known CVEs, but tend to miss configuration drift, business logic flaws, authentication bypass chains, and privilege escalation paths; a pentest (manual or AI-assisted) is the usual way to surface those.
A single well-scoped pentest generates evidence across five or more TSCs simultaneously: CC4.1, CC7.1, CC6.1 (logical access), CC6.6 (external threats), and CC8.1 (change management).
CC8.1: Change Management
CC8.1 requires changes to infrastructure, data, software and procedures to be tested and approved before they are implemented. It does not call for a pentest, but after significant changes (new APIs, cloud migrations, authentication system updates) auditors often look for security testing of what changed, and a targeted re-test is the usual way to show it. An annual pentest is the common auditor expectation, not a floor the criteria set.
What Auditors Actually Expect in 2026
Evidence standards have shifted: the gap most SOC 2 pentest guides miss entirely.
Three years ago, a pentest report with screenshots was broadly acceptable. In 2026, auditors weight system-generated logs far higher than screenshots, because logs are harder to fabricate and easier to cross-reference with other audit evidence. Your pentest deliverable now needs:
- Raw HTTP request and response data for every finding
- Reproduction steps a third party can independently verify
- Timestamps on all evidence capture
- Proof hashes (SHA-256 of the request/response pair) tying evidence to a specific point in time
Auditors are also asking how findings were tested. AI is now part of many pentesters' workflows, and a common question is whether findings stem from real HTTP interactions or pattern-matched speculation. Reports with actual captured traffic satisfy this regardless of whether AI was involved in the analysis.
See what your external surface exposes, mapped to the controls it touches.
Run a free External Security Check →Scope: What a SOC 2 Pentest Should Cover
A typical SaaS pentest for SOC 2 purposes covers four areas:
Web application layer: authentication flows, session management, authorization logic (horizontal and vertical privilege escalation), and business logic. Most directly relevant to CC6.1 and CC6.6.
API security: REST and GraphQL endpoints, token handling, rate limiting, and data exposure via error messages. Use our OWASP Risk Calculator to prioritize findings before your audit.
Network perimeter: exposed services, TLS configuration, and certificate validation. A quick SSL/TLS check before the formal test surfaces low-hanging fruit worth remediating first.
Infrastructure configuration: cloud storage access controls, misconfigured permissions, and security group rules. Common source of findings in post-change re-tests under CC8.1.
Physical security, social engineering, and denial-of-service testing are typically out of scope for a SaaS SOC 2 engagement.
How Often You Need to Run It
The baseline expectation is annual. First-time Type II reports typically cover a 3–6 month observation period; subsequent reports cover 12 months. An annual pentest maps cleanly onto a twelve-month window.
Two triggers require re-testing regardless of the calendar:
- Significant infrastructure changes: new cloud regions, authentication migrations, major dependency upgrades, new third-party integrations in the data path
- Significant product changes: new API endpoints, new roles and permission levels, changes to how customer data is stored or accessed
A practical approach: one full-scope annual test, plus scope-limited tests on changed components after major releases. This keeps evidence current without running a full engagement four times a year.
Cost Breakdown: Traditional vs. AI-Powered Alternatives
What a SOC 2 pentest costs depends far more on scope than on the framework. The main drivers are:
- Application scope: how many web applications, user roles, and business flows are in scope
- API surface: endpoint count and authentication complexity
- Testing approach and vendor tier: manual, AI-assisted, or hybrid, and whether you buy from a Big 4 firm, a boutique specialist, or a platform
- Retest and reporting: whether remediation retesting and SOC 2-mapped reporting are included in the price
Quotes vary widely, so compare them against the same written scope. Our penetration testing cost guide walks through how each driver moves the price. Pentesting is also one line item in a wider SOC 2 budget alongside the audit fee, compliance tooling, and internal time, so it is worth scoping carefully.
The key insight: auditors care about evidence quality, not vendor name. Boutique specialists generally cost less than Big 4 firms, with no difference in audit acceptance. AI-powered platforms deliver the same system-generated evidence (HTTP traffic, proof hashes, timestamped reproduction steps) in days rather than weeks. Check your current exposure before your audit window opens.
What Makes a Pentest Report Audit-Ready
Five qualities distinguish an audit-ready deliverable from one that generates follow-up questions:
- Self-standing evidence. Each finding includes raw HTTP request, response, timestamp, and proof hash; the auditor should validate independently.
- TSC mapping. Each finding identifies which Trust Services Criteria it relates to, saving auditor hours and preventing misclassification.
- Remediation verification. Findings fixed before the audit period closes include re-test evidence, a positive signal of a functioning CC4.1 monitoring process.
- Scope statement. The report defines what was tested, what was excluded, and why.
- Methodology disclosure. The report notes whether automated, manual, or AI-assisted analysis was used, and confirms findings are backed by real network interactions, not speculation.
Validate your stack's known exposure with our CVE Lookup tool before engaging a pentester; surfacing known vulnerabilities ahead of time means fewer surprises in the final report.
Frequently Asked Questions
Is penetration testing explicitly required for SOC 2?
No. The AICPA Trust Services Criteria do not name penetration testing as a mandatory control. However, CC4.1 calls for ongoing and/or separate evaluations (it does not require separate ones), and CC7.1 requires detection and monitoring procedures to identify vulnerabilities. In practice, a pentest is the most common way to evidence both, and auditors commonly expect one for a Type II report.
Which Trust Services Criteria are most relevant to penetration testing?
None requires it outright. CC4.1 (Monitoring Activities) and CC7.1 (System Operations) are the primary drivers. CC4.1 calls for ongoing and/or separate evaluations that confirm controls are operating (it does not require separate ones); CC7.1 requires detection and monitoring procedures to identify vulnerabilities. A single pentest generates evidence across both, and typically supports CC6.1, CC6.6, and CC8.1 as well.
How often do I need a pentest for SOC 2 Type II?
SOC 2 sets no frequency, but annually is the convention most auditors expect. If you make significant infrastructure or product changes during the observation period, auditors may also look for targeted re-testing of those changes as part of CC8.1 change management. Most SaaS teams run one full-scope annual test and add targeted post-release tests for major changes.
What does a SOC 2 pentest cost in 2026?
It depends on scope rather than on SOC 2 itself: the number of applications and API endpoints, authentication complexity, manual versus AI-assisted testing, the vendor tier, and whether retesting is included. Compare quotes against the same written scope; our penetration testing cost guide explains how each driver affects price. AI-powered alternatives with equivalent audit-grade evidence are available with faster turnaround.
Can an AI-powered pentest report satisfy SOC 2 auditors?
Yes, provided the evidence is real. Auditors care about evidence quality, not methodology. A report that includes actual captured HTTP traffic, timestamps, and proof hashes satisfies the same audit requirements as a manual pentest report. What auditors reject is AI-generated findings with no underlying network interaction, pattern-matched speculation rather than observed behavior.
How long before my audit should I run a pentest?
At least 6–8 weeks. You need time to remediate critical findings before the observation period closes. Running it the week before gives you the report but no remediation window; unresolved criticals will appear as audit exceptions.
What is the difference between a vulnerability scan and a pentest for SOC 2?
Scans are automated and find known CVEs and misconfigurations, satisfying part of CC7.1. Pentests include manual and AI-assisted adversarial testing that surfaces business logic flaws, auth bypass, and privilege escalation chains scanners miss. Both are expected; they are not substitutes.
Get Audit-Ready Evidence Before Your Next Assessment Period
The window between "we're pursuing SOC 2" and "our audit starts next month" closes faster than most teams expect. The pentest takes the longest to schedule, execute, and remediate, and it is the control auditors scrutinize most closely.
CyberOrbit runs 25+ security scanners with real HTTP evidence capture, delivering audit-grade reports with proof hashes and timestamped reproduction steps. The signed report typically follows within 2–5 business days once the assessment completes, not weeks. Request your assessment.