SOC 2 Penetration Testing: What Auditors Actually Require

TL;DR

• A System and Organization Controls 2 (SOC 2) penetration test is an independent attack simulation, scoped to the systems in your SOC 2 system description, whose results serve as evidence under the American Institute of Certified Public Accountants (AICPA) Trust Services Criteria that your security controls operate effectively. 
• SOC 2 criteria require evidence that security controls are evaluated under Common Criteria 4.1 (CC4.1), but no criterion explicitly mandates a penetration test.
• A SOC 2 penetration test is an independent, scoped attack simulation against the systems named in your SOC 2 system description, used as evidence under the AICPA Trust Services Criteria that security controls operate effectively.
• Auditors and enterprise customers expect a scoped penetration test as the standard proof that technical controls effectively resist attack.
• Scoping must align directly with the official SOC 2 system description, covering web applications, application programming interfaces (APIs), cloud infrastructure, and authenticated user roles.
• Audit evidence requires a complete chain for every finding, including the report entry, remediation ticket, code fix, retest verification, and closure date inside the review window.
• Point-in-time annual tests can leave coverage gaps across multi-month Type II review windows as code and infrastructure continuously evolve.
• Continuous testing provides timestamped evidence of ongoing evaluation under CC4.1 and vulnerability detection under CC7.1 throughout the entire audit period.
• Remediation must address the underlying root cause in source code rather than applying isolated point fixes to specific reported endpoints.

Does SOC 2 Require Penetration Testing?

No, System and Organization Controls 2 (SOC 2) does not mandate a penetration test. The American Institute of Certified Public Accountants (AICPA) Trust Services Criteria do not explicitly require one in any criterion. Under Common Criteria 4.1 (CC4.1), penetration testing appears only as an example within a point of focus, which serves to illustrate how a criterion might be met rather than setting a mandatory requirement. The CC4.1 point of focus ‘Considers Different Types of Ongoing and Separate Evaluations’ lists evaluations including ‘penetration testing, independent certification made against established specifications’ (AICPA, 2017 Trust Services Criteria with Revised Points of Focus 2022).

The practical reality for most organizations, however, differs from the strict text of the framework:

• Auditor Expectations: Under CC4.1, auditors require concrete evidence that management performs ongoing or periodic evaluations to ascertain whether internal controls are present and functioning. A professional penetration test is the most widely accepted method to satisfy this testing requirement for technical controls.
• Customer Vendor Assessments: Enterprise buyers routinely request a recent penetration testing report alongside a SOC 2 Type II report during vendor security reviews. Even if an auditor accepts alternative evaluations, your sales pipeline often makes a penetration test functionally non-negotiable.

Ultimately, while the AICPA framework leaves room for alternative control evaluation methods, relying on internal scans or manual reviews alone rarely satisfies sophisticated auditors or enterprise procurement teams.

Why Do Auditors and Customers Still Ask for a Pentest?

Organizations pursuing SOC 2 compliance quickly discover that the demand for penetration testing is driven by two distinct, reinforcing external pressures: auditor evaluation standards and enterprise customer procurement checks.

Auditors must exercise professional judgment under AICPA standards to confirm that your internal security controls are actively evaluated and functioning as intended. Because automated scans and self-assessments often fail to demonstrate how controls withstand chained, multi-step exploitation of the kind agentic pentesting automates,  independent penetration testing remains the benchmark evidence auditors rely on to validate control effectiveness.

Simultaneously, prospective enterprise customers treat a penetration test as an essential risk control. Mike DeKock, CPA of MJD Advisors, wrote in a February 2024 post republished on the Cloud Security Alliance (CSA) blog that penetration testing is “the most common requirement we hear as the last component to close a deal with an enterprise customer.”

This dynamic often creates an operational disconnect: a penetration test scoped quickly to satisfy a buyer’s immediate request may fail to cover the broader system boundaries, infrastructure components, or control sets that your SOC 2 auditor is actively examining.

SOC 2 Type I, Type II, and the Trust Services Criteria

