SOC 2 Penetration Testing Requirements Explained

If you are a SaaS company pursuing SOC 2 compliance, you have almost certainly encountered the penetration testing question. Your auditor mentioned it during the readiness assessment. Your compliance consultant included it on the preparation timeline. Your prospective enterprise customer asked for your most recent pentest report alongside the SOC 2 attestation. And yet, when you read the actual SOC 2 Trust Service Criteria, you will not find the words "penetration testing" anywhere.

This apparent contradiction is one of the most common sources of confusion for companies going through their first SOC 2 examination. The reality is nuanced: while penetration testing is not an explicit requirement, it has become a de facto expectation because it is the most effective way to demonstrate compliance with several Trust Service Criteria. Understanding this distinction, and knowing exactly what auditors are looking for, can save your organization significant time, money, and frustration.

At CyberGuards, we work with dozens of San Francisco Bay Area SaaS companies each year on SOC 2-aligned penetration testing. This guide distills our experience into a practical resource that covers the compliance rationale, scoping guidance, auditor expectations, and a readiness checklist to ensure your penetration test satisfies SOC 2 requirements.

How Penetration Testing Maps to Trust Service Criteria

SOC 2 is built on the Trust Service Criteria (TSC), a set of principles defined by the AICPA that govern how organizations manage data security, availability, processing integrity, confidentiality, and privacy. Penetration testing supports several TSC categories, particularly within the Common Criteria (CC) that apply to every SOC 2 examination.

CC6.1 — Logical and Physical Access Controls

This criterion requires that the organization implements logical access security measures to protect against unauthorized access. Penetration testing directly validates whether these access controls are effective in practice, not just in policy. A well-executed penetration test will attempt to bypass authentication mechanisms, escalate privileges, access unauthorized resources, and exploit misconfigurations in access control implementations.

When an auditor reviews CC6.1, they want to see evidence that access controls have been tested by an independent party. A penetration test report that documents testing of authentication mechanisms, session management, and authorization controls provides exactly this evidence.

CC7.1 — Identification of Vulnerabilities

CC7.1 requires 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 is one of the most direct ways to satisfy this criterion because it actively identifies vulnerabilities that exist in the current production environment.

Auditors typically look for evidence of both automated vulnerability scanning and manual penetration testing. Automated scans provide breadth of coverage, while penetration tests provide the depth of analysis needed to identify complex vulnerabilities that scanners miss, such as business logic flaws, authorization bypasses, and chained attack scenarios.

CC7.2 — Monitoring System Components

This criterion covers the monitoring of system components for anomalies that are indicative of malicious acts, natural disasters, and errors affecting the entity's ability to meet its objectives. While penetration testing is not a monitoring activity itself, it validates whether monitoring systems actually detect malicious activity. During a penetration test, the testing team's activities should trigger alerts and log entries. If they do not, that itself is a significant finding.

CC7.3 — Evaluation of Security Events

CC7.3 requires that the organization evaluates security events to determine whether they could or have resulted in a failure to meet objectives. Penetration test findings represent security events that must be evaluated and addressed. The remediation process following a penetration test directly demonstrates compliance with this criterion.

CC7.4 — Response to Security Incidents

While penetration testing does not directly test incident response (that would be a red team engagement), the findings and remediation process demonstrate that the organization can identify, evaluate, and respond to security issues. Some organizations use the penetration test as an opportunity to exercise their incident response procedures by treating testing notifications as if they were real security events.

What Auditors Actually Expect

Auditor expectations regarding penetration testing vary, but after working with numerous audit firms across the San Francisco Bay Area and nationally, we have identified consistent patterns in what auditors look for and what causes friction during the examination process.

Independence of the Testing Firm

Auditors expect the penetration test to be conducted by an independent third party, not by your internal engineering or security team. While internal testing is valuable for ongoing security, it does not satisfy the independence requirement for SOC 2 evidence. The testing firm should have no other business relationship with your organization that could compromise their objectivity.

The testing firm's qualifications also matter. Auditors may ask about the firm's credentials, certifications (OSCP, CREST, PNPT), years of experience, and relevant industry expertise. Having your pentest conducted by a reputable, specialized offensive security firm rather than a generalist IT consultancy strengthens the evidentiary value of the report.

