Your Guide to SOC 2 Penetration Testing Requirements

A SOC 2 penetration test is a simulated cyberattack against an organization’s systems, applications, and infrastructure that fall within the scope of its SOC 2 audit. The primary purpose of this test is to identify, exploit, and document security vulnerabilities to provide evidence for the effectiveness of security controls as defined by the AICPA’s Trust Services Criteria (TSC), particularly the Security (Common Criteria) principle.

While the AICPA’s official guidance for SOC 2 does not contain a line item explicitly mandating “penetration test,” the practice has become a de facto requirement for technology companies. SOC 2 auditors are required to gather sufficient evidence to form an opinion on the effectiveness of a company’s security controls. A penetration test provides direct, adversarial evidence that is difficult to obtain through other means. It validates that the documented security measures, such as those under the Common Criteria, function as intended when subjected to a realistic attack simulation, making it an expected piece of evidence in modern SOC 2 audits.

Understanding Penetration Testing in a SOC 2 Context

For a SOC 2 audit, a penetration test is not merely a technical security assessment; it is a critical piece of evidence demonstrating the operational effectiveness of your security controls. It moves your security program from theoretical policies to practical application by having an independent expert actively attempt to circumvent the controls you have implemented and documented. This process directly addresses an auditor’s need to verify that controls are not just designed properly but are also functioning effectively in a real-world environment.

Why this matters for SOC 2: An auditor’s primary goal is to gain assurance. A policy stating that access controls are in place is one level of evidence. A penetration test report showing that those access controls successfully repelled a simulated attacker is a much higher, more persuasive level of evidence. It provides tangible proof that supports your assertion of having a strong security posture.

Why It’s Practically Mandatory for an Audit

While the official AICPA guidance for SOC 2 lacks a specific mandate for penetration testing, the industry and auditor expectations have solidified around this practice. For any SaaS or technology company, a SOC 2 report without a corresponding penetration test is often viewed as incomplete. This is because a penetration test is the most effective method to validate the operational effectiveness of controls designed to meet criteria like CC4.1, which requires an entity to use a combination of ongoing and separate evaluations to monitor internal controls.

Why this matters for SOC 2: Auditors view a penetration test as a “separate evaluation” that provides objective evidence of your security control effectiveness. Without it, you are asking the auditor to trust your internal monitoring and documentation alone. A recent penetration test report serves as independent validation that your system can withstand attack attempts, significantly strengthening the credibility of your SOC 2 report and reducing the likelihood of audit findings related to control weaknesses.

Connecting Testing to Trust Services Criteria

The true value of a penetration test within a SOC 2 audit lies in its direct mapping to specific Trust Services Criteria (TSC). The findings from the test are not abstract technical issues; they are concrete data points that demonstrate compliance or non-compliance with the control objectives outlined in the SOC 2 framework.

A penetration test provides crucial evidence for several key criteria, including:

• CC4.1 (Monitoring Activities): A penetration test serves as a periodic “separate evaluation” to confirm that internal controls are present and functioning as intended.
• CC7.1 (System Operations - Vulnerability Management): The test directly evaluates your ability to identify vulnerabilities. The subsequent remediation process demonstrates your capacity to “evaluate and respond” to identified threats, fulfilling a core requirement of this criterion.
• CC9.2 (Incident Management): A successful exploit during a test can trigger your incident response plan, providing a real-world opportunity to demonstrate that your detection, response, and recovery procedures are effective.

Why this matters for SOC 2: A penetration test transforms your compliance narrative from simply stating that you have controls to proving they work. It provides your auditor with the demonstrable evidence needed to conclude that your controls are suitably designed and operating effectively, which is the cornerstone of a clean, unqualified audit opinion. You can see how these connect in our detailed guide on the SOC 2 Common Criteria explained.

Scoping Your SOC 2 Penetration Test Correctly