Understanding what auditors look for requires understanding the structure of the AICPA System and Organization Controls (SOC) suite. A SOC 2 report is a formal attestation report issued by an independent Certified Public Accountant (CPA), not a static pass-or-fail certification.

The evaluation is built upon the AICPA Trust Services Criteria, which encompass five distinct trust categories:

1. Security (Common Criteria): The foundational control set (CC1 through CC9) required in every single SOC 2 report, addressing protection against unauthorized access and system damage.
2. Availability: Evaluates whether operational systems and services remain accessible as stipulated by service level agreements.
3. Processing Integrity: Assesses whether system processing remains complete, valid, accurate, timely, and authorized.
4. Confidentiality: Focuses on protecting data designated as confidential from unauthorized disclosure.
5. Privacy: Examines how personal information is collected, used, retained, disclosed, and disposed of in alignment with organizational commitments.

Type I vs. Type II Evidence Requirements

The distinction between report types determines how an auditor reviews your security testing records:

Report Type	Evaluation Focus	Testing Evidence Requirement
Type I	Design Suitability: Verifies that controls are properly designed to meet relevant criteria at a specific point in time	Demonstrates that security testing procedures are formally defined and were executed during the designated assessment date
Type II	Operating Effectiveness: Verifies that controls operated effectively across a designated review window (typically 6 to 12 months)	Requires evidence of ongoing or periodic testing throughout the review period, alongside complete remediation logs for identified flaws

Because a Type II audit evaluates operational consistency over time, a single annual point-in-time penetration test conducted at the end of the audit window can leave coverage gaps earlier in the review period if major infrastructure or code changes occurred during that time.

What Do SOC 2 Auditors Actually Look For?

When a SOC 2 auditor reviews your penetration testing documentation, they are not simply checking whether a PDF exists in your compliance folder. Instead, they examine the report to confirm that specific technical controls under the Common Criteria were actively evaluated and that identified risks were systematically resolved.

A penetration test provides concrete evidence across four key Common Criteria:

1. CC4.1 (Evaluation of Controls): Demonstrates that management conducts ongoing or separate technical evaluations to verify that security controls are present and functioning properly.
2. CC4.2 (Deficiency Communication): Proves that technical vulnerabilities discovered during testing are documented, escalated, and communicated to the teams responsible for taking corrective action.
3. CC7.1 (Vulnerability Detection): Confirms that the organization maintains operational mechanisms to detect system configuration changes that introduce security flaws or leave assets vulnerable to newly discovered threats.
4. CC3.4 (Impact of Organizational Changes): Verifies that management evaluates the impact of major system, architectural, or code changes to ensure that ongoing modification does not degrade internal controls.

How Auditors Sample Penetration Testing Evidence

During a SOC 2 Type II review, auditors sample your testing records against strict operational criteria. The table below outlines how specific Common Criteria map to penetration testing evidence and what an auditor inspects during sampling:

Common Criterion	What a Penetration Test Evidences	What the Auditor Samples and Inspects
CC4.1: Evaluation of Controls	Independent validation that technical controls withstand active attack vectors	A full report whose defined scope matches your official SOC 2 system description, with execution dates falling squarely within the audit review period
CC4.2: Deficiency Communication	Formal recording and escalation of discovered security weaknesses to responsible engineers	Ticket logs, Jira issues, or remediation records showing each identified finding traced directly to an assigned owner and corrective action plan
CC7.1: Vulnerability Detection	Identification of configuration drift, unpatched software, and newly exposed attack paths	Evidence that testing evaluated runtime endpoints, exposed application programming interfaces (APIs), and underlying cloud infrastructure for known vulnerabilities
CC3.4: Impact of Organizational Changes	Validation that significant architectural updates did not introduce critical security flaws	Proof of targeted retesting or fresh penetration test cycles triggered immediately following major application or infrastructure releases

