SOC 2 Penetration Testing: Why Auditors Expect It and How to Get It Right

The SOC 2 Penetration Testing Paradox

Search the AICPA's Trust Services Criteria documentation for the phrase "penetration testing" and you will not find it. SOC 2 does not explicitly require penetration testing. There is no control that says "the organization shall perform annual penetration tests." This leads some organizations to conclude that they can skip penetration testing entirely and still pass their SOC 2 audit.

They are technically correct. They are also almost certainly going to have a difficult conversation with their auditor.

In practice, penetration testing has become a de facto expectation in SOC 2 Type II audits. Auditors view it as the most credible form of evidence for several Trust Service Criteria controls, particularly those related to security monitoring, vulnerability management, and incident response. An organization that presents a SOC 2 audit package without penetration testing evidence is not failing a specific requirement -- it is leaving gaps in its evidence that the auditor will question.

This article explains exactly how penetration testing maps to the Trust Services Criteria, what auditors look for in penetration testing evidence, and how to scope a penetration test that strengthens your SOC 2 narrative rather than just checking a box.

How Penetration Testing Maps to Trust Service Criteria

SOC 2 is built on Trust Service Criteria (TSC), with the Security criterion (formerly the "Common Criteria") being mandatory for every SOC 2 engagement. The Security criterion is implemented through nine control families: CC1 through CC9.

Penetration testing provides evidence for several of these control families. Understanding the mapping helps you position penetration testing as a deliberate control activity rather than an afterthought.

CC4 -- Monitoring Activities

CC4.1 requires that the organization selects, develops, and performs ongoing and/or separate evaluations to ascertain whether the components of internal control are present and functioning.

Penetration testing is a "separate evaluation" under this definition. It is an independent assessment of whether your security controls actually work -- not just whether they exist on paper, but whether they withstand an adversary's attempt to bypass them.

An auditor evaluating CC4.1 wants to see that the organization does more than monitor its own dashboards. Penetration testing provides third-party validation that internal monitoring would detect a real attack. If your SOC 2 narrative claims that your security monitoring is effective, a penetration test either confirms that claim or exposes the gaps.

CC7.1 -- Monitoring Infrastructure and Software

CC7.1 states that the organization uses detection and monitoring procedures to identify changes to configurations that result in the introduction of new vulnerabilities, and susceptibilities to newly discovered vulnerabilities.

Penetration testing directly supports CC7.1 by identifying vulnerabilities that automated monitoring may miss. Configuration drift, business logic flaws, authentication bypass paths, and privilege escalation chains are all examples of vulnerabilities that scanning tools detect poorly but penetration testers identify routinely.

For a comprehensive look at how continuous scanning supports CC7.1 on an ongoing basis between penetration tests, see our SOC 2 audit readiness monitoring guide.

CC7.2 -- Monitoring for Anomalies

CC7.2 requires that the entity monitors system components and the operation of those components for anomalies that are indicative of malicious acts, natural disasters, and errors affecting the entity's ability to meet its objectives.

A penetration test generates real-world anomalies -- port scans, authentication attempts, exploitation attempts, lateral movement -- that your monitoring should detect. If your SIEM, IDS, or logging infrastructure fails to flag the penetration tester's activity, that is a meaningful finding about your monitoring capability.

Some organizations explicitly coordinate with their penetration tester to run the test without notifying the SOC (Security Operations Center) team. This "blind" approach tests CC7.2 directly: did the monitoring detect the simulated attack?

CC7.3 -- Evaluating Security Events

CC7.3 requires evaluation of identified events to determine whether they could affect the entity's ability to achieve its objectives. Penetration testing findings are security events that require evaluation, prioritization, and remediation decisions. The process of triaging penetration test findings -- assessing business impact, determining remediation priority, assigning ownership -- is itself evidence of CC7.3 functioning.

CC7.4 -- Responding to Security Incidents

CC7.4 covers the organization's incident response process. While a penetration test is not a real incident, the remediation workflow it triggers mirrors incident response: identify the vulnerability, assess impact, implement a fix, verify the fix, and document the entire process. Auditors view this as a rehearsal of the incident response capability documented in your SOC 2 controls.

CC3.2 -- Risk Identification and Assessment

CC3.2 requires that the organization identifies risks to the achievement of its objectives across the entity and analyzes risks as a basis for determining how the risks should be managed. Penetration testing is a risk identification mechanism that goes beyond theoretical risk analysis. It identifies real, exploitable weaknesses in your environment rather than hypothetical risk scenarios from a spreadsheet.

CC5.2 -- Selection and Development of Control Activities

CC5.2 addresses the selection of control activities that contribute to risk mitigation. Penetration testing validates whether the controls you have selected are actually effective. A WAF rule that should block SQL injection but is trivially bypassed is a control that exists but does not function -- and CC5.2 asks whether controls function, not just whether they exist.

What Auditors Look for in Penetration Testing Evidence

Understanding what auditors evaluate helps you produce evidence that strengthens rather than weakens your SOC 2 narrative.

Scope Alignment

The penetration test scope should align with your SOC 2 system description. If your SOC 2 boundary includes your production SaaS application, its API, and its supporting infrastructure, the penetration test should cover all three. A penetration test that only covers the web application while your SOC 2 scope includes the API and infrastructure creates an evidence gap.

Methodology Documentation

Auditors expect to see a documented methodology -- not just results. The report should describe what the tester did, how they did it, what tools and techniques they employed, and what areas they covered. A bare list of vulnerabilities without methodology documentation looks like an automated scan, not a penetration test.

Findings with Business Impact

Audit-quality penetration test reports contextualize findings in terms of business impact, not just technical severity. "SQL injection vulnerability in login form" is a technical finding. "SQL injection vulnerability in login form allows unauthenticated extraction of the customer database, including names, email addresses, and subscription tier -- affecting approximately 15,000 records" is a finding that maps to the entity's ability to meet its commitments and system requirements.