Correctly defining the scope is the most critical initial step in a SOC 2 penetration test. The scope must be precisely aligned with your SOC 2 “system boundary,” which encompasses all the people, processes, and technology involved in delivering your services to customers. A misaligned scope—either too narrow or too broad—can render the test results irrelevant for the audit, wasting time and resources.

Why this matters for SOC 2: Your auditor will scrutinize the penetration test scope to ensure it covers the entire system they are auditing. A test scoped too narrowly leaves critical components of your service unassessed, creating a gap in your evidence. This directly impacts the auditor’s ability to gain assurance over criteria like CC7.1, as they cannot confirm that your vulnerability management process covers the full attack surface relevant to customer data. A properly scoped test tells the auditor you understand your system and are proactively securing all relevant parts.

Identifying Your SOC 2 System Boundary

Your SOC 2 system boundary is the complete ecosystem that supports the services defined in your audit scope. You must identify every asset that processes, stores, or transmits customer data, as well as any systems that could impact the security of that data.

For a typical SaaS company, the following components must be included in the penetration test scope:

• Primary Web Application: The customer-facing platform and its underlying infrastructure.
• APIs: All external (customer-facing) and critical internal APIs that handle data or authentication.
• Cloud Infrastructure: The configuration of your cloud environment (AWS, Azure, GCP), including identity and access management (IAM), network security groups, storage bucket policies, and database configurations.
• Internal Networks & Supporting Systems: Any internal systems that, if compromised, could provide a pathway to the production environment, such as administrative consoles or CI/CD pipelines.
• Third-Party Integrations: The connection points and data flows between your system and any critical third-party services that are part of your service delivery.

Why this matters for SOC 2: A comprehensive scope is your proof to the auditor that you have a holistic view of your security risk. It demonstrates that you are not just securing the front door (your web app) but also the windows, back doors, and internal hallways that an attacker could exploit.

This diagram illustrates how a properly scoped penetration test is not an isolated event but an integral part of the evidence-gathering process that validates the effectiveness of your security controls for the audit.

Determining the Right Testing Frequency

While the AICPA framework does not prescribe a specific testing frequency, annual penetration testing is the established industry standard and the minimum expectation for SOC 2 compliance. However, your specific risk profile and the rate of change within your environment should dictate the actual cadence.

Why this matters for SOC 2: The frequency of testing provides evidence for criteria like CC4.1 (Monitoring Activities) and CC7.2 (Change Detection). A regular testing schedule proves that your security evaluations are ongoing and that you are proactively assessing the impact of changes on your security posture. For a fast-moving company, a single annual test may not be sufficient to provide an auditor with confidence that security is maintained throughout the audit period.

A penetration test report from six months ago on a version of your product that has since undergone major architectural changes is of little value to an auditor. The test evidence must be relevant to the system as it existed during the audit’s observation period.

Recommended SOC 2 Penetration Testing Frequency

This table provides actionable guidance on scheduling penetration tests to align with your development lifecycle and SOC 2 audit requirements, ensuring the evidence you provide is timely and relevant.

Scenario / Company Profile	Recommended Frequency	Primary SOC 2 Criteria Supported	Justification for SOC 2
First SOC 2 Type 2 Audit	Annually, timed just before or at the beginning of the observation period.	CC7.1, CC4.1	Establishes a security baseline and provides timely evidence for the initial audit period. This timing ensures findings can be remediated within the observation window.
Growth-Stage SaaS	Annually, plus after any major product releases or architectural changes.	CC7.2, CC8.1	The rapid pace of change introduces new potential vulnerabilities. Testing after major changes demonstrates that your change management process includes security validation.
High-Risk/Fintech/Healthtech	Every 6 months, or quarterly if handling highly sensitive data.	CC3.2, CC7.1, A1.2	The higher risk associated with the data requires more frequent and rigorous validation of controls to meet heightened auditor and customer expectations.
Mature Enterprise	Annually at a minimum, supplemented with continuous, automated scanning.	CC7.1, CC4.2	Demonstrates a mature, ongoing risk management program. This combination shows auditors both point-in-time expert validation and continuous automated monitoring.
Post-Security Incident	Immediately following remediation of a significant breach or incident.	CC9.2	Validates that remediation efforts were successful and the underlying vulnerability is closed, providing crucial evidence for the effectiveness of your incident response.

