What SOC 2 Auditors Actually Check in a Pentest Report

Who this is for

If you're a CTO, engineering leader, or compliance manager responsible for SOC 2 Type II compliance, and you've just realized you need a pentest report to satisfy your auditor, this post covers what auditors actually scrutinize. You'll learn what ends up in the final report, how auditors grade it, and what questions to ask your vendor before you sign the contract.

Most pentest reports we see submitted to auditors get flagged for the same three gaps: missing scope documentation, no methodology section, and zero evidence of retesting. Those are easy to fix upfront—but only if you know what your auditor will ask for.

SOC 2 doesn't actually require a pentest

This is the part that surprises people. SOC 2 Type II compliance has no line that says "you must conduct a penetration test." The actual controls are CC7.1 (identifying changes that introduce new vulnerabilities and susceptibilities to newly discovered vulnerabilities) and CC7.2 (monitoring system components and detecting anomalies indicative of malicious activity). A pentest is not a control—it's evidence that the control works.

But auditors ask for one anyway, because a pentest is the clearest way to prove that your detection and response processes actually catch attackers. If you can show a pentest finding, a log entry, and an incident response, the auditor sees the control in action. A pentest report is a translation layer between what you've built and what your auditor needs to attest.

What auditors actually look for

The auditor isn't reading your pentest report for entertainment. They're checking for three specific things:

1. Scope coverage. Does the pentest cover the systems that are actually in scope for SOC 2? You have a "SOC 2 boundary" that defines which infrastructure, applications, and endpoints are subject to the control. The pentest scope needs to align with that boundary. If your boundary includes production databases but the pentest only tested web servers, you have a gap.
2. Methodology. What did the pentester actually do? Auditors want to see that you didn't just run a vulnerability scanner and call it done. They want evidence of active testing: network reconnaissance, privilege escalation attempts, lateral movement, data exfiltration scenarios.
3. Severity ratings and remediation. What vulnerabilities were found? Were they patched before the report was finalized? For any vulnerability that wasn't fixed immediately, is there documented risk acceptance from your security and engineering teams?

The report format problems that get flagged

We see four recurring issues:

1. Scanner output only. A vendor runs Nessus or Qualys, exports the CSV, and calls it a pentest report. Auditors flag this immediately. It's data, not analysis. An actual pentest report includes scope, methodology, manual testing results, and business-context recommendations.
2. Missing scope statement. The report doesn't explicitly say which systems, networks, or applications were in scope. The pentester tested production, but the report doesn't document that fact. The auditor assumes the scope is undefined and marks it down.
3. No methodology section. The report jumps straight from "Executive Summary" to "Findings." Auditors need to see what testing techniques were used, what tools, what timeframe, and how coverage was measured.
4. No retest evidence. After vulnerabilities are fixed, did the pentester come back and verify the fix? If there's no retest report attached, the auditor has no proof that the vulnerability is actually gone.

Timing and cadence matter

Plan to do your pentest 2–4 weeks before your official audit window opens. This gives you time to remediate findings and run a retest if needed. Most auditors expect pentest evidence to be within the last 12 months of the audit period, but closer is better—if your pentest is from January and your audit is in November, you might face questions about whether the environment has drifted.

For Type II audits (which typically cover 6–12 months), we recommend running pentests annually, in the same calendar window each year. This gives you a predictable cadence and makes remediation planning easier. Some organizations do a light pentest every 6 months and a deep pentest annually; that's a reasonable middle ground if your risk profile demands it.

Scope: what actually needs to be tested

Your "SOC 2 boundary" should have been defined during scoping with your auditor. Typically it includes:

• Production web applications and APIs exposed to customers
• Authentication systems (SSO, OIDP, MFA infrastructure)
• Data processing and storage systems that handle customer data
• Administrative access paths (bastion hosts, VPNs, employee laptops if they access production)
• Third-party systems that process customer data on your behalf (sometimes)

The pentest vendor needs to know which systems are in scope before they start. If they test everything in your AWS account but half of it isn't in the SOC 2 boundary, you're wasting time and money. Scope creep looks good on a vendor invoice but doesn't help your audit.

Pentest that finds bugs vs. pentest that passes audit

A pentest optimized for your audit is not the same as a pentest optimized for finding vulnerabilities. An audit-focused pentest prioritizes breadth and documentation over depth. It ensures scope is tight, methodology is explicit, and every finding is traced to a control.

A vulnerability-hunting pentest is deeper, slower, and often narrower in scope. It might spend two weeks privilege-escalating on a single system. That's valuable, but for SOC 2 it's not what you need.

The best practice: ask your vendor to do both. Run a focused SOC 2 compliance pentest tied to your boundary, get that report ready for audit, and separately schedule a quarterly security assessment that digs deeper into your highest-risk systems. One satisfies the auditor; the other actually hardens your infrastructure.

What to ask the pentest vendor

Before signing a statement of work, get clear answers to these questions:

1. What's included in your report template? Does it have sections for scope, methodology, tools used, testing timeline, and risk ratings? Ask to see a redacted sample.
2. How do you handle findings that can't be fixed in time? Will you document risk acceptance, or do you require all findings to be remediated before final delivery?
3. Is retest included? If we fix a critical vulnerability, do you come back and verify? Is that part of the deliverable or an add-on?
4. Will you work with our auditor directly? Some auditors want to discuss testing methodology with the pentester. Will your vendor do that call?
5. How do you scope this? Walk through your SOC 2 boundary definition with them and confirm they understand which systems are in and out of scope before work starts.

Handling findings before the audit window

If the pentest turns up a critical vulnerability, fix it before the final report is delivered. Auditors understand that vulnerabilities exist—they're checking whether you have a process for finding and fixing them. If a critical is sitting in your report with a status of "open," you're sending the message that nobody cares.

What we see in the field: The most common mistake is treating pentest findings like a backlog ticket. "We'll fix it in the next sprint." By the time the audit window opens, the vulnerability is still open, and the auditor marks you down for lack of urgency. If a finding is truly unfixable for business reasons, document that decision in writing. Risk acceptance signed by an executive beats a quiet unresolved vulnerability.

For findings that are fixed, the retest evidence is your proof. The auditor sees the original finding, the remediation plan, and the retest report showing it's gone. That's the control in action.

The short version

SOC 2 auditors expect a pentest report that explicitly documents scope (aligned to your SOC 2 boundary), methodology (not just scanner output), and remediation (with retest evidence for critical findings). Schedule the pentest 2–4 weeks before your audit window, confirm the vendor's report template includes methodology and scope sections, and ask upfront whether retest is included in the deliverable. A pentest optimized for compliance is not the same as one optimized for deep vulnerability hunting—you want the former for audit, the latter for defense. Most pentest reports get flagged for missing scope documentation or zero retest evidence; those are simple to prevent if you ask the right questions before signing the contract.