Pentest Report for SOC 2 Compliance - What Auditors Actually Want to See

Does SOC 2 Actually Require a Pentest?

Technically, SOC 2 does not explicitly mandate penetration testing. The AICPA Trust Service Criteria do not contain a line item that says "perform a penetration test." However, Trust Service Criteria CC7.1 (Detection of Changes) and CC7.2 (Monitoring for Unauthorized or Suspicious Activities) are where penetration testing fits naturally. These criteria require organizations to detect unauthorized changes and monitor for threats - and a pentest directly demonstrates that you are proactively identifying vulnerabilities before attackers do.

In practice, most auditors expect to see pentest evidence for a clean Type II report. If your organization handles sensitive customer data and claims to follow security best practices, the auditor will ask for pentest documentation. Arriving at your SOC 2 audit without a recent pentest report is like showing up to a driving test without a car. You might technically be able to argue your way through it, but it will not go well.

The key distinction is between Type I and Type II audits. A Type I audit evaluates controls at a point in time. A Type II audit evaluates controls over a period - typically 6 to 12 months. For Type II, the pentest should fall within the audit period, and ideally the report should show remediation of findings discovered during that period. This demonstrates not just that you test, but that you act on results. If you need help structuring your report for any compliance framework, our pentest report template guide covers the fundamentals.

What Auditors Look for in a Pentest Report

Scope That Matches Trust Service Criteria Boundaries

The pentest scope must cover the systems within the SOC 2 boundary. If your SOC 2 report covers a SaaS platform, the pentest should cover that platform - not a different product, not a staging environment, not a subset of the production infrastructure. Auditors will compare the scope section of your pentest report against the system description in the SOC 2 report. A mismatch is one of the most common reasons pentest reports get flagged during an audit.

Be explicit about what was included and excluded. List IP ranges, application URLs, API endpoints, and cloud environments. If certain systems were excluded from the pentest scope, document why. "The payment processing subsystem was excluded because it is covered under a separate PCI DSS assessment" is a valid explanation. "We ran out of time" is not.

Defined Methodology

Auditors want to see that you followed a recognized testing framework - OWASP Testing Guide, PTES (Penetration Testing Execution Standard), or OSSTMM. The specific framework matters less than having one documented. Ad-hoc testing with no methodology reference signals to auditors that the assessment may not have been thorough or consistent. State the framework, describe how it was applied to the engagement, and reference the version used.

Findings Mapped to Trust Service Criteria

This is where pentest reports for SOC 2 differ from standard pentest reports. Each finding should reference which Trust Service Criteria it impacts. The relevant criteria are:

• CC6.1 (Logical Access) - findings related to authentication, authorization, and access control. SQL injection, broken authentication, privilege escalation, and weak password policies map here.
• CC6.6 (System Boundaries) - findings related to system boundaries and external threats. Missing security headers, insecure API endpoints, SSRF, and network segmentation issues map here.
• CC7.1 (Change Detection) - findings related to detecting unauthorized changes. Outdated dependencies with known CVEs, unpatched systems, and configuration drift map here.
• CC7.2 (Anomaly Monitoring) - findings related to detecting and responding to anomalies. Lack of logging, insufficient monitoring, and missing alerting map here.

Adding a TSC column to your findings table takes minimal effort and dramatically increases the report's value for SOC 2 purposes. An auditor who sees findings mapped to specific criteria can immediately validate that the pentest addresses the controls they need to evaluate.

CVSS Scoring

Auditors expect standardized severity ratings. CVSS 3.1 is the standard. Every finding should include a CVSS base score and vector string. This provides an objective, industry-recognized measure of severity that auditors can reference in their workpapers. Custom severity ratings without CVSS backing will raise questions. If you need a refresher on scoring, check our guide on calculating CVSS scores.

Remediation Evidence

For a Type II audit covering a period, auditors want to see that findings were remediated. The ideal pentest report for SOC 2 includes retest results or remediation dates for each finding. A finding listed as "Critical" with no remediation status or timeline is a red flag. Include one of the following for each finding: a retest date confirming the fix, a remediation date with a brief description of the fix applied, or a risk acceptance statement with justification for findings the organization chose not to remediate.

Limitations and Caveats

Document what was excluded from scope and why. Time constraints, access limitations, out-of-scope systems, and testing restrictions all belong here. Auditors appreciate transparency. A pentest report that claims to have tested everything with no limitations is less credible than one that clearly states what was and was not covered.

Tester Qualifications

Include the name of the testing firm or individual and relevant certifications. OSCP, CREST CRT, GPEN, CEH - auditors look for recognized credentials that validate the tester's competency. If you are an independent consultant, list your certifications prominently. If you are a firm, include a brief company description and the credentials of the team members who performed the assessment.

Report Structure for SOC 2 Compliance

A pentest report structured for SOC 2 should follow this format. This is not dramatically different from a standard pentest report - the key additions are TSC mapping and remediation status.

