SOC 2 Penetration Testing Requirements: What Auditors Actually Expect in 2026
SOC 2 is the de facto standard for proving that your organization handles customer data responsibly. While the framework does not prescribe specific security tools, auditors consistently expect penetration testing as evidence that your controls work in practice, not just on paper.
This guide quotes what the Trust Services Criteria actually say, maps pentest findings to the criteria an examiner checks, shows when to test inside a Type I or Type II window, lists the evidence your auditor will ask for, and gives the US cost.
Does SOC 2 require penetration testing? Short answer
No, not by name. The Trust Services Criteria themselves never use the words; the 2022 points of focus mention penetration testing once, under CC4.1, and auditors treat a current test as expected evidence for CC4.1 and CC7.1, especially inside a Type II review period. Run one test every 12 months, plus a retest after remediation and a fresh test after major changes.
Key takeaways
- SOC 2 does not mandate a pentest; most auditors mark its absence as a gap under CC4.1
- Map findings to CC4.1, CC4.2, CC6.1, CC6.6, CC6.7, CC7.1, CC7.2 and CC9.1
- Test inside the Type II window, remediate, retest; hand over the retest letter
- Cost on Budget Security: $985 per tester-day, so $2,955 to $4,925 for a 3 to 5 day single-application scope
What SOC 2 Says About Penetration Testing, Verbatim
The AICPA's Trust Services Criteria (TSC 2017, with the 2022 revised points of focus) mention penetration testing exactly once, and vulnerability scanning once. Both appear as points of focus, the illustrative detail under a criterion, not as criteria themselves. That is why "SOC 2 requires a pentest" is technically wrong and practically right.
CC4.1 (COSO Principle 16), point of focus "Considers Different Types of Ongoing and Separate Evaluations":
"Management uses a variety of different types of ongoing and separate evaluations, including penetration testing, independent certifications made against established specifications (for example, ISO certifications), and internal audit assessments."
CC7.1, point of focus "Conducts Vulnerability Scans":
"The entity conducts vulnerability scans designed to identify potential vulnerabilities or misconfigurations on a periodic basis and after any significant change in the environment and takes action to remediate identified deficiencies on a timely basis."
Read together, the two passages draw the line most teams miss: scanning answers CC7.1, and the separate evaluation under CC4.1 is where the penetration test sits. An auditor who receives only a scanner export has CC7.1 evidence and nothing for CC4.1. The criteria that a pentest then supports in practice are CC4.2 (evaluating and communicating deficiencies), CC6.1, CC6.6 and CC6.7 (logical access, boundary protection and data in transit), CC7.2 (monitoring for anomalies) and CC9.1 (risk mitigation), which the mapping table below walks through.
Source: AICPA, TSP Section 100, 2017 Trust Services Criteria for Security, Availability, Processing Integrity, Confidentiality, and Privacy (with revised points of focus, 2022). Quote the criteria to your auditor by ID; they will recognise them.
What SOC 2 Requires for Security Testing
SOC 2 is built around five Trust Services Criteria (TSC) defined by the AICPA. Penetration testing directly supports several of these criteria by providing independent verification that your security controls actually prevent unauthorized access and data exposure.
Security (CC6/CC7)
Controls that protect against unauthorized access. Pentesting validates that firewalls, access controls, and authentication mechanisms function correctly.
Availability (A1)
Controls ensuring systems remain operational. Pentesting identifies denial-of-service risks and infrastructure weaknesses that could cause downtime.
Confidentiality (C1)
Controls that restrict access to sensitive data. Pentesting checks for data exposure through insecure APIs, misconfigured storage, and broken authorization.
Risk Assessment (CC3)
Processes for identifying and evaluating threats. A penetration test provides concrete evidence that your risk assessment covers real-world attack scenarios.
Auditors reviewing your SOC 2 controls want to see that you test your own defenses. Vulnerability scans alone are not sufficient. A manual penetration test demonstrates that a skilled tester attempted to bypass your controls and documents what they found. This is the strongest evidence you can provide for control effectiveness.
To make this concrete, here is how penetration test findings map to the criteria an examiner checks:
| Criteria | What a pentest proves |
|---|---|
| CC4.1 (Separate evaluations) | The pentest is the separate evaluation the point of focus names. The report is the primary artefact. |
| CC4.2 (Communicating deficiencies) | Findings delivered to management with severity and owners, plus the remediation tickets, show deficiencies were communicated and tracked. |
| CC6.1 (Logical access software) | Authentication and authorization testing across roles and tenants proves access controls hold under attack. |
| CC6.6 (External threats) | External network and web application testing demonstrates boundary controls block unauthorized access from outside. |
| CC6.7 (Data in transit and removal) | TLS, session and data-exposure findings (or their absence) evidence that data is protected in motion. |
| CC7.1 (Vulnerability scans) | Scanning inside the engagement, with results validated by hand, covers the scanning point of focus. |
| CC7.2 (Anomaly monitoring) | Whether your monitoring detected the test activity is itself evidence: the tester's timeline versus your alert log. |
| CC7.4 (Incident response) | The remediation trail and retest confirm you act on identified vulnerabilities. |
| CC9.1 (Risk mitigation) | Findings mapped to business impact feed the risk register and show mitigation activities are selected and applied. |
Type I vs Type II: When Pentesting Matters Most
SOC 2 audits come in two forms, and each has different implications for penetration testing:
Type I (Point-in-Time)
- Evaluates control design at a single date
- Often used as a first step toward Type II
- One pentest report covering your current state is typically sufficient
- Faster to achieve, but less trusted by enterprise buyers
- Good starting point for startups pursuing their first SOC 2
Type II (Over a Period)
- Evaluates control effectiveness over 6 to 12 months
- Requires evidence of ongoing security practices
- Annual pentesting (or more frequent) is expected
- Remediation evidence strengthens your report
- Required by most enterprise procurement teams
For Type II audits, a single pentest is rarely enough. Auditors want to see that you test regularly and that you act on the findings. Showing a pentest report alongside evidence of remediation (retesting, patched vulnerabilities, updated configurations) is what separates a clean audit from one with exceptions noted.
The Requirement in Practice: Criteria vs Points of Focus
Not by name. The criteria themselves never use the words "penetration test"; only the 2022 points of focus mention it, once, under CC4.1. This is the single biggest point of confusion for teams preparing for a SOC 2 audit, so it is worth being precise: there is no line item that says you must run a pentest.
What the criteria do require is evidence, and the CC4.1 point of focus quoted above names penetration testing as the kind of separate evaluation management is expected to use. In practice most companies that pass SOC 2 run a pentest even though no rule forces them to, and many auditors note its absence as a gap. For the full yes-or-no reasoning, including the Type I edge cases, read Does SOC 2 require a penetration test?
Bottom line: SOC 2 does not mandate a penetration test, but auditors expect one as evidence under CC4.1 and the CC7 series. Treat it as required in practice, not optional.
What a SOC 2 Penetration Test Covers
A SOC 2 penetration test scopes around the systems that touch your in-scope data and the controls your auditor will examine. There is no fixed SOC 2 pentest checklist, but a thorough engagement for a typical SaaS or cloud company covers the following:
- External network testing of internet-facing infrastructure, firewalls, and exposed services
- Web application testing against the OWASP Top 10: broken access control, injection, authentication and session flaws, and business-logic abuse
- API testing for authorization gaps, broken object-level authorization (BOLA/IDOR), and data exposure
- Cloud configuration review of your AWS, Azure, or GCP environment for misconfigured storage, over-permissive IAM, and exposed secrets
- Internal network and privilege-escalation testing where lateral movement could expose customer data
- Authentication and authorization testing across roles, tenants, and multi-factor enforcement
Your exact scope depends on your architecture and which Trust Services Criteria you committed to in your audit. A single-product SaaS company usually needs web application and API testing plus a cloud configuration review. A company running its own infrastructure adds external and internal network testing. When you scope your engagement on the Budget Security platform, you select the systems that map to your criteria so you are not paying to test surfaces that fall outside your audit.
Timeline and Cost: Fitting a Pentest Into Your Audit Window
How often does SOC 2 require a penetration test?
At least once every 12 months, timed so the test, remediation and retest all fall inside your Type II review period, plus a fresh test after any significant change such as a major release or infrastructure migration. Type I needs one current test before the point-in-time date.
When to test
The biggest scheduling mistake teams make is booking a pentest too late. A penetration test almost always surfaces findings, and you need time to remediate before your auditor reviews your evidence. For a Type II audit, run your test early in the review period, not at the end, so remediation and a retest both land inside the window your examiner is assessing.
A practical 90-day sequence inside a Type II window: book by week 1, test in weeks 2 to 3, remediate in weeks 4 to 8, retest in week 9, and hand the full evidence set to your auditor by week 12. For a Type II report, that full cycle of test, fix, and retest is exactly the operating-effectiveness story your auditor wants to see.
How long it takes
A focused SOC 2 penetration test for a single web application and its API typically runs three to five tester-days. Broader scopes that add cloud infrastructure or internal network testing run longer. With Budget Security you scope and book online, testing starts within 24 hours of booking, and the report is delivered within 7 days through the platform, so your evidence is ready as soon as testing completes.
SOC 2 pentest cost in the US
The US market range for a SOC 2 penetration test is $5,000 to $20,000, because the scope is usually an external and web application test, sometimes with an internal segment. Budget Security bills $985 per tester-day for US clients (€849 per day in the EU). A typical single-application SOC 2 scope of three to five tester-days is therefore $2,955 to $4,925, with the report and one retest included and delivery in 7 days. You see the price before you commit: enter your scope in the penetration testing cost calculator and the platform returns a fixed number you can put straight into your audit budget. No sales calls, no custom-quote delays.
Evidence Your Auditor Will Ask For
The report alone is not the evidence set. This is the checklist a SOC 2 examiner works through, in the order they usually ask. Every Budget Security engagement produces each item through the platform.
- Scope statement with the in-scope systems and the test dates, so the auditor can confirm the test falls inside the review period
- Tester credentials: name, certification (OSCP, OSWE, CREST), and the independence of the testing provider from the audit firm
- Methodology reference: OWASP Testing Guide, PTES, or NIST SP 800-115, stated in the report
- Findings report with CVSS scores, exploitation evidence (requests, screenshots) and business impact per finding
- Remediation tickets showing owner, date, and fix for each finding, linked from the report
- Retest letter or retest report confirming which findings were closed and which were accepted as risk
- Letter of attestation summarising scope, dates, method and outcome on the provider's letterhead
- Upload location: most teams store the set in Vanta, Drata, Secureframe, Thoropass or Sprinto against the CC4.1 and CC7.1 controls
Missing any one of these is the most common reason a pentest gets marked as an exception rather than as evidence. The retest letter is the item teams forget most often.
How Budget Security Helps You Pass Your SOC 2 Audit
Budget Security delivers penetration testing built for organizations going through SOC 2 audits. You scope your engagement, see a fixed price, and schedule testing through the platform. $985 per tester-day for US clients, €849 per day in the EU, testing starts within 24 hours, report in 7 days.
Scope your test online
Use our platform to define what needs testing: web applications, APIs, cloud infrastructure, or internal networks. Our scoping tool helps you cover the systems that map to your SOC 2 Trust Services Criteria.
Certified testers, manual methodology
Every engagement is performed by OSCP and OSWE certified penetration testers. We follow OWASP, PTES, and NIST SP 800-115 methodologies to ensure thorough coverage.
Audit-ready reports with TSC mapping
Our reports include an executive summary, detailed technical findings with CVSS scores, exploitation evidence, and clear remediation steps. Each finding references the relevant SOC 2 control criteria so your auditor can trace it directly.
Remediation verification included
After you fix the reported issues, we retest to confirm the vulnerabilities are resolved. This gives your auditor documented proof that findings were addressed, which is critical for Type II engagements.
Get Your SOC 2 Pentest Quote
See exactly what your SOC 2 penetration test would cost. Enter your scope, get a fixed price. No sales calls, no waiting, and reports your auditor can use directly.
Looking for the bigger picture? Explore all our penetration testing services covering web, network, API, mobile, and cloud.
FAQ