SOC 2 ControlsSOC 2Penetration TestingPen TestCC7Security AssessmentCompliance

SOC 2 Penetration Testing Requirements: What You Need and When

Everything engineering teams need to know about SOC 2 penetration testing — when it's required, what scope auditors expect, how to track findings, and how to share results with customers.

SecureSpect Team··8 min read

Is Penetration Testing Required for SOC 2?

Technically, no — the SOC 2 Trust Services Criteria do not explicitly require penetration testing. However, in practice, most enterprise customers contractually require it, most auditors expect to see it, and many SOC 2 reports include it as an additional control. For any company targeting enterprise SaaS contracts, annual penetration testing is effectively required.

The relevant SOC 2 criteria that pen testing addresses:

  • CC4.1 — The organization selects and develops control activities
  • CC7.1 — The organization uses detection and monitoring procedures to identify security events
  • CC7.2 — The organization monitors the system for anomalies and security events
A penetration test demonstrates that your controls hold up against real attack techniques, not just that they're configured correctly. This is a qualitatively different assurance than automated configuration scanning.

What Scope Do SOC 2 Auditors Expect?

At minimum, enterprise customers and auditors expect:

Annual external penetration test — Simulates an attacker with no prior knowledge of your systems targeting your externally accessible attack surface: web application, API endpoints, authentication mechanisms, and public cloud infrastructure.

Scope should include:

  • Production web application and API (all endpoints, authentication, authorization)
  • External AWS/cloud perimeter (public-facing resources)
  • Social engineering simulation (optional but positive signal)
What most auditors accept:
  • A report from a reputable pen testing firm (CREST-certified, OSCP-credentialed testers)
  • Test completed within the last 12 months
  • All critical and high findings either remediated or have documented risk acceptance
  • A letter of attestation confirming scope, methodology, and completion date
What auditors look for: Not whether zero findings were found — a penetration test that finds nothing is a sign of inadequate scope, not perfect security. They look for: was the scope meaningful? Were findings tracked? Were critical/high findings remediated?

Choosing a Penetration Testing Vendor

For SOC 2 purposes, the key criteria:

Certification: Look for firms with CREST accreditation or testers with OSCP, GPEN, or equivalent certifications. These signal methodological rigor that auditors recognize.

Scope experience: The firm should have explicit experience testing cloud-native SaaS applications on AWS, Azure, or GCP — not just traditional on-premise or network penetration testing.

Deliverable quality: You need a written report that includes: executive summary, technical findings with CVSS scores, proof of concept details (not just descriptions), and remediation recommendations. This report is what you share with customers and what your auditor reviews.

Retesting included: After you remediate critical and high findings, you need a retest to confirm the remediation is effective. This should be included in the engagement.

Managing and Documenting Findings

The penetration test report alone is not complete SOC 2 evidence. You also need evidence that findings were managed:

  • Create a tracking ticket for every finding immediately after receiving the report — P1/Critical and P2/High tickets with owners and deadlines
  • Remediate critical and high findings within defined SLAs — typical expectation is critical within 15 days, high within 30 days
  • Document accepted risks — if any finding is risk-accepted rather than remediated, get sign-off from a C-suite executive with a written rationale
  • Retest remediated findings — get written confirmation from the testing firm that the remediation was effective
  • Retain the report, tracking tickets, and retest results — this complete package is your SOC 2 evidence for the observation period
  • Sharing Pen Test Results with Customers

    Enterprise customers increasingly request pen test reports as part of their vendor security reviews. Common sharing approaches:

    Full report under NDA: Share the full technical report after the customer signs a mutual NDA. This is the most thorough option but requires NDA processing time.

    Executive summary only: Share the executive summary (scope, methodology, finding counts by severity, remediation status) without detailed technical findings. This satisfies most initial security review requirements without exposing detailed attack paths.

    Trust center summary: Display the test date, scope, testing firm name, and a summary of finding disposition on your public trust center. This answers the most common initial question without requiring any document exchange.

    SecureSpect Pen Test Management

    SecureSpect's Pen Tests module provides a structured workspace for uploading pen test reports, tracking findings from the report through remediation, and documenting risk acceptance decisions. When a customer asks for pen test evidence, you can export a clean finding-and-remediation status report directly from SecureSpect — no spreadsheet assembly required.

    Automate your SOC 2 evidence collection

    Connect your AWS and GitHub environments and start collecting audit-ready evidence today. Free to start.

    Start Free →More Articles