SOC 2 Penetration Testing: What Auditors Expect

The short answer: SOC 2 does not mandate penetration testing by name, but the AICPA Trust Services Criteria (2017) — specifically CC6 and CC7 — require controls that auditors increasingly satisfy through documented pentest evidence. Without it, your auditor will likely flag gaps, and sophisticated buyers reviewing your report will notice their absence.

This guide explains exactly which criteria map to pentesting, what Type I versus Type II auditors need to see, when to run tests relative to your audit window, and how to build the evidence package that closes the loop.

Why Penetration Testing and SOC 2 Are Inseparable

SOC 2 is an attestation, not a certification. Your auditor evaluates whether your controls are suitably designed (Type I) and operating effectively over time (Type II). The controls that matter most for security-oriented SaaS companies live in the Security Trust Service Category, and two control families make pentest evidence nearly indispensable.

Trust Service Criteria Mapping

The table below maps the AICPA Trust Services Criteria (2017 edition) to the specific ways penetration testing provides evidence of control design and effectiveness.

Trust Service Criteria	Description	How Pentesting Addresses It
CC6.1	Logical access controls restrict unauthorized access	Pentest validates that authentication, authorization, and access segmentation hold under adversarial conditions
CC6.6	Logical access restrictions over infrastructure and software	External/internal pentest verifies that network segmentation, firewall rules, and API boundaries resist exploitation
CC6.7	Transmission and storage protections	Pentest checks for weak TLS configurations, certificate pinning gaps, and insecure data-at-rest exposures
CC7.1	Detection and monitoring of threats and vulnerabilities	Pentest validates that SIEM and IDS/IPS alert on attack patterns; findings prove detective controls are tested
CC7.2	Evaluation of security events	Pentest reports document how identified vulnerabilities were triaged, escalated, and resolved
CC7.3	Response to identified security incidents	Pentest retesting evidence shows the organization can identify a control failure and remediate it within a defined SLA
CC7.4	Recovery from security incidents	Scope can include disaster-recovery path testing to validate backup integrity and failover under simulated breach
CC9.2	Risk management with vendors and business partners	Third-party pentest of vendor-facing APIs and integration points validates supply-chain risk controls

Auditors use CC6 and CC7 as the primary anchors, but well-scoped pentests generate evidence that spills across multiple criteria — strengthening your overall control environment narrative.

SOC 2 Type I vs. Type II: Different Evidence Requirements

Type I — Point-in-Time Design

A Type I report asks: Are your controls suitably designed as of a specific date?

For pentesting, this means:

A completed pentest report dated before or on the Type I report date
Documentation that a pentest methodology was selected and scoped appropriately
Evidence that findings were triaged (even if remediation is in progress)
A written management response to each finding

Type I auditors generally accept a recent pentest (within 12 months of the report date) combined with a remediation plan. They are evaluating design, not sustained execution.

Type II — Operating Effectiveness Over Time

A Type II report covers an observation period — typically 6 or 12 months. Auditors must see that controls operated continuously and effectively throughout that window.

For pentesting, this means:

At minimum one pentest completed within the observation period (not before it starts)
Remediation evidence with timestamps showing vulnerabilities were closed within your stated SLA
Retest evidence confirming that patched vulnerabilities no longer exist
If you claim continuous testing controls, evidence of cadence (quarterly, monthly)

Critical timing rule: Schedule your pentest so that it begins and concludes inside the Type II observation window, not in the months before it opens. Auditors will ask for the test date. A pentest completed six weeks before the observation period began does not satisfy a Type II control for that period.

What Auditors Actually Look For

Experienced SOC 2 auditors know the difference between a scanner output and a real penetration test. Here is what they evaluate when reviewing your pentest evidence:

Methodology documentation The report must describe the testing methodology (e.g., PTES, OWASP Testing Guide, NIST SP 800-115). Auditors need to understand whether the test included manual exploitation or was purely automated.

Scope definition Scope must align with your SOC 2 system description. If your system description covers your production API, customer portal, and underlying cloud infrastructure, the pentest scope must cover the same. Scope gaps are audit findings.

CVSS-scored findings Every vulnerability should carry a CVSS score (v3.1 or v4.0) so auditors can confirm that critical and high findings received priority remediation. Findings without severity scores signal an immature process.

Remediation evidence A pentest report alone is not enough. You must show that findings were tracked to closure — ticket references, patch deployment logs, configuration change records, or equivalent artifacts.