Matching your testing cadence to your risk and development velocity ensures you always have fresh, relevant evidence for your auditor. You can learn more about how testing frequency aligns with audit requirements on BrightDefense.com. A well-scoped test, performed at the right frequency, produces a powerful, defensible report that is a cornerstone of a smooth audit process.

Penetration Tests vs Vulnerability Scans What Auditors Expect

It is crucial to understand that penetration tests and vulnerability scans are distinct activities, and your SOC 2 auditor will expect evidence from both. Submitting a vulnerability scan report in place of a penetration test report is a common mistake that will be immediately rejected by an auditor, as they serve different purposes and provide different types of assurance.

A vulnerability scan is an automated process that uses software to check systems against a database of known vulnerabilities. A penetration test is a manual, human-driven process where a security expert simulates an attacker’s actions to identify and exploit vulnerabilities, including complex business logic flaws that automated tools cannot find.

Why this matters for SOC 2: For an auditor, these two activities satisfy different requirements. Vulnerability scans provide evidence of continuous monitoring and security hygiene (breadth), while penetration tests provide evidence of in-depth, adversarial testing of control effectiveness (depth). You need both to demonstrate a comprehensive and mature vulnerability management program.

The Role of Each in a SOC 2 Audit

From a SOC 2 compliance perspective, scans and penetration tests are complementary controls that provide evidence for different aspects of your security program.

Vulnerability scans are your proof of an ongoing, automated process to identify common weaknesses across your infrastructure. A penetration test, conversely, is a targeted, manual assessment that demonstrates how those weaknesses might be chained together by a skilled attacker to achieve a significant compromise. This manual testing is essential for uncovering complex authorization bypasses or business logic flaws that automated tools are blind to.

This distinction maps directly to specific SOC 2 criteria:

• Vulnerability Scans Support CC7.1: They demonstrate you have a continuous process to “identify and position the entity to respond to threats,” proving you have an operational vulnerability management program.
• Penetration Tests Support CC4.1: They serve as a “separate evaluation” to prove your security controls are truly effective against a simulated real-world attack.

Why this matters for SOC 2: Presenting evidence from both scans and penetration tests shows the auditor a layered security strategy. It proves you are using automated tools for broad, continuous coverage and human expertise for deep, targeted validation of your most critical systems.

How Auditors Interpret the Results

An auditor reviews reports from both activities with a different lens. For a vulnerability scan report, their focus is on process: Did you scan all in-scope systems? Is there a documented process for triaging and remediating the findings within a defined SLA?

When reviewing a penetration test report, the auditor’s expectations are much higher. They are looking for a narrative that details a methodical, adversarial assessment of the systems within your SOC 2 boundary. A shallow report filled with unvalidated, low-impact findings from an automated scanner will not suffice. To see how auditors view different methodologies, exploring automated penetration testing software can provide valuable context on what passes muster.

Why this matters for SOC 2: An auditor wants to see evidence of critical, human-led analysis. A strong penetration test report doesn’t just list a vulnerability; it explains the specific business impact within the context of your service. For example, it will detail how a specific flaw could be exploited to compromise customer data, directly linking a technical finding to a compliance risk.

Penetration Testing vs Vulnerability Scanning for SOC 2

This table provides a clear comparison of the two security testing methods, highlighting their distinct purpose, methodology, and value as evidence for a SOC 2 audit.