Understanding what to expect from a penetration test report helps you evaluate whether your testing provider delivers the depth of reporting that SOC 2 auditors require.

Remediation Evidence

The complete evidence package includes not just the penetration test report but also documentation of remediation actions and verification:

Finding:       Cross-site scripting in search functionality
Severity:      High
Date Found:    2026-01-15
Remediation:   Input validation + output encoding implemented (PR #842)
Date Fixed:    2026-01-22
Retest Date:   2026-01-24
Retest Result: Verified remediated — XSS no longer reproducible

This remediation loop demonstrates CC7.3 (event evaluation) and CC7.4 (response) in action. Findings without corresponding remediation records are worse than no findings at all -- they demonstrate that the organization identified risks and failed to address them.

Testing Frequency

SOC 2 does not specify a penetration testing frequency, but auditors generally expect at least annual testing. For Type II audits covering a twelve-month period, a penetration test performed within that window provides evidence of control effectiveness during the audit period. A test from eighteen months ago does not.

Many organizations adopt an annual cadence with additional testing triggered by significant changes: major releases, infrastructure migrations, or new integrations. This approach mirrors the PCI DSS model and demonstrates a mature security testing program.

Scoping Penetration Testing for SOC 2

SOC 2 scoping differs from PCI DSS scoping in a fundamental way. PCI DSS defines scope around cardholder data flows. SOC 2 defines scope around the "system" described in your SOC 2 report, which is whatever you and your auditor agree it is.

This flexibility is both an advantage and a risk. You can define your SOC 2 boundary to include only the systems relevant to your customers' trust, but your penetration test must then cover that entire boundary.

Define the System Boundary

Start with your SOC 2 system description. What infrastructure, applications, and data stores are included? What is explicitly excluded? The penetration test scope should match or exceed this boundary.

Prioritize Customer-Facing Systems

Within the SOC 2 boundary, prioritize testing of customer-facing systems -- the application, APIs, and integrations that your customers interact with. These are the systems your SOC 2 report makes commitments about, and they carry the highest reputational risk if compromised.

Include Authentication and Authorization

SOC 2 auditors pay close attention to logical access controls (CC6.1, CC6.2, CC6.3). Your penetration test should specifically target authentication mechanisms, session management, role-based access controls, and authorization boundaries. Can a standard user escalate to admin? Can one customer access another customer's data? These are the questions your auditor will ask, and your penetration test should answer them.

Test the Infrastructure

If your SOC 2 scope includes cloud infrastructure (AWS, Azure, GCP), the penetration test should include infrastructure testing: misconfigured IAM policies, overly permissive security groups, exposed storage buckets, and privilege escalation paths within the cloud environment.

Consider API Testing

Modern SaaS applications often expose more functionality through APIs than through their web interfaces. If your application has an API, it should be in the penetration test scope. API-specific testing covers authentication token handling, rate limiting, input validation, and authorization checks at the endpoint level.

Integrating Penetration Testing into Your SOC 2 Narrative

The most effective SOC 2 programs weave penetration testing into a broader narrative about security maturity rather than presenting it as an isolated compliance artifact.

The Narrative Arc

Your SOC 2 narrative should tell a story:

1. We identify risks through continuous monitoring, vulnerability scanning, and periodic penetration testing (CC3.2, CC4.1)
2. We detect threats through infrastructure monitoring, log analysis, and anomaly detection -- validated by penetration testing (CC7.1, CC7.2)
3. We evaluate findings through a defined triage process that assesses business impact and assigns remediation priority (CC7.3)
4. We respond and remediate through a documented process that includes verification and regression testing (CC7.4)
5. We validate controls by confirming that remediated vulnerabilities do not reappear and that new controls are effective (CC5.2)

Penetration testing touches every step of this narrative. It is not a standalone activity -- it is the thread that connects risk identification to control validation.

Timing Your Penetration Test

Schedule your penetration test so that it falls within the SOC 2 audit period and allows sufficient time for remediation and retesting before the audit window closes. If your audit period is January through December, scheduling a penetration test in October with remediation in November and retesting in December creates a complete evidence package that auditors can evaluate end to end.

Avoid scheduling the penetration test in the last month of the audit period. If critical findings emerge, you need time to remediate them. Unresolved critical findings at the end of an audit period will result in a qualified opinion or an exception in the SOC 2 report.

Continuous Scanning as a Complement

Penetration testing provides deep, point-in-time analysis. Continuous security monitoring provides ongoing evidence between tests. Together, they build the evidence trail that SOC 2 Type II audits require: consistent, documented control effectiveness over the entire audit period.

The Difference Between Passing and Excelling

Organizations that view penetration testing as a compliance checkbox produce a report, file it, and move on. Organizations that use penetration testing as a security improvement tool integrate findings into their development lifecycle, track remediation metrics over time, and demonstrate year-over-year improvement in their security posture.

Auditors notice the difference. A SOC 2 package that shows declining findings, faster remediation times, and proactive retesting tells a story of a maturing security program. A package that shows the same findings year after year tells a different story.

If you are evaluating whether your organization needs a penetration test, SOC 2 readiness is one of the strongest drivers -- not because the standard requires it, but because auditors expect it and your customers rely on it.

Next Steps

Our Penetration Testing Scoping Wizard helps you define the right scope for a SOC 2-aligned penetration test. It maps your system boundary, identifies testing priorities, and produces a scope document that aligns with Trust Service Criteria requirements.

If your SOC 2 audit is approaching and your penetration testing evidence has gaps, our services team can help you design a testing program that strengthens your audit narrative and satisfies auditor expectations.