SOC 2 pentest requirements checklist for SaaS teams

What SOC 2 auditors and enterprise buyers usually expect from penetration test evidence, and how to prepare before the observation period.

SOC 2pentest checklistaudit evidenceCC7.1

SOC 2 does not prescribe one universal penetration testing template, but auditors and enterprise customers usually expect the same core evidence: scope, methodology, dates, access level, findings, severity, remediation, and retest status. The mistake many SaaS teams make is waiting until the auditor asks for evidence before they define what the pentest should cover.

Start with the system boundary. Your pentest scope should map to the systems described in your SOC 2 report: customer-facing web app, APIs, admin surfaces, identity provider integrations, cloud infrastructure, data stores, and any AI workflows that process customer data. If the pentest excludes a major production surface, write down why.

Methodology matters because it tells the auditor the work was structured. OWASP Testing Guide, OWASP API Security Top 10, NIST SP 800-115, PTES, and relevant AI security references are common anchors. You do not need to drown the report in methodology language, but you do need enough detail for the reviewer to understand what was tested and how.

Findings should be validated. A SOC 2 evidence package is weaker when it is just a list of possible vulnerabilities. Confirmed findings with screenshots, request and response evidence, reproduction steps, impact, remediation guidance, and retest status create a much stronger control story.

Map findings to control context where possible. For many teams, logical access, change management, monitoring, vulnerability management, and incident response are the areas that benefit from pentest evidence. CC7.1 and CC6.1 often come up in conversations, but exact mapping should match your auditor and system description.

Timing matters too. If your observation period is already active, a six-week scheduling cycle can create stress. A platform-assisted or service-led DeepScan engagement can start from approved scope and produce evidence faster, while still preserving human validation where required.

The practical checklist is: define scope, document exclusions, approve rules of engagement, test app and API paths, validate exploitability, write remediation-ready findings, retest fixes, export a report, and store the evidence in your GRC workflow. That is the level of structure buyers and auditors are usually looking for.