Retest results The original tester (or an independent tester) must confirm that remediated vulnerabilities are closed. A retest report or a formal attestation letter from the security firm serves this purpose.

Tester qualifications Auditors increasingly ask about tester credentials (OSCP, GPEN, CEH, CREST) and organizational independence. An internal team running automated scans does not satisfy the independence expectation most auditors apply for Type II evidence. The guide on how to verify pentester certifications provides the step-by-step lookup process for each major credential body.

Annual vs. Continuous Testing for SOC 2 Maintenance

A single annual pentest is the floor, not the ceiling. For growing SaaS companies under continuous SOC 2 surveillance, the risk profile changes faster than once a year — new features ship, infrastructure changes, third-party integrations are added.

Annual testing satisfies basic Type II requirements and works for stable, low-change environments.

Continuous or quarterly testing — Penetration Testing as a Service (PTaaS) models — provides rolling evidence that maps cleanly to any 12-month Type II window without timing gaps. It also catches regressions immediately after code releases. For organizations subject to multiple frameworks, the PCI DSS penetration testing requirements article details how the testing evidence overlaps and where the two standards diverge.

When your customer base includes enterprises or financial institutions, continuous testing evidence is increasingly a differentiator in vendor due-diligence questionnaires, not just a SOC 2 checkbox.

Common Mistakes That Fail SOC 2 Audits

No pentest at all Auditors note the absence. Sophisticated buyers reading your SOC 2 report will notice the gap in CC6/CC7 controls. This is the most common and most costly mistake.

Scanner-only results Vulnerability scans (Nessus, Qualys, Tenable) produce asset inventories and known-CVE lists. They do not demonstrate exploitability or validate that access controls hold under adversarial conditions. Auditors distinguish between scans and tests.

No remediation evidence A pentest report with open critical findings and no remediation trail is worse than no pentest — it documents known, unaddressed vulnerabilities. Every finding needs a closed ticket or a documented risk-acceptance decision signed by management.

Wrong timing A pentest completed before the Type II observation period does not count. Run it inside the window. If your observation period is January through December, a pentest completed in October of the prior year is out of scope.

Scope misalignment Testing a staging environment when your SOC 2 system description covers production is a scope gap auditors will flag. Always align pentest scope to your system description before the test begins.

No retest Patching without verification is not remediation. Auditors expect evidence that fixes were validated, not just deployed.

Real-World Use Case: SOC 2 Type II Evidence Done Right

Consider a SaaS company targeting enterprise customers with a Type II observation period running January through December. Their security team schedules the annual pentest in October — well inside the observation window. Testing takes three weeks; the final report is delivered November 1st documenting nine findings across CC6 and CC7 controls, each with a CVSS v3.1 score.

Remediation begins immediately. By November 30th, all nine findings are closed. The testing firm issues a retest attestation letter dated December 5th, signed by the lead tester, confirming that each finding was retested and verified closed in the production environment.

When audit fieldwork opens in January, the evidence package submitted to the CPA firm includes: the signed scope document aligned to the SOC 2 system description, a methodology statement describing PTES-based manual testing with OWASP Top 10 coverage, the full pentest report with CVSS scores and proof-of-concept artifacts, a Jira export showing all nine findings closed with engineer names and timestamps, the retest attestation letter, and the lead tester's OSCP certification record verified on Credly.

The auditor accepts the package without additional information requests. Three elements made it work: testing was completed inside the observation window (not in September of the prior year), retest evidence was a written attestation from the testing firm rather than just closed Jira tickets, and the tester's qualifications were independently verifiable by credential number.

Evidence Package Checklist

Hand your auditor a clean evidence package. The following documents satisfy the typical SOC 2 Type II requirement:

Pentest scope document — written scope agreement signed before testing began, aligned to your SOC 2 system description
Methodology statement — the framework used (PTES, OWASP, NIST SP 800-115, or custom) and whether manual exploitation was performed
Full pentest report — executive summary, findings list with CVSS scores, technical details, and proof-of-concept artifacts
Tester qualifications — credentials of the lead tester and the firm's attestation of independence
Remediation tracker — ticket or project-management export showing each finding, assignee, due date, and closure date
Patch/configuration evidence — screenshots, deployment logs, or change-management records for each remediated finding
Retest report or attestation letter — signed confirmation that remediated findings no longer reproduce
Risk-acceptance documentation — for any finding marked accepted rather than remediated, a signed management decision with rationale and compensating controls
Testing dates — explicit start and end dates for both the original test and the retest, confirming they fall within the observation period

