SOC 2 Penetration Testing Requirements: Scope and Evidence

A SOC 2 penetration test is an authorized, adversarial assessment of systems, applications, and infrastructure within the SOC 2 system boundary. It gives management evidence about selected attack paths for the auditor to evaluate alongside the system description, control design, and operating evidence. The AICPA’s Trust Services Criteria define the control categories a SOC 2 examination addresses; the test scope should follow the service and controls under examination.

A penetration test is not a substitute for the rest of the control environment. Its value depends on whether the scope matches the service being examined, findings receive documented treatment, and the evidence remains relevant to the audit period. NIST SP 800-115 describes penetration testing as security testing that mimics real-world attacks to identify ways around application, system, or network security features.

When Does Penetration Testing Support a SOC 2 Audit?

Penetration testing supports a SOC 2 audit when it tests the systems and attack paths that matter to the service under examination, and when management can trace material findings through remediation and retesting. It is one possible source of evidence for monitoring and vulnerability-management controls; it is not a universal replacement for risk assessment, scanning, change management, or access reviews.

For example, a test can evaluate whether an authenticated user can cross an authorization boundary or whether a cloud-identity configuration creates a path to production data. The report becomes useful audit evidence only when its scope, limitations, findings, remediation records, and retest results are available for review.

How Does Testing Relate to the Trust Services Criteria?

A penetration test may support management’s evidence for risk assessment, monitoring, system operations, or remediation controls. The relationship depends on the controls in the system description and what the test actually covered; a finding does not by itself prove compliance or determine the auditor’s opinion.

Map each retained artifact to the control it is meant to support. The test plan establishes authorization and scope, the report records procedures and findings, remediation tickets show management’s response, and a retest can show whether a specific fix addressed the reported condition. The CPA firm decides how much that evidence contributes to its examination.

How Should You Scope a SOC 2 Penetration Test?

Scope the test from the SOC 2 system boundary, the service’s material attack paths, and the control objectives the assessment is intended to inform. The two boundaries do not have to be identical: document included and excluded systems so management and the CPA firm can judge whether the test is relevant.

Which Systems Belong in the Test Scope?

Include the systems and interfaces needed to answer the assessment objective. For a SaaS service, candidates may include the customer-facing application, externally exposed APIs, authentication flows, administrative interfaces, cloud configurations, and paths that can reach production data. Record why each candidate is included or excluded.

Third-party services require a boundary decision rather than automatic inclusion. Test connection points you are authorized to assess, identify provider-managed components, and retain the dependency and exclusion notes. NIST SP 800-115 recommends planning technical security testing around objectives, scope, authorization, logistics, and rules of engagement.

Keep the evidence chain in this order: scope → active testing → remediation records → retest result → auditor review.

How Should You Set the Testing Frequency?

SOC 2 does not prescribe a universal testing frequency. Define the cadence in policy from the systems in scope, material changes, threat exposure, and the evidence needed during the audit period. NIST SP 800-53 Rev. 5, control CA-8 similarly calls for penetration testing at an organization-defined frequency on organization-defined systems or components.

The frequency decision should be documented with the same precision as the scope decision. A fast-changing SaaS product may need a targeted assessment after a material architecture, identity, or data-flow change; a stable service may use recurring vulnerability and configuration validation between deeper assessments. The policy should identify the trigger, decision-maker, affected systems, and evidence to retain.

Schedule the principal assessment early enough for management to evaluate material findings, deploy fixes, and obtain retest evidence before fieldwork. The right lead time depends on the agreed scope, testing window, remediation work, and the audit timetable; do not use a generic month-in-period rule as proof of readiness.

A report from before a material architecture change may not address the current attack surface. Document whether that change requires supplemental testing or other validation, and retain evidence that relates to the system as it operated during the audit period.

How to Set a SOC 2 Penetration-Testing Cadence

Use the risk and change events below to write a cadence decision that an auditor can review; they are not universal testing intervals.

A documented, risk-based cadence gives the auditor a clearer basis for assessing whether management evaluated the relevant attack surface during the period. Keep the policy, testing plan, report, remediation records, and retest evidence together so the evidence chain can be reviewed without reconstructing it from email or verbal explanations.

How Do Penetration Tests Differ From Vulnerability Scans?

Penetration tests and vulnerability scans answer different questions. A scan identifies potential known weaknesses across a defined target set; a penetration test uses authorized attack techniques to determine whether selected weaknesses or attack paths can be exploited. The documented risk assessment and control design determine whether a program needs either or both.

A vulnerability scan is generally automated and repeatable. A penetration test combines tools with analyst judgment under agreed rules of engagement. Neither label guarantees scope, depth, or evidence quality, so review the procedures and limitations in the delivered report.

Penetration Testing vs Vulnerability Scanning for SOC 2

Compare the evidence each activity can produce before treating one report as a substitute for the other.

What Should a Penetration-Test Report Contain?

A useful report lets management and the CPA firm understand what was tested, what was not tested, what the assessor did, what it found, and what happened next. No single template or scoring version is universally required for SOC 2.

Retain these report elements:

1. Authorization, dates, and scope: Identify the legal parties, test window, targets, exclusions, and rules of engagement.
2. Methodology and limitations: Name the testing approach, access level, constraints, and assumptions.
3. Findings and evidence: Record affected assets, reproduction information, impact, and the basis for severity.
4. Management response: Link each accepted finding to an owner, decision, and remediation record.
5. Retest status: State which findings were retested, when, by whom, and with what result.

Risk scores can help prioritize findings, but the scoring system and version should be named rather than assumed. Pair the score with service-specific impact and the affected system. For related evidence-organization practices, see SOC 2 documentation.

How Should You Document Remediation and Retesting?

Document the disposition of each validated finding, including accepted risk, remediation, compensating controls, or another approved response. The evidence should connect the original finding to an owner, decision, implementation record, and current status.

Use this sequence:

1. Validate the finding and assign an owner.
2. Record severity and service-specific impact.
3. Document the response decision and due date.
4. Link implementation evidence, such as a change record or configuration update.
5. Decide whether independent retesting or another validation method is appropriate.
6. Retain the result and any remaining limitation.

Retesting terms vary by provider and contract. Confirm the included window, eligible findings, deliverable, and additional fees before signing. A closed ticket records workflow status; the underlying evidence shows what changed and how the result was validated.

How Does the Testing Record Support the SOC 2 Audit?

The testing record gives the CPA firm one evidence source for evaluating the controls described by management. Its usefulness depends on authorization, scope, timing, procedures, findings, management’s response, and any validation of remediation; it does not guarantee a clean opinion.

---

If you need to source the testing itself, compare SOC 2-scoped options on the SOC 2 penetration testing firms page. If you already have the report and need a CPA firm to evaluate it in the wider examination, use the SOC 2 auditor directory.