1. Cover page - organization name, assessment period (must fall within SOC 2 audit period), testing firm name, and lead tester details.
2. Executive summary - overall risk rating, finding statistics, key risks in business language, and strategic recommendations. See our executive summary writing guide for detailed instructions.
3. Scope and methodology - systems tested (mapped to SOC 2 boundary), testing framework used, testing dates, access level provided, and exclusions.
4. Findings - each finding with title, description, CVSS score and vector, TSC mapping, evidence (screenshots, request/response pairs), remediation recommendation, and remediation status.
5. Risk summary - aggregated view of findings by severity and by TSC category.
6. Remediation roadmap - prioritized timeline for addressing findings, grouped by effort and impact.
7. Appendices - raw evidence, tool output, detailed technical data that supports the findings but does not belong in the main body.

Common SOC 2 Pentest Findings

Certain finding categories appear consistently in SOC 2 pentest reports. Understanding these helps you structure your testing and ensures your report covers the areas auditors expect to see addressed.

Insufficient Input Validation - CC6.1

SQL injection, cross-site scripting, and command injection fall under logical access controls. These vulnerabilities allow attackers to bypass authentication, access unauthorized data, or execute arbitrary commands. For SOC 2 purposes, frame these findings in terms of unauthorized data access rather than pure technical impact. "This vulnerability allows unauthenticated extraction of customer records" maps directly to a CC6.1 control failure.

Weak Authentication Controls - CC6.1

Password policy gaps, missing multi-factor authentication, session management weaknesses, and account lockout bypass. These are high-priority findings for SOC 2 because they directly relate to how the organization controls access to the system. Auditors pay close attention to authentication findings because they map directly to the criteria they are evaluating.

Insecure API Endpoints - CC6.6

Broken authorization (IDOR), missing rate limiting, excessive data exposure, and broken function-level access control. API security findings map to system boundary controls. For SaaS companies going through SOC 2, the API is often the primary attack surface, and auditors expect thorough API testing coverage.

Missing Security Headers - CC6.6

HSTS, Content Security Policy, X-Frame-Options, and X-Content-Type-Options. While these are lower severity individually, their absence indicates a gap in boundary protection controls. Auditors view missing security headers as evidence that the organization has not implemented defense-in-depth measures at the application boundary.

Outdated Dependencies - CC7.1

Known CVEs in third-party libraries and frameworks. This maps to change detection controls because the organization failed to detect that components in their system have known vulnerabilities. Document the specific CVEs, the affected components, and the available patch versions. This gives the auditor clear evidence of the gap and the remediation path.

Mistakes That Get SOC 2 Pentest Reports Rejected

Scope Mismatch

Testing the wrong systems is the fastest way to get a pentest report rejected by an auditor. If your SOC 2 boundary covers app.example.com and api.example.com, but the pentest only tested staging.example.com, the report is useless for the audit. Before starting the engagement, obtain the SOC 2 system description and verify that every in-scope system is included in the pentest scope. For PCI DSS engagements, the scope requirements are even more prescriptive - see our PCI DSS pentest report guide for details.

No Methodology Reference

A pentest report without a stated methodology looks like ad-hoc testing. Even if you performed thorough testing, the absence of a framework reference raises questions about completeness. State the framework, list the testing phases, and describe how each phase was executed for this specific engagement.

Missing Remediation Status

For Type II audits, the auditor needs to see that vulnerabilities found during the audit period were addressed. A pentest report that lists 15 findings with no remediation status creates work for the auditor and raises questions about the organization's response process. Include a status for every finding: remediated (with date and verification), in progress (with expected completion date), or accepted risk (with justification).

No TSC Mapping

A generic pentest report without Trust Service Criteria mapping forces the auditor to do the mapping themselves. This wastes their time and increases the chance of misinterpretation. Adding a TSC column to your findings table takes five minutes and significantly improves the report's utility for SOC 2 purposes.

Testing Outside the Audit Period

If the SOC 2 audit period is January 1 to December 31, 2026, and the pentest was conducted in November 2025, the report may not satisfy the auditor. The pentest should fall within the audit period. For annual pentests, schedule them in the first or second quarter of the audit period so there is time to remediate findings and demonstrate the remediation during the remaining audit period.

Vulnerability Scans Disguised as Pentests

Running Nessus or Qualys and formatting the output as a pentest report does not meet SOC 2 expectations. Auditors can distinguish between automated scan results and manual penetration testing. A pentest report should demonstrate manual testing, business logic testing, chained attack paths, and exploitation validation - none of which appear in a vulnerability scan report. If your report consists entirely of tool output with no manual testing evidence, the auditor will push back.

Automating SOC 2 Pentest Reports

Generating a SOC 2 compliant pentest report does not mean you need to manually add TSC mappings, CVSS vectors, and remediation tracking to a Word document. PentestReportAI automates the compliance-specific elements: CVSS 3.1 scoring with vector strings, structured findings with consistent formatting, and export templates designed for auditor review. You focus on the testing and the technical accuracy. The tool handles the formatting, scoring, and structure that auditors expect.

For teams running multiple SOC 2 pentests per quarter, the time savings compound quickly. Instead of spending two to three hours formatting each report for auditor consumption, you generate a compliant report in minutes and spend your time on what matters - the quality of the testing itself.

Ready to streamline your SOC 2 pentest reporting? Create a free account and generate your first two reports at no cost. See how the output compares to your current process and decide whether it fits your workflow before committing to a paid plan.