Building a SOC 2-Ready Pentest Program

A SOC 2-ready pentest provider should deliver structured reports with CVSS scoring, integrated remediation tracking, and retest attestation letters formatted to satisfy Big Four and regional CPA firm auditors. Engagements should be scoped against your SOC 2 system description from day one, so the evidence package is audit-ready without additional reformatting.

For organizations on continuous monitoring programs, quarterly PTaaS engagements generate rolling evidence across any 12-month Type II observation window — eliminating the timing risk that catches teams off guard during audit fieldwork. Providers like WhiteJaguars offer this model with deliverables specifically structured for auditor review.

Key Takeaways

SOC 2 does not explicitly name pentesting, but CC6 and CC7 controls are most convincingly satisfied with real penetration test evidence
Type I auditors need a recent report with a remediation plan; Type II auditors need testing, remediation, and retesting evidence inside the observation period
Scanner outputs do not substitute for manual penetration testing in an auditor's eyes
Your evidence package must include scope, methodology, CVSS-scored findings, remediation records, and retest results
Timing is the most overlooked risk — schedule your pentest to complete well before your audit fieldwork begins, but inside the observation window

Frequently Asked Questions

Does SOC 2 explicitly require a penetration test?

No. The AICPA Trust Services Criteria (2017) do not contain the words "penetration test." What they do require — under CC6.1, CC6.6, CC7.1, CC7.2, and CC7.3 — are controls that demonstrate logical access restrictions are functioning, threats are being detected, and identified vulnerabilities are being remediated. Auditors satisfy these criteria by reviewing evidence of control operation. In practice, penetration test documentation — report, remediation records, retest attestation — is the most efficient and credible form of evidence for those controls. Companies that attempt to satisfy CC7 controls with scanner output alone routinely receive audit findings noting insufficient evidence of adversarial testing.

How do I time my pentest to satisfy a SOC 2 Type II observation period?

The test must begin and conclude within the observation period, not before it opens. If your Type II period runs January 1 through December 31, a pentest completed in November of the prior year does not count — even if it was completed only weeks before January 1. Schedule testing to complete with enough time remaining in the period to remediate findings and conduct a retest. A practical rule: complete initial testing no later than October if your observation period closes December 31. That leaves eight weeks for remediation, retest, and attestation letter issuance before the period closes.

Can an internal security team run the pentest for SOC 2?

An internal team can conduct the assessment, but auditors will scrutinize the independence and qualifications of the testers carefully. For Type II evidence, most Big Four and regional CPA firm auditors apply a practical independence test: was the team that built or operated the controls also the team that tested them? If yes, that is a conflict of interest that weakens the evidence value. A third-party assessment by a firm with no operational role in your environment provides cleaner independence. If you do use an internal team, document their qualifications, their separation from the teams responsible for the tested controls, and their methodology in detail — auditors will read it.

What CVSS score threshold should I remediate before the audit?

There is no CVSS threshold specified in the Trust Services Criteria. However, the practical auditor expectation is that all critical (CVSS 9.0–10.0) and high (CVSS 7.0–8.9) findings are remediated within the organization's stated SLA, which your policies should define. Medium findings (CVSS 4.0–6.9) should either be remediated or accompanied by documented risk-acceptance decisions signed by management. Leaving any critical or high finding open without a signed risk-acceptance record is a reliable audit finding under CC7.2 and CC7.3. For findings that cannot be immediately remediated — complex architectural changes, third-party dependencies — document compensating controls and a remediation timeline, and ensure management has formally accepted the residual risk.

How does SOC 2 pentesting differ from PCI DSS pentesting?

Both frameworks require penetration testing evidence, but the specifics diverge in three meaningful ways. PCI DSS v4.0 (Requirement 11.4) mandates penetration testing explicitly by name and prescribes minimum scope: external and internal network testing, application-layer testing, and segmentation verification if a cardholder data environment is network-segmented to reduce scope. SOC 2 implies pentesting through control criteria but leaves methodology and frequency to the organization's judgment. Second, PCI DSS specifies annual testing as a minimum frequency; SOC 2 does not set a minimum cadence, though Type II auditors expect testing within the observation period. Third, PCI DSS segmentation testing is a distinct, required workstream — if you use network segmentation to isolate your cardholder data environment, you must test that the segmentation actually holds. SOC 2 has no equivalent requirement. Organizations subject to both frameworks can design a single engagement that satisfies both, provided the scope covers the elements each framework requires.

SOC 2 and Penetration Testing: What Auditors Expect