Penetration Testing for SOC 2 Compliance: What Auditors Actually Want

Why SOC 2 and penetration testing are connected

SOC 2 Type II doesn't mandate a pentest by name in the Trust Services Criteria — but the CC6.1 and CC7.1 controls around "logical access controls" and "system monitoring" are nearly impossible to satisfy without one. In practice, every auditor from a recognized firm will ask for it.

The question isn't whether you need a pentest for SOC 2. You do. The question is what form the evidence needs to take for your auditor to accept it.

What auditors actually ask for

When an auditor asks for pentest evidence, they're looking for four specific things:

• Scope definition — What was tested, what was explicitly excluded, and why. An audit that tests "some endpoints" is not acceptable.
• Findings list with severity ratings — Each finding needs a risk rating (Critical/High/Medium/Low) and a CVSSv3 score. Opinion-based severities without numeric scoring get questioned.
• Remediation evidence — Not just a list of fixes, but written confirmation from the tester that the fixes were verified. This is the retest confirmation letter.
• Tester qualifications — The auditor may ask who performed the test. CREST, OSCP, or equivalent certification helps here.

The single most common reason a company has to redo a pentest before their SOC 2 audit is missing retest confirmation. The vendor fixed the findings but never got written sign-off from the tester.

The timing question: when to run it

Most teams run their pentest too close to the audit date. The problem: if the test surfaces High or Critical findings (likely), you need time to remediate and retest before handing the evidence to your auditor.

A practical timeline that avoids last-minute scrambling:

• 12 weeks before audit — Finalize scope, sign statement of work
• 10 weeks before — Active testing begins
• 8 weeks before — Initial report delivered, remediation starts
• 5 weeks before — Fixes submitted for retest
• 4 weeks before — Retest complete, confirmation letter issued
• Audit week — Evidence package submitted to auditor

This gives you buffer for a second remediation round if the first fixes don't fully close the issues.

What the report format should look like

Auditors review hundreds of pentest reports. They have expectations about format. A report that's structured for internal engineering readers won't satisfy an auditor's checklist.

The sections your report needs:

• Executive summary — One-page overview including total finding count by severity, scope summary, and overall risk posture. The auditor reads this first.
• Scope and methodology — Explicit list of in-scope assets (domains, IP ranges, API versions), testing methodology (OWASP WSTG, manual exploitation, auth testing), and dates of testing.
• Findings with evidence — Each finding needs: title, severity, CVSS score, affected component, description, reproduction steps, and a remediation recommendation. Evidence screenshots or request/response pairs confirm the finding is real, not theoretical.
• Remediation status table — A summary table showing each finding and its current status: Open, In Progress, or Remediated.
• Retest section — A separate signed section confirming which findings were retested, what remediation was verified, and the date of verification.

The difference between a pentest report and a vulnerability scan report

Automated vulnerability scanners produce output. Penetration tests produce evidence. Your auditor knows the difference.

A scanner report lists potential vulnerabilities based on version numbers and configuration signatures. A pentest report documents vulnerabilities that were actively exploited, with the HTTP request and response that demonstrates the exploitation worked.

If your report contains lines like "CVE-2023-XXXX may affect this system version," your auditor will likely push back. Findings need to be confirmed exploitable, not theoretical.

Business logic vulnerabilities: the gap scanners can't fill

SOC 2 auditors are increasingly aware of application-layer risks. A scan that finds no CVEs in your infrastructure but misses a broken object-level authorization flaw in your API isn't demonstrating adequate security testing.

Manual testing covers the attack surface that matters for a SaaS product: authentication bypass, session management weaknesses, privilege escalation between accounts, and insecure direct object references. These don't appear in scanner output. They require a tester who understands how the application is supposed to work and can find the places where it doesn't.

What happens if findings are still open at audit time

Open High or Critical findings at audit time create a problem. Your auditor has to note them. The question is how.

Some auditors will accept a "remediation in progress" notation with a committed completion date and an updated risk register. Others will flag it as a control deficiency. This depends on the auditor and how old the finding is.

The safest position: no open Critical or High findings at audit time. For Medium and Low findings, document the remediation plan with specific dates and who owns each item.

Using the pentest report in enterprise sales

This is the value most teams miss: the pentest evidence package you prepare for SOC 2 is the same package your enterprise prospects want during vendor security reviews.

When a prospect's security team sends a vendor questionnaire, one of the first questions is: "Do you perform regular penetration testing? Can you share the most recent report or a summary?"

A redacted pentest report with a clean retest confirmation letter answers this question directly and signals that your security posture is real, not self-reported. It shortens security review cycles and removes a common reason deals stall.

What to include in the evidence package you hand to your auditor

The final artifact set for SOC 2 should contain:

1. Full pentest report (scope, methodology, findings, CVSS scores)
2. Remediation evidence (screenshots, code diffs, or configuration change logs for each remediated finding)
3. Retest confirmation letter signed by the testing firm, confirming each finding's remediation status
4. Scope agreement or statement of work showing what was in scope

Some teams also include a management response letter — a brief document where your engineering lead acknowledges the findings and confirms the remediation plan for any items still open. This signals process maturity.