Attribute	Vulnerability Scanning	Penetration Testing
Methodology	Automated: Uses software to scan for known vulnerabilities (CVEs) and common misconfigurations.	Manual & Human-Driven: Security experts simulate real-world attack techniques to exploit vulnerabilities and bypass controls.
Primary Goal	Discover: To generate a broad list of potential vulnerabilities across many systems.	Exploit: To demonstrate the real-world impact of vulnerabilities by achieving specific objectives (e.g., access sensitive data).
SOC 2 Evidence	Evidence of ongoing monitoring and baseline security hygiene (supports CC7.1).	Proof of control effectiveness against a skilled, human adversary (supports CC4.1).
Auditor Focus	”Do you have a consistent process for scanning, triaging, and patching?"	"Was the scope correct? Were critical flaws found? Can you prove they were remediated and retested?”
Key Output	A comprehensive list of potential findings, which may include false positives.	A detailed, contextual report with reproducible attack chains, business impact analysis, and actionable remediation guidance.

Why this matters for SOC 2: Arriving at your audit with evidence from both activities demonstrates a mature, risk-based approach to security. This assures the auditor that you are not just checking boxes but are actively managing vulnerabilities through a combination of automated breadth and manual depth, significantly strengthening your compliance posture.

The Anatomy of an Auditor-Ready Pentest Report

The final penetration test report is one of the most important pieces of evidence you will provide to your SOC 2 auditor. A vague, incomplete, or poorly structured report can undermine the entire value of the test, raising red flags about the maturity of your vulnerability management program. The report must be a clear, comprehensive, and standalone document that tells a compelling story about your security posture.

Why this matters for SOC 2: The report is your primary artifact for proving compliance with criteria like CC7.1, which requires you to have a process to detect, evaluate, and respond to vulnerabilities. A high-quality report is direct evidence that you have a robust process for the “detect and evaluate” portions of that requirement. It is the tangible output that the auditor will scrutinize to validate that your security controls are operating effectively.

Key Components of a Compliant Report

Your SOC 2 auditor has a mental checklist for what constitutes a credible penetration test report. They will expect to see a recognized methodology (e.g., OWASP Top 10, NIST SP 800-115) and a standard structure. A report missing these key sections is likely to be rejected.

Ensure your report includes these five essential sections:

1. Executive Summary: A one-page, non-technical overview for leadership. It must clearly state the scope, testing dates, a summary of the methodology, a high-level overview of critical findings, and an overall assessment of the system’s security posture.
2. Methodology and Scope: A precise definition of what was tested (IP addresses, URLs, applications), what was out of scope, and the exact testing methodology used. This section must align perfectly with your defined SOC 2 system boundary.
3. Detailed Technical Findings: The core of the report. Each finding must include a description of the vulnerability, its location, a severity rating, clear steps for reproduction, and supporting evidence such as screenshots or code snippets.
4. Risk Ratings and Business Impact: Every vulnerability must be assigned a risk score using a standard framework like the Common Vulnerability Scoring System (CVSS). Crucially, the report should also explain the specific business impact of each finding in the context of your service and customer data.
5. Actionable Remediation Guidance: The report must provide clear, practical recommendations for how your engineering team can fix each identified vulnerability. This guidance should be specific enough to form the basis of a remediation ticket.

What Auditors Look For Beyond the Basics

A truly effective report goes beyond a simple list of vulnerabilities. Experienced auditors can easily differentiate between a low-cost, automated scan report and a thorough, expert-led assessment. They are looking for evidence of a mature, risk-aware security program.

Why this matters for SOC 2: An auditor wants to see evidence of critical thinking and contextual analysis. A report that links technical findings to potential business impact—specifically, the risk to customer data—is far more valuable. For example, instead of just “Cross-Site Scripting found,” a strong report explains, “This Stored XSS vulnerability in the admin panel could allow a low-privilege user to inject a malicious script, which would execute in an administrator’s browser, leading to session hijacking and full administrative control over the application.” For more on creating effective compliance artifacts, check out our guide on essential SOC 2 documentation.

The report must tell a logical story, demonstrating a methodical approach to testing rather than a random collection of automated scan results. This analytical depth is what proves to your auditor that you have a structured, risk-based program for identifying and managing security weaknesses, making it a cornerstone of your SOC 2 audit readiness.

