SOC 2 Penetration Testing for SaaS Companies: Requirements, Process, and How to Pass Your Audit

SOC 2 Compliance · SaaS Security · April 2026

Your SOC 2 auditor is asking for a penetration test. Your enterprise prospects require a SOC 2 Type II report before signing. This guide walks SaaS companies through exactly what SOC 2 requires from penetration testing, how to scope and time it correctly, and how to ensure your report passes auditor review without triggering control deficiencies.

💫 Key Takeaways

• SOC 2 does not explicitly mandate penetration testing, but virtually every auditor expects it as evidence for Trust Service Criteria CC7.1 (detection mechanisms) and CC7.2 (monitoring activities)
• The pentest must cover all systems within your SOC 2 boundary — if your system description includes your web app, API, and cloud infrastructure, all three must be tested
• Schedule your pentest at least 3 months before your observation period ends to leave time for remediation and retesting
• Unresolved critical findings in your pentest report are the #1 cause of SOC 2 control deficiency exceptions related to security testing
• The difference between a Type I and Type II report changes how auditors evaluate your pentest — Type II requires evidence of ongoing testing over the observation period
• A well-structured pentest report saves your auditor 4–8 hours of evidence review and reduces audit fees by streamlining the assessment

SOC 2 is based on the AICPA Trust Service Criteria, organized around five Trust Service Categories: Security (the Common Criteria, always required), Availability, Processing Integrity, Confidentiality, and Privacy. Each category includes specific criteria that your auditor evaluates. Penetration testing provides evidence for several criteria across the Security category.

The specific criteria most directly supported by penetration testing:

CC4.1 — COSO Principle 16: The entity selects, develops, and performs ongoing and/or separate evaluations to ascertain whether the components of internal control are present and functioning. A penetration test is a “separate evaluation” that verifies your security controls function under adversarial conditions. This is the most directly applicable criterion.

CC7.1: To meet its objectives, the entity 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 identifies vulnerabilities that automated monitoring may not detect, particularly business logic flaws and authorization errors.

CC7.2: The entity monitors system components and the operation of those components for anomalies that are indicative of malicious acts, natural disasters, and errors. While this criterion primarily addresses ongoing monitoring (SIEM, log analysis), penetration testing demonstrates that you are proactively looking for vulnerabilities rather than waiting for attackers to find them.

CC8.1: The entity authorizes, designs, develops or acquires, configures, documents, tests, approves, and implements changes to infrastructure, data, software, and procedures to meet its objectives. Penetration testing verifies that changes to your application have not introduced security vulnerabilities.

Your SOC 2 report includes a system description that defines which systems, infrastructure, and processes are in scope. Your penetration test must cover the technical components within this boundary. Here is how each Trust Service Category expands your pentest scope:

For most SaaS companies pursuing SOC 2, the Security criterion is mandatory and Availability and Confidentiality are commonly included. This means your penetration test should, at minimum, cover your web application, API, cloud infrastructure, and authentication/authorization systems. If Availability is in scope, add DoS resilience testing. If Confidentiality is included, add data leakage and encryption validation testing.

A mistake we see frequently: SaaS companies define a narrow SOC 2 scope to reduce audit cost (e.g., only the main web application) but then add infrastructure, APIs, and integrations over time without updating the scope. When the pentest covers only the original narrow scope but the auditor’s system description has expanded, a gap emerges. Always align your pentest scope with your current SOC 2 system description, not the original one.

Timing is one of the most critical and most commonly mishandled aspects of SOC 2 penetration testing. The pentest must fall within your SOC 2 observation period, and there must be sufficient time after the test for remediation and retesting. Here is how to plan:

Type I vs. Type II timing differences. A SOC 2 Type I report evaluates your controls at a single point in time. The pentest must be relatively recent — typically within 6 months of the report date. A SOC 2 Type II report evaluates controls over an observation period (usually 6 or 12 months). The pentest must fall within that observation period, and ideally early enough to allow remediation of findings before the period ends.

The ideal timeline for Type II. If your observation period is January through December, schedule your pentest for Q2 (April–June). This gives you July through November to remediate findings, retest, and have clean evidence ready when the auditor conducts fieldwork in Q4. Testing in Q4 is too late — if you find critical issues, there is no time to remediate them before the observation period ends.

First-time SOC 2 preparation. If you are pursuing SOC 2 for the first time, conduct a penetration test during the readiness assessment phase, before the observation period begins. Use the findings to fix vulnerabilities, implement missing controls, and establish your baseline. Then conduct another pentest during the observation period to demonstrate that controls are operating effectively. Yes, this means two pentests in year one — but it dramatically reduces the risk of control deficiencies in your first report.

Ongoing annual cadence. After your first SOC 2 Type II, establish an annual pentest cadence aligned with your observation period. Many SaaS companies schedule their pentest at the same point each year, roughly 3–4 months into the observation period. This creates a predictable schedule that your engineering team can plan around and ensures consistent evidence for each audit cycle.

Understanding what auditors look for helps you ensure your pentest report passes review the first time. Based on our experience supporting dozens of SOC 2 audits, here are the specific elements auditors verify:

Scope alignment. The auditor compares the pentest scope statement against the system description in the SOC 2 report. Every system component in the SOC 2 boundary should appear in the pentest scope. If your SOC 2 includes “web application, REST API, PostgreSQL database, and AWS infrastructure,” the pentest should explicitly list testing of each component.

Testing date within the observation period. The auditor verifies that the penetration test was performed during the observation period. For Type II reports, the test date must fall within the start and end dates of the observation period. A pentest conducted before the observation period started may not be accepted as valid evidence.