Auditors can reject penetration tests whose scope omits primary production components detailed in your system description. Furthermore, if a report flags Critical or High severity vulnerabilities without accompanying tickets or retest evidence proving remediation, the auditor may record a control deficiency under CC4.2.

How Should You Scope, Schedule, and Budget a SOC 2 Pentest?

Because the AICPA Trust Services Criteria do not prescribe rigid rules for penetration testing, organizations must make deliberate decisions regarding scope, frequency, and budget. Auditors evaluate these decisions by checking whether your testing strategy aligns consistently with your internal risk assessment.

Scoping the Test to the System Description

The golden rule of SOC 2 pentest scoping is simple: your testing boundary must reflect your official system description. If your SOC 2 report covers a multi-tenant cloud platform, your penetration test scope must include:

• All customer-facing web applications and mobile frontends.
• External and internal API endpoints supporting those services.
• Core cloud infrastructure, storage buckets, and microservices.
• Authenticated and unauthenticated testing across multiple user roles (such as tenant admin, standard user, and unauthenticated visitor).

Omitting core infrastructure or key API routes that are explicitly listed in your system description will draw immediate scrutiny during an audit.

How Often Should You Test?

Industry standard practice for SOC 2 is to conduct a full penetration test annually, supplemented by targeted testing following significant architectural or code modifications. However, it is essential to remember that this is a market convention, not an AICPA directive.

To understand what a rigid, mandatory requirement looks like by contrast, examine Payment Card Industry Data Security Standard (PCI DSS) v4.0.1 Requirement 11.4, which explicitly mandates internal and external penetration testing at least once every 12 months and after any significant infrastructure or application change. SOC 2 offers far more flexibility, allowing management to define testing cadences based on their specific risk model, provided that choice is supported by documented risk assessments.

What Does a SOC 2 Pentest Cost?

Independent, peer-reviewed benchmarks for SOC 2 penetration test pricing are hard to find. However, compliance automation vendor Secureframe notes a typical $15,000 pentest cost within their overall SOC 2 preparation budget breakdown.

In practice, actual pricing varies based on several scoping variables:

• Target Volume: The number of unique web applications, microservices, and external API routes.
• Authentication Depth: The complexity of user roles and permission matrices being tested.
• Access Level: White-box assessments (with source code access) versus black-box tests.
• Retesting Rights: Whether remediation validation is included in the initial quote or billed separately.

What ISO 27001 Expects by Comparison

If your organization is pursuing ISO/IEC 27001:2022 certification alongside SOC 2, a similar dynamic applies. ISO 27001 does not explicitly use the term “penetration test” in its main text. Instead, certification auditors look for testing evidence under Annex A Control 8.8 (Management of technical vulnerabilities) and Control 8.29 (Security testing in development and acceptance), with a scoped penetration test serving as a common form of evidence for both controls.

Is an Annual Pentest Enough for SOC 2 Type II?

A traditional annual penetration test records your security posture across a single, narrow timeframe. While this point-in-time assessment satisfies the baseline expectations of most auditors, relying solely on an annual test during a 6- or 12-month SOC 2 Type II review period introduces operational compliance risk.

Because a Type II audit evaluates whether internal controls operated effectively throughout the entire review window, any major architectural updates, new API endpoints, or code releases deployed between annual tests remain untested.

Adopting a continuous penetration testing model addresses this coverage gap by generating a continuous, timestamped trail of evaluations, vulnerability detections, and verified fixes across the full audit period. This ongoing evidence stream provides auditors with clear proof that control evaluation under CC4.1 and vulnerability detection under CC7.1 operated without interruption.

Maintaining an annual third-party penetration test report from a traditional pentesting engagement alongside continuous testing remains best practice, ensuring that enterprise customers and auditors requesting a traditional report by name receive a complete deliverable.

Preparing Evidence: Findings, Remediation, and Retesting

When an auditor samples a penetration test, they trace every identified finding through a complete, verifiable evidence chain. Presenting a report containing unaddressed Critical or High severity findings without documented follow-up is one of the quickest ways to trigger an audit deficiency.