Scope Alignment with the SOC 2 Boundary

The penetration test scope must align with the system boundary defined in your SOC 2 report. If your SOC 2 boundary includes your web application, API layer, cloud infrastructure, and corporate network, the penetration test should cover all of these components. A penetration test that only covers the web application when the SOC 2 boundary includes infrastructure will raise questions from auditors.

Conversely, testing components outside the SOC 2 boundary is not necessary for compliance purposes (though it may be valuable for overall security). Work with your auditor to align the penetration test scope with the defined system boundary before the engagement begins.

Report Quality and Content

Auditors need specific information from the penetration test report to complete their examination. A report that is too brief or lacks key elements will require follow-up, which delays the audit. At minimum, auditors expect:

• Clear scope definition: What was tested, including specific URLs, IP ranges, applications, and environments
• Testing methodology: The frameworks and standards followed (OWASP, PTES, NIST) and the types of testing performed (black box, gray box, white box)
• Testing timeline: When testing was performed and the total duration
• Findings with severity ratings: Each vulnerability should include a clear description, severity rating (CVSS or equivalent), evidence of exploitation, and specific remediation guidance
• Remediation status: Whether findings have been remediated and, ideally, evidence of retest confirming the fixes
• Executive summary: A non-technical overview that auditors can include in their workpapers without extensive translation

Timeliness

The penetration test must have been conducted within the audit period for Type II reports, or reasonably close to the report date for Type I reports. A penetration test conducted eighteen months ago does not provide relevant evidence about the current security posture. Most auditors expect the penetration test to have been conducted within the last twelve months, with many preferring testing within the current audit period.

Type I vs. Type II: Penetration Testing Differences

The type of SOC 2 report you are pursuing affects how penetration testing fits into your compliance program.

SOC 2 Type I

A Type I report evaluates the design of your controls at a specific point in time. For penetration testing, this means the auditor wants to see that you have a penetration testing process in place and that a test has been conducted (or is scheduled). The pentest report itself serves as evidence that the vulnerability identification control (CC7.1) is designed and implemented.

For Type I, the penetration test should be completed before or during the audit date. If you are pursuing Type I as a stepping stone to Type II, use this initial penetration test to establish a baseline and identify issues that need to be remediated before the Type II observation period begins. Many San Francisco startups pursue Type I first to close enterprise deals quickly, then transition to Type II within six to twelve months.

SOC 2 Type II

A Type II report evaluates the operating effectiveness of your controls over a period of time, typically six to twelve months. For penetration testing, this means the auditor needs evidence that testing is performed regularly, not just once. The pentest must fall within the observation period, and the auditor will review both the test results and the remediation process.

For Type II, demonstrating a mature testing cadence strengthens your compliance posture. If your observation period is twelve months, having a penetration test at the beginning and end of the period (or quarterly tests throughout) provides stronger evidence than a single annual test. The remediation of findings during the observation period also provides evidence for CC7.3 and CC7.4.

Frequency Requirements

How often should you conduct penetration testing for SOC 2 compliance? The answer depends on your organization's risk profile, the complexity of your environment, and your auditor's expectations.

Minimum Expectations

At minimum, most auditors expect an annual penetration test. This aligns with the typical twelve-month Type II observation period and provides evidence that vulnerability identification controls operate throughout the period. Annual testing is the baseline, not the best practice.

Recommended Frequency

For organizations with active development and frequent deployments, which describes most SaaS companies, we recommend more frequent testing:

• Annual comprehensive assessment: A full-scope penetration test covering all in-scope components, conducted by an external firm. This is the anchor assessment for your SOC 2 evidence.
• Quarterly focused assessments: Targeted tests of new features, significant changes, or previously identified vulnerability areas. These can be shorter engagements focused on specific risk areas.
• Continuous automated scanning: Regular vulnerability scans (monthly or more frequently) to maintain visibility into the security posture between manual assessments. Automated scanning is complementary to, not a substitute for, manual penetration testing.

Trigger-Based Testing

Beyond scheduled assessments, certain events should trigger additional penetration testing:

• Major application releases or significant feature additions
• Infrastructure changes such as cloud provider migrations, new services, or architecture changes
• Merger or acquisition activities that introduce new systems into the environment
• Security incidents that suggest undiscovered vulnerabilities may exist
• Changes to the SOC 2 system boundary that bring new components into scope

Report Deliverables for SOC 2

The penetration test report is the primary deliverable that your auditor will review. Ensuring the report contains the right information in the right format saves time during the examination and prevents follow-up requests that delay attestation.

Essential Report Components

Based on our experience working with audit firms, these report components are essential for SOC 2 purposes:

• Engagement letter or statement of work: Documents the agreed scope, methodology, and authorization. Auditors use this to verify that the test was properly scoped and authorized.
• Executive summary: A concise, non-technical overview of the assessment, key findings, and overall risk posture. This is what auditors reference most frequently in their workpapers.
• Methodology section: Description of the testing approach, frameworks used (OWASP, PTES), testing type (black box, gray box), and tools employed. This demonstrates that the testing was systematic and comprehensive.
• Detailed findings: Each finding should include a unique identifier for tracking, a descriptive title, severity rating with justification (CVSS scores are ideal), a detailed description of the vulnerability, step-by-step reproduction instructions, evidence such as screenshots and request/response captures, specific remediation guidance, and a reference to the relevant TSC criterion.
• Remediation tracking: A summary showing each finding's current remediation status (open, in progress, remediated, accepted risk). Include retest results for remediated findings when available.
• Attestation of independence: A statement confirming that the testing firm is independent and has no conflicts of interest. Some auditors request this explicitly.

Mapping Findings to Trust Service Criteria

One of the most valuable things a penetration testing firm can do for SOC 2 purposes is map each finding to the relevant Trust Service Criteria. This saves your compliance team hours of work and makes the auditor's job significantly easier. For example:

• An authentication bypass finding maps to CC6.1 (Logical and Physical Access Controls)
• A missing security header finding maps to CC6.1 and CC6.6 (Security Measures Against Threats Outside System Boundaries)
• An unpatched software finding maps to CC7.1 (Identification of Vulnerabilities)
• A lack of monitoring for the tested attack vectors maps to CC7.2 (Monitoring System Components)

Common Penetration Testing Findings in SOC 2 Audits

Certain findings appear with remarkable consistency across SOC 2-aligned penetration tests. Knowing what to expect allows your engineering team to proactively address these issues before the assessment, reducing the remediation burden after the report is delivered.

High-Frequency Findings

• Missing or misconfigured security headers: Content-Security-Policy, Strict-Transport-Security, X-Content-Type-Options, and X-Frame-Options are frequently absent or misconfigured. These are low-severity findings that are easy to fix and demonstrate security awareness.
• Verbose error messages: Application error messages that reveal stack traces, database queries, file paths, or framework versions provide reconnaissance information to attackers. Configure production error handling to return generic messages while logging details server-side.
• Insecure Direct Object References (IDOR): Authorization checks that verify authentication but not resource-level authorization are found in the majority of first-time assessments. This is typically a medium to high severity finding.
• Weak session management: Session tokens that do not expire, sessions that persist after password changes, missing cookie security attributes, and concurrent session issues appear regularly.
• Insufficient rate limiting: Login endpoints, password reset endpoints, and API endpoints that lack rate limiting enable brute force attacks and automated abuse.
• Outdated software components: Third-party libraries, frameworks, and server software with known vulnerabilities. Software composition analysis should be part of your CI/CD pipeline to catch these before the pentest.
• Excessive data in API responses: API endpoints that return complete database objects instead of carefully constructed response schemas, leaking internal fields, metadata, or sensitive data.

Findings That Concern Auditors Most

Not all findings carry equal weight in the auditor's assessment. The findings that most concern auditors are those that directly undermine the Trust Service Criteria, particularly:

• Authentication bypasses or weaknesses that allow unauthorized access (directly undermines CC6.1)
• Authorization failures that allow cross-tenant data access in multi-tenant SaaS environments (directly undermines CC6.1 and C1.1 for Confidentiality)
• SQL injection or other vulnerabilities that could lead to data breach (directly undermines CC6.1 and multiple other criteria)
• Lack of evidence that previous findings were remediated (undermines CC7.3 and suggests controls are not operating effectively)