Independence of the tester. Auditors prefer — and some require — that penetration testing be performed by a qualified third party independent of the organization. Internal security testing can supplement external testing, but most auditors expect at least one annual test by an external provider. The tester’s qualifications (certifications like OSCP, CREST, or GPEN) add credibility.

Finding severity and resolution. Auditors examine the findings section to understand the risk posture. They look for: the number and severity of findings, whether critical and high findings have been remediated, and evidence that remediation was verified through retesting. A report with unresolved critical findings signals a control weakness. A report showing all critical findings remediated and retested demonstrates an effective vulnerability management program.

Executive summary and methodology. The auditor reviews the executive summary for testing methodology, tools used, and overall assessment. Reports that reference industry-standard methodologies (OWASP Testing Guide, PTES, NIST SP 800-115) are viewed more favorably than reports with no methodological context. The executive summary should clearly state the testing approach, the scope, and a risk-rated summary of findings.

Certain vulnerability categories, when found during a pentest, create significant complications for SOC 2 certification because they indicate fundamental control failures. Here are the findings that cause the most problems:

Broken access control (horizontal or vertical privilege escalation). If User A can access User B’s data, or a standard user can perform admin functions, this directly violates the logical access controls that SOC 2’s Common Criteria require. Auditors treat access control failures as high-severity control deficiencies because they undermine the foundation of your security model. In SaaS environments, cross-tenant access failures are especially damaging because they affect multiple customers simultaneously.

Missing or weak authentication controls. Default credentials, missing MFA on admin accounts, session tokens that don’t expire, and password policies that allow trivial passwords all conflict with SOC 2 criteria around identity and access management. These findings are straightforward to remediate but embarrassing if they appear in a pentest conducted during an audit.

Unencrypted sensitive data. SOC 2’s Confidentiality criterion requires that sensitive data is protected. If the pentest reveals sensitive data transmitted over HTTP instead of HTTPS, stored in plaintext in databases, or exposed in API responses that should be redacted, the auditor will flag these as control failures requiring immediate remediation.

SQL injection or other injection flaws. Injection vulnerabilities indicate insufficient input validation, which relates to both security and processing integrity. A SQL injection finding in a SOC 2 pentest is particularly problematic because it demonstrates that an attacker could potentially access or modify the entire database, affecting data for all tenants.

Missing security headers and outdated components. While these are typically medium or low severity individually, a pentest that reveals a large number of missing security headers, outdated frameworks with known vulnerabilities, and misconfigured security controls creates a cumulative impression of immature security practices. Auditors may not flag these individually but will note a pattern of insufficient security hardening.

A SaaS company we’ll call TeamFlow provides a collaboration platform for professional services firms. They had approximately 200 customer organizations on the platform and were pursuing SOC 2 Type II to unlock enterprise sales. Their first penetration test, conducted in month 3 of their 12-month observation period, revealed several significant findings.

The pentest uncovered two critical and three high-severity vulnerabilities: a cross-tenant data exposure through their file sharing API (any user could access files from other organizations by manipulating the file ID), a privilege escalation that allowed standard users to access admin-only billing endpoints, an insecure direct object reference in the user profile API, a missing rate limit on the authentication endpoint enabling brute-force attacks, and an SSRF vulnerability in their URL preview feature.

TeamFlow’s engineering team prioritized remediation immediately. Within 3 weeks, all critical and high findings were fixed. We conducted a comprehensive retest at week 4 and confirmed all fixes were effective. The updated pentest report included a remediation appendix showing: finding identified → JIRA ticket created → code change deployed → retest verified. The entire process — from initial finding to verified fix — was documented with timestamps.

When the SOC 2 auditor reviewed the evidence, they specifically noted the penetration testing program as a strength. The auditor’s commentary highlighted that TeamFlow had identified vulnerabilities proactively, responded to critical findings within an aggressive timeline, verified remediation through retesting, and documented the entire lifecycle. The SOC 2 Type II report was issued with no exceptions related to security testing.

Use this checklist to ensure your penetration test scope covers everything your SOC 2 auditor will expect:

Web application testing: All customer-facing web application functionality, including authentication, authorization, session management, input validation, and business logic. Test with multiple user roles.

API testing: All APIs consumed by the web application, mobile applications, and third-party integrations. Include BOLA/IDOR testing, rate limiting, authentication bypass, and data exposure testing.

Cloud infrastructure: Review of cloud configuration (AWS, GCP, or Azure) for misconfigurations: publicly accessible storage buckets, overly permissive IAM policies, unencrypted databases, exposed management interfaces.

Multi-tenant isolation (for SaaS): Cross-tenant data access testing, tenant context validation, shared resource isolation. This is critical for SaaS companies and is often the source of the most impactful findings.

Authentication and identity: SSO implementation testing (if applicable), password policy enforcement, MFA bypass testing, session management, and token security.

Data protection: Encryption in transit and at rest verification, sensitive data exposure in API responses, information disclosure in error messages, and data leakage through logs, caches, or exports.

Choosing a provider for SOC 2 pentesting: Ask potential providers these questions: Do you have experience with SOC 2 engagements? Will your report explicitly map findings to Trust Service Criteria? Do you include a remediation status section that is updated after retesting? Can you provide the report in a format my auditor can easily consume? Will you be available to answer auditor questions about your methodology? The best providers for SOC 2 pentesting understand the audit process and design their deliverables to support it. A technically excellent report that does not align with SOC 2 evidence requirements creates extra work for you and your auditor.

Preparing for Your SOC 2 Audit?

We provide SOC 2-aligned penetration testing with reports designed for auditor review. Every engagement includes Trust Service Criteria mapping, a remediation status appendix, and complimentary retesting so you have clean evidence for your audit.