A complete audit evidence chain consists of five distinct artifacts:

1. The Report Finding: The initial technical description, severity score, and affected endpoint recorded during testing, set out finding by finding, as in this sample penetration test report.
2. The Remediation Ticket: A corresponding task in Jira, GitHub Issues, or a ticketing system showing an assigned engineering owner, priority level, and target due date.
3. The Code or Configuration Fix: A pull request, commit hash, or infrastructure change log documenting the exact technical modification made to address the vulnerability.
4. The Retest Verification: An official retest entry or automated verification log proving that the fix was tested and successfully neutralized the exploit path.
5. The Final Closure Record: A timestamped ticket resolution date falling within the designated SOC 2 review window.

If a finding cannot be fully remediated before the audit period ends, management must provide a formal risk acceptance document or an active, milestone-driven remediation plan rather than leaving the issue unaddressed. Whether testing occurs once a year or continuously, maintaining this unbroken chain of evidence proves to auditors that your deficiency management process functions effectively under CC4.2.

Where Does SOC 2 Pentest Evidence Fall Short?

Even well-intentioned security teams often encounter audit friction due to easily avoidable documentation gaps. When an auditor rejects penetration testing evidence, it is typically caused by one of the following primary failure modes:

• Scope Mismatch: The penetration test scope fails to cover the full application boundary, cloud environments, or critical API endpoints defined in the official SOC 2 system description.
• Date Misalignment: The testing execution dates fall entirely outside the designated SOC 2 Type II review period.
• Vulnerability Scans Disguised as Pentests: The deliverable consists solely of raw, unverified output from automated vulnerability scanners without human or agentic proof of exploitation.
• Unlinked Remediation Records: Identified findings lack corresponding ticketing records, pull requests, or developer assignment logs proving that corrective action was initiated.
• Unvalidated Fixes: Security tickets are marked as resolved in internal systems without an official retest log or validation entry confirming that the patch effectively closed the vulnerability.
• Reused Historical Reports: Submitting a single historical penetration test report across multiple audit cycles without conducting fresh testing during the active review window.
• Undocumented Tester Independence: Relying on internal security teams to perform the assessment without maintaining formal documentation proving their operational independence from the development teams building the target systems.

Producing Continuous SOC 2 Evidence with OX Security

Meeting SOC 2 compliance requirements while maintaining rapid development velocity requires automating the collection of technical security evidence. The OX AI-Native Application Protection Platform (AINAPP) delivers evidence-based security validation and automated compliance tracking to streamline audit preparation across the enterprise.

Within the platform, OX Agentic Pentester  (currently in Early Access) runs AI-driven penetration tests against web applications, attacking live targets, backing each finding with evidence, and correlating discovered endpoints with the connected source repositories. It generates both high-level executive summaries and detailed technical findings reports to ensure full visibility for leadership and engineering teams alike.

Complementing this offensive capability, the broader platform powers continuous compliance monitoring and reporting aligned with more than 35 compliance frameworks, SOC 2 among them. By maintaining service level agreement (SLA) tracking, automated Mean Time to Remediate (MTTR) metrics, and audit logs, the platform helps your organization retain an unbroken, audit-ready chain of evidence throughout the entire SOC 2 Type II review period.

Treating SOC 2 Pentesting as Year-Round Evidence

The AICPA Trust Services Criteria ultimately require proof that internal controls are regularly evaluated and operating effectively, rather than mandating a specific penetration testing document by name. While a single annual test satisfies basic procurement checklists, the strongest evidence an organization can present during a SOC 2 Type II audit is an unbroken, timestamped chain of continuous testing, developer fixes, and retest verifications spanning the entire review window.

By aligning your testing scope directly with your official system description and automating the evidence collection lifecycle, compliance ceases to be an annual sprint. Instead, security teams maintain audit readiness year-round while ensuring production applications remain resilient against evolving threats.

To see how automated validation and continuous security monitoring generate audit-ready compliance evidence, book a demo with OX Security.