SOC 2 Penetration Testing Readiness Checklist

Use this checklist to ensure your organization is prepared for a SOC 2-aligned penetration test. Completing these items before the engagement begins maximizes the value of the assessment and minimizes delays.

Pre-Engagement Readiness

• SOC 2 system boundary is defined and documented
• Penetration test scope aligns with the SOC 2 system boundary
• Testing timeline falls within the SOC 2 observation period (Type II) or near the report date (Type I)
• Independent penetration testing firm is selected and contracted
• Statement of Work and rules of engagement are signed
• Testing firm has confirmed they will map findings to Trust Service Criteria
• Cloud provider notification requirements are reviewed (if applicable)

Technical Readiness

• Test accounts are provisioned for each user role in the application
• API documentation and architecture diagrams are available for the testing team
• Testing team IP addresses are whitelisted in WAF and rate-limiting systems
• Testing environment is stable and will not be redeployed during the engagement
• Technical point of contact is designated and available during the testing window
• Secure communication channel is established for the engagement
• Logging and monitoring are active so detection capabilities can be evaluated

Post-Engagement Actions

• Penetration test report is reviewed by the security and engineering teams
• Findings are entered into a tracking system with assigned owners and target dates
• Critical and high findings are remediated within 30 days
• Medium findings are remediated within 90 days
• Remediation is verified through retest by the penetration testing firm
• Risk acceptance is formally documented for any findings not remediated
• Report and remediation evidence are packaged for auditor review
• Lessons learned are incorporated into development practices to prevent recurrence

Choosing the Right Penetration Testing Partner for SOC 2

The penetration testing firm you select directly impacts the quality of your SOC 2 evidence. Not all penetration testing providers understand SOC 2 requirements or produce reports that satisfy auditor expectations. When evaluating firms, consider:

• SOC 2 experience: Does the firm regularly conduct SOC 2-aligned assessments? Can they provide sample report formats? Do they understand Trust Service Criteria mapping?
• Technical depth: Will the assessment be performed by experienced penetration testers, or by junior analysts running automated scanners? The difference is substantial in terms of finding quality and report value.
• Industry relevance: Does the firm have experience testing applications similar to yours? A firm that specializes in SaaS applications will be more effective than a generalist that primarily tests corporate networks.
• Report quality: Request a redacted sample report to evaluate the level of detail, clarity of findings, and alignment with SOC 2 needs before committing to an engagement.
• Remediation support: Does the firm provide retest as part of the engagement? Can they advise on remediation approaches? Retesting is essential for demonstrating that findings have been addressed.

CyberGuards has conducted SOC 2-aligned penetration tests for hundreds of SaaS companies across the San Francisco Bay Area. Our reports are designed from the ground up to satisfy auditor requirements, with TSC mapping, CVSS scoring, detailed reproduction steps, and remediation verification included in every engagement. We work directly with your auditor when needed to ensure the evidence we provide meets their specific expectations.

"A penetration test conducted for SOC 2 should serve two masters: it must satisfy the auditor's evidentiary requirements, and it must provide genuine security value to the engineering team. The best assessments accomplish both without compromise."

Key Takeaways

• SOC 2 does not explicitly require penetration testing, but it is the most effective way to demonstrate compliance with CC6.1, CC7.1, CC7.2, CC7.3, and CC7.4.
• The penetration test scope must align with the SOC 2 system boundary. Work with your auditor to ensure alignment before the engagement.
• For Type II reports, the penetration test must fall within the observation period. Plan your testing timeline in coordination with the audit timeline.
• Annual penetration testing is the minimum expectation. Quarterly focused assessments and continuous scanning provide stronger evidence of ongoing security.
• The penetration test report must include clear scope, methodology, detailed findings with severity ratings, and remediation status. Mapping findings to TSC criteria saves significant time during the audit.
• Address the most common findings proactively: security headers, error handling, IDOR, session management, rate limiting, and software patching.
• Start the penetration testing process at least three months before your audit to allow time for testing, remediation, retesting, and report finalization.