Managing Remediation and Retesting for Your Audit

Receiving the penetration test report is not the final step; it is the beginning of the remediation phase. For a SOC 2 audit, demonstrating a complete, closed-loop process for addressing identified vulnerabilities is just as critical as conducting the test itself. An auditor needs to see evidence that you not only found the weaknesses but also effectively fixed them.

Why this matters for SOC 2: The entire remediation and retesting cycle provides direct, tangible evidence for CC7.1 (System Operations) and CC9.2 (Incident Management). It proves you have an operational vulnerability management program that can “evaluate and respond” to threats. Presenting a report full of critical findings with no documented remediation plan is a significant red flag that will likely lead to an audit finding or exception.

Creating a Formal Remediation Workflow

You must have a formal, repeatable process for triaging, prioritizing, and resolving findings. Auditors expect to see a structured workflow, not an ad-hoc approach.

This workflow should follow these actionable steps:

1. Triage and Prioritization: A security or engineering lead reviews each finding, validating it and assigning a priority (e.g., Critical, High, Medium, Low) based on the report’s risk rating and internal business context.
2. Ticket Creation: Every validated finding is logged as a ticket in a system like Jira or Azure DevOps. The ticket must include the full description of the vulnerability, reproduction steps, and the recommended remediation from the report.
3. Assignment and Tracking: Tickets are assigned to the appropriate engineering team. The ticket’s status must be meticulously tracked from creation to deployment of the fix.

Why this matters for SOC 2: This documented trail creates a clear, auditable chain of evidence. It allows an auditor to easily trace a vulnerability from its discovery in the penetration test report to a specific ticket, the code commit that fixed it, and its final resolution.

The Critical Role of Retesting

Once your team has deployed fixes for the identified vulnerabilities, the process is not complete until you have independent verification that the fixes are effective. You cannot self-attest that a vulnerability is gone; it must be validated by the third-party testing firm.

Most penetration testing providers include retesting for identified findings as part of their engagement. The output of this retest is a formal addendum or updated report confirming that the vulnerability was re-examined and could no longer be exploited.

Why this matters for SOC 2: The retest report is the final piece of evidence that closes the loop. Simply marking a ticket as “Done” is insufficient for an auditor. The independent, third-party validation from the retest provides the official proof that you have successfully remediated the vulnerability, satisfying the “respond” component of CC7.1. Without this, the effectiveness of your remediation remains unproven.

A typical SOC 2 penetration test can take anywhere from 2 to 6 weeks, and it is crucial to align this timeline with your audit’s observation period. You can find more insights on how to sync pentesting timelines with your audit on Blaze Infosec’s blog. Documenting this entire lifecycle provides a complete and compelling story to your auditor, demonstrating security diligence and paving the way for a successful SOC 2 audit.

Connecting Your Pentest to a Successful SOC 2 Audit

A penetration test is more than a technical requirement; it is a foundational piece of evidence that demonstrates the true effectiveness of your security program. For a SOC 2 audit, it provides tangible proof that your documented controls are not just theoretical but are capable of withstanding a simulated real-world attack. This is precisely the level of assurance auditors need to see to gain confidence in your security posture and issue a clean report.

The complete penetration testing lifecycle—from scoping and testing to remediation and retesting—directly supports multiple Trust Services Criteria, most notably CC4.1 (Monitoring Activities) and CC7.1 (Vulnerability Management). The test report, the associated remediation tickets, and the final retest confirmation letter serve as critical audit artifacts. Together, they tell a clear and convincing story of security diligence, proving you have a mature, repeatable process to identify, prioritize, resolve, and validate the security of your systems. This comprehensive approach transforms a technical security test from a simple checklist item into a cornerstone of your SOC 2 audit readiness.

---

Finding the right auditor who understands the nuances of penetration testing is crucial. At SOC2Auditors, we help you compare and connect with vetted audit firms that align with your company’s specific needs, budget, and timeline. Get matched with up to three auditors in 24 hours.