SOC 2 Pentest Requirements Explained

If you’re preparing for a SOC 2 examination, “do we need a penetration test?” is one of the first questions that comes up. The honest answer is more nuanced than a yes or no, and the follow-up questions (when to test, and what it costs) matter just as much for hitting your audit date without a scramble.

Does SOC 2 technically require a pentest?

Not explicitly. The SOC 2 Trust Services Criteria do not name “penetration test” as a required control; it appears only as one example of a separate evaluation in the CC4.1 points of focus. But in practice, a penetration test is one of the most common ways companies demonstrate the Security criterion (specifically the controls around vulnerability management and system monitoring), and most auditors will ask for one as supporting evidence if you don’t already have a recent report on file. SOC 2 is one of several frameworks where the requirement is effectively real even when the text is indirect. Our overview of compliance frameworks that require penetration testing covers how the others compare. If you sell into the defense supply chain, CMMC Level 2 follows the same pattern: its NIST SP 800-171 assessment controls expect testing evidence without ever naming a pentest outright, and our guide to NIST SP 800-171 penetration testing lists the practices a test evidences.

Enterprise customers evaluating your SOC 2 report often ask directly, too. A clean penetration test report alongside your SOC 2 report answers a question your report alone doesn’t: has anyone actually tried to break in? When buyers ask for ISO 27001 as well, or health systems ask for HITRUST, the same test can serve both reports; our comparisons of ISO 27001 vs SOC 2 and HITRUST vs SOC 2 explain how.

What your auditor wants to see

• Recency. Testing performed within the last 12 months, ideally timed so results land inside your examination period.
• Appropriate scope. Testing that covers the systems actually in your SOC 2 boundary, not a generic scan of unrelated infrastructure.
• A real report, not a scanner export. Executive summary, methodology, findings with severity ratings, and remediation status. Request a sample report to see what auditors expect.
• Evidence of remediation. Findings that were identified and fixed, ideally with a retest confirming the fix.
• Independence. Testers who didn’t build or operate the systems they’re assessing. An internal team can technically run the test, but a third-party penetration testing report from an independent firm carries more weight with both auditors and the enterprise customers reading your SOC 2 report downstream.

Type I vs. Type II: when in the audit window to test

The two report types create different timing problems, and getting this wrong is the most common way a pentest ends up wasted as audit evidence.

Type I examines the design of your controls at a single point in time. Here the pentest is straightforward: complete testing, and remediation of anything significant, before the as-of date, so the auditor can see a recent report and closed findings when they assess control design. A test finished two weeks after your as-of date does nothing for a Type I.

Type II examines whether your controls operated effectively over an observation period, typically 3 to 12 months. The pentest now needs to land inside that window to serve as operating evidence. Two timing traps:

• Testing before the window opens. A pentest completed a month before your observation period starts is design-time evidence at best. Many auditors will still consider a recent report, but a test dated inside the period is unambiguous.
• Testing in the final days of the window. If the test surfaces a critical finding on day 350 of a 365-day period, there is no time to remediate and retest before the window closes, and the auditor sees an open critical instead of a demonstrated vulnerability-management cycle.

The sweet spot for Type II is to run the test 1 to 3 months before the observation period ends. That places the report squarely inside the window and leaves enough runway to fix significant findings and complete a retest before the period closes. The evidence package your auditor ends up with is exactly what they want: a dated report inside the period, remediation tracking, and retest confirmation that the fixes held: a complete find-fix-verify loop, which is the control actually being examined.

If you run SOC 2 annually (most companies renewing Type II do), this becomes a rhythm: schedule the pentest at the same point in each observation period, and every year’s report carries current evidence without any calendar heroics.

What a SOC 2 pentest costs

SOC 2-driven penetration tests typically run $4,000 to $15,000 for most SaaS companies, depending on the size of the system boundary: primarily the web application, its APIs, and the external network perimeter. Larger platforms with many roles and services can run higher. Our guide to penetration testing for SaaS companies covers what a SaaS scope usually includes.

Invadel’s fixed prices for the engagements SOC 2 audits most often need:

• Web application penetration test, from $5,200
• External network penetration test, from $4,200
• API penetration test, from $4,000

Every engagement includes the retest after you remediate, which matters more under SOC 2 than almost anywhere else, because the retest is part of the evidence. Full details are on our pricing page; the number is fixed before you sign and doesn’t move afterward.

Timing it before your audit

Whatever your report type, the sequencing inside the engagement matters. Run the test with enough lead time to:

1. Receive the report
2. Remediate any significant findings
3. Get a retest confirming the fix
4. Have all of that finished before your auditor’s fieldwork begins

Waiting until the week before your audit to schedule testing is the most common mistake we see: if something significant is found, there’s no time left to fix it before the auditor asks about it. Build backwards from your audit date: most engagements need 2 to 3 weeks from kickoff to final report, plus your own remediation time, plus the retest.

Vanta and Drata compatibility

If you’re using a compliance automation platform like Vanta or Drata, your penetration test report and remediation evidence should be uploadable as supporting documentation against the relevant control. Ask whoever runs your test to format the report and any attestation letter so it drops cleanly into your existing evidence library instead of requiring reformatting. Our list of SOC 2 penetration testing providers explains how the Vanta and Drata partner directories work, and why a listing is not required.

What a SOC 2-ready report includes

• Executive summary written for a compliance manager or auditor, not just an engineer
• Scope aligned to your SOC 2 system boundary
• Findings mapped to the controls they relate to
• A retest confirming remediated findings are actually closed
• An attestation letter, if your auditor or customer needs one

Getting it scheduled

Our SOC 2 penetration testing evidence checklist lists every item an auditor asks for and the criterion each one maps to. The pentest is one of the few SOC 2 evidence items you can’t produce internally at the last minute, so it’s worth locking the date early. Our SOC 2 penetration testing services page covers how we scope and time testing around your examination period, and which Trust Services Criteria each finding maps to. When you’re ready for a number, scope your test: tell us your audit date and what’s in your system boundary, and we’ll send back a fixed-cost proposal built around your observation period, with onboarding starting within 24 hours of signing.