SOC 2 Penetration Testing: What Auditors Actually Expect

SOC 2 penetration testing: the requirement that isn't written down

SOC 2 doesn't technically require a penetration test. That's the technically correct answer.

Here's the practical answer: 94% of SOC 2 auditors expect to see pentest evidence for a Type II audit. Skip it, and you're either going to fail, get a qualified opinion, or spend three weeks in back-and-forth with your auditor explaining why you didn't do one.

The gap between "not technically required" and "auditors expect it anyway" is where a lot of companies get burned. This post covers exactly what auditors actually want—scope, timing, report format, remediation evidence—so you're not guessing.

Why auditors expect a pentest even though it's not mandatory

SOC 2 is built around Trust Services Criteria (TSC). The one that matters most for penetration testing is CC4.1, which requires that the organization "selects, develops, and performs ongoing and/or separate evaluations to ascertain whether the components of internal control are present and functioning."

That's AICPA-speak for: prove your controls actually work, not just that you wrote them down.

A pentest is the most direct way to demonstrate CC4.1. You can write a vulnerability management policy, document your firewall rules, and configure your WAF — but a pentest shows whether an attacker could actually bypass all of it. Auditors know that.

Two other criteria also come into play:

• CC6.1: Logical and physical access controls. A pentest validates whether your access restrictions hold up under real adversarial pressure.
• CC7.1: System monitoring. Pentest findings help auditors assess whether your detection capabilities would actually catch an intrusion.

None of these say "you must pentest." But they all point in the same direction. And auditors filling out their checklists know it.

Type I vs. Type II: why the distinction matters

SOC 2 Type I is a point-in-time audit. It evaluates whether your controls are designed appropriately as of a specific date. A pentest conducted before the audit date satisfies most auditors for a Type I.

SOC 2 Type II is where it gets more demanding. A Type II covers an observation period — typically 6 to 12 months — and evaluates whether those controls operated effectively throughout that entire window. Your pentest needs to fall within the audit observation period, not just before it.

If your Type II covers January through December and your only pentest was in January of the previous year, you're going to have a problem. Auditors expect to see a test that's representative of your security posture during the period they're auditing.

The practical implication: schedule your pentest 3 to 4 months into your audit observation period. That gives you time to remediate findings before the period closes, while keeping the test date clearly inside the window.

What scope auditors expect to see covered

Your pentest scope needs to align with your SOC 2 system boundary. Whatever systems you've described as part of your in-scope environment should be tested. That typically means:

• Customer-facing applications: Your main product, web app, any portals customers log into
• APIs: Public and partner-facing APIs that handle customer data
• Cloud infrastructure: AWS, Azure, or GCP environments that support in-scope systems
• Authentication flows: SSO, MFA, identity provider configurations
• Admin and support portals: Internal tools that give your team access to customer data
• Remote access: VPN, jump servers, any external entry points into your internal network

A common mistake is scoping the pentest narrowly to the marketing site or a single application while excluding the admin panel, the internal API, or the cloud infrastructure. Auditors notice when the scope doesn't match the system description in your SOC 2 report.

Talk to your auditor before finalizing scope. They won't design the pentest for you, but most will confirm whether your planned scope would support the evidence they're looking for. It's a five-minute conversation that can save you from a scope disagreement mid-audit.

What the pentest report needs to contain

Not all pentest reports satisfy auditors equally. A 200-page automated scanner export with no analyst commentary won't cut it for SOC 2. What auditors want to see:

Independence: The test must be conducted by a qualified third party. Internal security teams can do a lot of valuable work, but self-testing doesn't satisfy the "independent evaluation" intent of CC4.1.

Methodology: A brief description of the approach. Black box, gray box, or white box testing? Manual testing or tool-assisted? OWASP, PTES, or another recognized methodology? Auditors want to know the test was systematic.

Findings with severity ratings: CVSS (Common Vulnerability Scoring System) scores are standard. Each finding should have a severity classification — critical, high, medium, low — along with a description of the vulnerability and its potential business impact.

Remediation status: Was the finding fixed? Partially mitigated? Accepted as a risk? The report needs to show the disposition of every finding, not just the initial discovery.

Retest evidence: For high and critical findings, auditors expect to see documentation that remediation was verified. Most pentest providers include a retest phase where they confirm fixes are effective. If yours doesn't offer this, ask.

The report date matters too. Auditors check whether the test falls within the audit period. A test completed two days before the observation window closes is technically valid but raises eyebrows. Aim for a test date that gives you time to remediate before the window ends.

The remediation evidence auditors want

Passing a pentest isn't the goal. Remediating the findings is.

Auditors reviewing SOC 2 evidence don't just want to see that you ran a pentest. They want evidence that your organization took the findings seriously and addressed them. That means:

• A documented remediation plan with timelines and owners for each finding
• Status updates showing which findings were fixed, when, and by whom
• Retest results confirming that fixes worked
• Risk acceptance documentation for any findings you decided to accept rather than fix, including the rationale

If you fixed 14 of 15 findings and accepted one low-severity issue as a known risk with compensating controls, that's a defensible position. If you fixed nothing and have no remediation documentation, that's an audit problem regardless of how clean your pentest results were.

How to choose a provider for SOC 2 specifically

Not every pentest provider knows what SOC 2 auditors expect to see in a report. Before you engage someone, ask:

• Have you worked with companies going through SOC 2 audits before?
• Does your report format include CVSS scores, severity ratings, and remediation status?
• Do you offer a retest after remediation?
• Can you scope the engagement to match our SOC 2 system boundary?

If the answer to any of those is "we'll figure it out," keep looking. A provider who understands SOC 2 context will ask for your system description upfront and align their scope and report format to what your auditor expects.

For more on what to ask before hiring, see our questions to ask before hiring a penetration testing firm — many of those questions apply directly to compliance-driven engagements.

Timing your pentest for the audit cycle

If you're planning a SOC 2 Type II audit, here's a practical timeline:

1. Start of observation period: Establish your baseline. Make sure your controls are documented and functioning.
2. Month 3–4: Schedule and conduct the penetration test. This gives you enough runway to remediate before the period closes.
3. Immediately after the test: Begin remediation. Prioritize critical and high findings first.
4. 4–6 weeks after the test: Conduct retest to verify fixes on material findings.
5. Before the audit: Compile remediation evidence — tickets, retest reports, configuration changes, or code commits showing the work was done.
6. Audit: Provide the pentest report, retest results, and remediation documentation to your auditor.

One scheduling trap to avoid: running the pentest in the final month of your observation period. Even if the test goes perfectly, you won't have time to remediate meaningful findings before the audit — and that creates exactly the documentation gap auditors flag.

What a "good" SOC 2 pentest actually looks like

To make this concrete: a SOC 2-aligned pentest for a typical SaaS company usually involves 8–12 days of testing across the full in-scope environment. It includes both external testing (simulating an outside attacker trying to get in) and internal testing (simulating a compromised user or insider threat moving laterally). It's manual, not just automated scanner output.

The final report has executive summary, methodology, full findings list with CVSS scores and remediation guidance, and an appendix showing what tools were used. A retest is included as part of the engagement.

This is also why pentest cost varies significantly based on scope. As we covered in our penetration testing cost guide, a typical web application and infrastructure test runs $15,000–$30,000 depending on scope complexity. That's not a place to cut corners if SOC 2 is the objective.

---

Trying to figure out what your SOC 2 pentest should actually cover? Book a free consultation with our team and we'll walk you through what a pentest engagement looks like for your stack.