SOC 2 Penetration Testing Requirements: What Auditors Actually Want

You're deep into your SOC 2 journey. Spreadsheets are full, policies are written, and then someone on the team asks the question that derails the entire timeline: "Do we actually need a penetration test for this?"

It's a fair question, and one with a surprisingly nuanced answer. The short version: SOC 2 doesn't technically require a pentest. The longer version: try showing up to an audit without one and see what happens.

The stakes are real. Verizon's 2025 Data Breach Investigations Report found that vulnerability exploitation as an initial access vector rose 34% year over year, now accounting for 20% of all confirmed breaches. The report also found that only about 54% of edge device vulnerabilities were fully remediated throughout the year, with a median remediation time of 32 days. The threat landscape is not waiting for your annual audit cycle.

This guide breaks down exactly what auditors are looking for when it comes to penetration testing, which Trust Services Criteria are involved, how to scope and time your engagement, what your report needs to include, and where most companies quietly stumble.

---

Is Penetration Testing Actually Required for SOC 2 Compliance?

This is the question that launches a thousand forum threads, and a fair amount of bad advice. The direct answer is no. SOC 2 reports are based on the Trust Services Criteria (TSC), which focus on security, availability, processing integrity, confidentiality, and privacy. The standard does not mandate a specific list of technical assessments for compliance, including penetration tests.

The framework is intentionally descriptive rather than prescriptive. SOC 2 compliance, governed by the AICPA, does not explicitly mandate any control activities. Instead, it requires organizations to design and implement controls to mitigate risks based on the Trust Services Criteria.

But here's where the nuance matters. While the standard doesn't mandate pentesting by name, it absolutely requires you to prove that your security controls are present and functioning under real-world conditions. The AICPA's official Trust Services Criteria document (TSP Section 100, revised in 2022) includes a point of focus under CC4.1 that explicitly names penetration testing. The guidance states that management should consider different types of ongoing and separate evaluations, "including penetration testing, independent certification made against established specifications (for example, ISO certifications), and internal audit assessments." You can review the full criteria language in the AICPA's published TSP Section 100.

So while you could technically satisfy CC4.1 through other means, auditors widely view penetration testing as the most credible and efficient way to demonstrate that your defenses hold up when tested. In a detailed analysis, Drata's GRC team frames the decision through three lenses: is it a preference, a tradition, or a requirement? Pentesting may not technically be the last one, but it is firmly the first two, and that distinction carries real weight in practice. If you choose not to conduct penetration tests, auditors will likely scrutinize your decision-making process and assess whether your alternative evaluations adequately mitigate risks.

The market data reinforces the urgency. According to A-LIGN's 2025 Compliance Benchmark Report, SOC 2 has shifted from a competitive differentiator to a baseline expectation, with 92% of organizations now conducting two or more audits annually. And according to Vanta's State of Trust Report 2024, nearly two-thirds (65%) of organizations say that customers, investors, and suppliers require more demonstration of compliance than before.

What Trust Services Criteria Does Penetration Testing Actually Map To?

One of the reasons penetration testing carries so much weight in SOC 2 audits is that it doesn't map to just one criterion. It provides evidence across several. Understanding this mapping helps you frame your pentest not as an isolated activity, but as a foundational piece of your broader control narrative.

CC4.1 (Monitoring Activities) is the most commonly cited criterion. Rooted in COSO Principle 16, it requires organizations to select, develop, and perform evaluations that confirm internal controls are present and functioning. As noted in the AICPA's Trust Services Criteria, the CC4.1 point of focus states that management should use a variety of different types of ongoing and separate evaluations, including penetration testing. A pentest goes beyond reviewing whether a policy exists. It actively attempts to exploit weaknesses, providing a far more realistic picture of control effectiveness.

CC7.1 (System Operations) requires the use of detection and monitoring procedures to identify vulnerabilities. The criterion states that the entity must use procedures to identify changes to configurations that result in the introduction of new vulnerabilities and susceptibilities to newly discovered vulnerabilities. It also includes a specific point of focus around vulnerability scanning, noting that the entity should conduct scans to identify potential vulnerabilities or misconfigurations on a periodic basis and after significant changes. According to Blaze InfoSec's analysis of SOC 2 requirements, penetration testing is frequently used to satisfy both AICPA criteria CC4.1 and CC7.1.

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

CC7.2 through CC7.4 cover the detection, evaluation, response, and remediation cycle for security events. 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. As TechPause's SOC 2 analysis explains, this remediation loop directly demonstrates CC7.3 (event evaluation) and CC7.4 (response) in action.

A1.2 (Availability) addresses system resilience and environmental protections. Penetration testers employ techniques to uncover weaknesses that traditional scans might miss, and those vulnerabilities could disrupt system availability if exploited by a real attacker.

C1.1 (Confidentiality) relates to protecting confidential information. As Astra Security notes, a pentest for SOC 2 compliance can simulate how an attacker might gain access to sensitive data, allowing your company and auditors to assess the risk and impact of a successful attack with respect to sensitive customer data covered under the Confidentiality principle.

The takeaway: penetration testing provides a single engagement that generates evidence across five or more Trust Services Criteria simultaneously. Few other security activities offer that kind of compliance leverage.

Do Auditors Really Expect a Pentest Even Though It's Not Mandatory?

Yes, and the expectation has only grown stronger. While the AICPA doesn't mandate specific control activities, auditors exercise professional judgment, and in the current threat landscape, that judgment increasingly points toward penetration testing as baseline evidence.

As Budget Security's compliance guide puts it, while SOC 2 does not explicitly require penetration testing, auditors expect evidence that you proactively identify and address security vulnerabilities. A penetration test is the most effective way to demonstrate this, and most auditors will flag its absence as a gap in your security controls.

The customer-side pressure is equally acute. According to Bastion's analysis of SOC 2 pentest requirements, SOC 2 auditors don't require penetration testing, but your customers do. For B2B SaaS companies pursuing enterprise deals, pentests are effectively mandatory because buyers expect and often require them. The dynamic plays out in a predictable pattern: when a CISO at a prospective customer receives your SOC 2 report, they review the controls and auditor's opinion, but that's only part of the evaluation. The next request is almost always to see the penetration test report. Many enterprise security questionnaires explicitly require evidence of annual penetration testing, and for most enterprise buyers, it's not optional in their evaluation criteria.

The consequences of skipping are tangible. Drata highlights the risk clearly: prospects with strict due diligence requirements may demand an ad-hoc penetration test under a tight deadline as a prerequisite to close a deal. In competitive situations, prospects may select a different vendor who used their security controls, including periodic penetration tests, as a differentiator.

This tracks with broader industry trends. Vanta's State of Trust Report 2024, based on a survey of 2,500 business and IT leaders, found that 65% of organizations say customers, investors, and suppliers require more demonstration of compliance than before. A majority (55%) say the security risks for their business have never been higher.

What Should the Scope of a SOC 2 Penetration Test Include?

Scope is where many organizations quietly create problems for themselves. These are problems that don't surface until the auditor is reviewing evidence and asking uncomfortable questions.

The fundamental rule: your pentest scope should mirror your SOC 2 system boundary. As TechPause explains, 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 test that only covers the web application while your SOC 2 scope includes the API and infrastructure creates an evidence gap that auditors will flag.

For most SaaS companies, a comprehensive scope includes external network infrastructure, the web application itself, all API endpoints, cloud environment configurations, and authentication and authorization mechanisms across all layers. If your application has an API (and nearly every modern SaaS product does), it must be explicitly included. API-specific testing covers token handling, rate limiting, input validation, and authorization checks at the endpoint level.

One particularly damaging scoping mistake occurs when a company's documentation doesn't match the evidence. As Asteros describes in its analysis of common pentest pitfalls, policies may state that the organization undergoes web application penetration testing, but the actual work delivered is only an external network scan of the application infrastructure. While an auditor will recognize the value of a network-level test, they will also recognize that it completely ignores the application layer. If your documentation promises one thing and you deliver another, the auditor will call it out.

As for methodology, Bastion recommends grey box testing for most SaaS startups. It provides thorough coverage at a reasonable cost by giving testers partial access such as user credentials and basic architecture documentation while still testing defenses. This approach catches both external and internal vulnerabilities without the high cost of full black box reconnaissance.

When Should You Schedule Your Penetration Test Relative to the Audit?

Timing is one of the most common, and most avoidable, reasons organizations run into trouble. As Q-Sec's compliance guide notes, for SOC 2 Type II audits, your most recent penetration test should fall within the audit observation period (or shortly before it). A test from eighteen months ago doesn't demonstrate that your controls were effective during the window being evaluated.

Best practice is to conduct a penetration test before your SOC 2 Type II observation period begins, remediate critical findings, and include the test evidence in your control documentation. This gives auditors clean evidence of both testing and remediation.

Netragard's SOC 2 guidance reinforces that industry best practice calls for penetration testing at minimum annually, with additional testing following significant system changes. Organizations making substantial infrastructure changes, like migrating to new cloud platforms or deploying major application updates, should conduct targeted testing following those changes rather than waiting for the annual assessment.

The remediation timeline matters more than many teams realize. According to Asteros' analysis of audit pitfalls, after reviewing a penetration test report, auditors rarely start with the vulnerability list itself. They look at how the organization responded. Long remediation windows for serious findings often suggest that severity ratings are being applied mechanically rather than strategically. Allowing 60 or 90 days to fix a critical vulnerability raises immediate questions about whether the organization takes risk management seriously.

Budget adequate time between testing completion and audit fieldwork. Rushing to fix findings the week before your auditor arrives is a recipe for incomplete remediation and missing documentation.

What Does an Audit-Ready Penetration Test Report Actually Look Like?

Not all pentest reports are created equal, and auditors can tell the difference immediately. As TechPause emphasizes, 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 automated scan output, not a penetration test.

According to Astra Security's breakdown of auditor expectations, auditors expect comprehensive penetration test reports that include executive summaries, detailed vulnerability findings with CVSS scores, evidence of exploitation, and prioritized remediation recommendations.

Critically, audit-quality penetration test reports contextualize findings in terms of business impact, not just technical severity. Identifying a SQL injection in a login form is a technical finding. Explaining that it could allow an attacker to exfiltrate the entire customer database is the kind of business-impact framing that auditors find meaningful.

The remediation evidence component is what separates a compliance-ready report from a standard security deliverable. Netragard notes that auditors expect clear documentation showing that identified findings were remediated and that fixes were effective. Penetration testing vendors typically perform follow-up testing focused on re-exploiting previously reported vulnerabilities. If those weaknesses can no longer be exploited, they're marked as resolved, and your vendor delivers a remediation report reflecting verified fixes.

A critical point from TechPause's analysis: findings without corresponding remediation records are worse than no findings at all. They demonstrate that the organization identified risks and failed to address them.

Can Vulnerability Scanning Replace Penetration Testing for SOC 2?

No, and this is a hill that auditors are increasingly willing to die on. While the two activities are complementary, they are not interchangeable.

As DeepStrike's SOC 2 guide explains, automated scans are useful for finding known issues quickly, but a human-led pentest is needed to actually exploit vulnerabilities and prove how an attacker could break in. The distinction matters: scanners identify potential issues (often with significant false positive rates), while penetration testers confirm what's actually exploitable and chain multiple issues together to demonstrate real-world impact.

Netragard's analysis digs into why automated tools fall short as standalone audit evidence. Automated scanners identify some known vulnerabilities but cannot evaluate business logic flaws, chained attack scenarios, or complex authorization bypass techniques that manual testing uncovers. They also generate high rates of false positives and false negatives that degrade report accuracy. From an auditor's perspective, scanner-heavy reports lack the contextual analysis needed to understand which findings pose genuine risk to systems within your SOC 2 scope.

CYBRI's vulnerability management guide reinforces this point: scans demonstrate ongoing monitoring (breadth), while pentests validate the strength of your defenses (depth). To satisfy SOC 2 auditors, your vulnerability management program must combine both.

The right approach uses automated scans for breadth and continuous coverage between tests, with periodic manual penetration testing for deeper validation. Most auditors expect vulnerability scanning at least quarterly, with annual manual penetration testing providing the validation layer.

The volume of new vulnerabilities makes this dual approach essential. According to NIST's March 2025 update, CVE submissions to the National Vulnerability Database increased 32% in 2024, and that prior processing rate is no longer sufficient to keep up with incoming submissions. Verizon's DBIR analysis, as reported by Infosecurity Magazine, corroborates this: NIST registered roughly 40,000 CVEs in 2024 compared to 28,000 in 2023. The attack surface is growing faster than any single assessment method can address.

What Are the Most Common Pentest Mistakes That Lead to Audit Findings?

Understanding where other organizations have stumbled helps you avoid the same traps. As Asteros writes, most SOC 2 audit friction does not come from technical issues or catastrophic security failures. It usually comes from a breakdown between what a company says and what the evidence shows.

Misalignment between policy and evidence. This is the most common issue. Policies may state that the organization undergoes web application penetration testing, but the actual work delivered is only an external network scan. If your documentation commits to a specific type of testing, the evidence must match exactly.

Unrealistic remediation SLAs. Asteros' analysis explains that many companies define remediation SLAs that feel reasonable internally but do not reflect a risk-based view of security. A common example is allowing 45, 60, or even 90 days to remediate a high or critical vulnerability, a timeline that raises immediate questions among auditors. SOC 2 is grounded in risk management, and remediation windows must be proportional to actual severity.

Missing retest evidence. Netragard's guidance stresses that auditors expect clear documentation showing findings were remediated and that fixes were effective. A pentest report with open findings and no follow-up documentation is a red flag that can result in qualified opinions or noted exceptions.

Testing outside the audit window. For Type II audits covering a twelve-month observation period, a penetration test performed outside that window has limited evidentiary value.

Relying on bargain-basement testing. According to Blaze InfoSec's buyer's guide, beware of providers offering "express" penetration tests lasting one to three days, as these assessments likely rely on automated scanners or basic checklists. In their experience, a penetration test for SOC 2 that takes less than 40 hours to complete for a small to medium-sized scope may not provide the necessary level of scrutiny.

How Much Does SOC 2 Penetration Testing Typically Cost?

Cost varies significantly based on scope, system complexity, and provider methodology. Understanding the range helps you budget appropriately and recognize when a quote is suspiciously low.

According to Blaze InfoSec, the average estimated price for a SOC 2 pentest conducted by a credible and accredited cybersecurity firm ranges between $5,000 and $25,000, depending on scope and complexity. Reputable penetration test providers often charge between $200 and $300 per hour.

For a typical SaaS application, Bastion estimates $10,000 to $30,000 for a thorough grey box assessment. Simpler applications with limited scope may cost less, while complex multi-tenant platforms may cost more.

Be cautious of significantly lower prices. As Blaze InfoSec warns, providers with rock-bottom rates may rely heavily on automated scanners or employ unqualified pentesters. While such low-quality pentest reports might appease an auditor, they can create a false sense of security and leave systems vulnerable due to superficial evaluations.

When evaluating providers, look beyond technical capability. The provider should understand what auditors need from the deliverables, be experienced in mapping findings to Trust Services Criteria, and produce reports with executive summaries, methodology documentation, and remediation tracking.

For context on overall audit investment, A-LIGN's 2024 Compliance Benchmark Report found that 69% of respondents deem compliance report quality "extremely important," and 38% of organizations have had a report rejected by a vendor or prospect. A well-scoped pentest in the $10,000 to $25,000 range generates some of the highest-impact evidence in your compliance package.

How Can MindFort Help You Stay Audit-Ready Year-Round?

The traditional model of annual penetration testing creates an uncomfortable gap that every section of this guide has pointed to: for 364 days between tests, you're largely blind to new vulnerabilities introduced by code deployments, configuration changes, and emerging threats. You get a snapshot once a year and hope nothing critical ships in between.

That gap is increasingly hard to defend. Auditors expect continuous monitoring evidence under CC7.1. Vulnerability exploitation as a breach vector grew 34% year over year. The 2025 DBIR analyzed over 22,000 security incidents and 12,195 confirmed data breaches, a record-breaking dataset that underscores how fast the threat landscape is evolving. Annual testing alone cannot keep pace.

This is the problem MindFort was built to solve. MindFort is an enterprise cybersecurity platform that uses AI agents to continuously test web applications for complex vulnerabilities, finding, validating, triaging, and patching them at machine speed and scale. MindFort's autonomous AI agents use the same principles as human penetration testers to understand their target and identify the best ways to exploit it, but they operate around the clock without the scheduling delays, scoping overhead, and high costs of traditional engagements.

For teams preparing for or maintaining SOC 2 compliance, MindFort directly addresses the core challenges this guide has outlined:

Audit-ready reporting on demand. MindFort automates compliance reporting by generating high-quality penetration test documentation: the exact deliverables auditors expect, including findings, severity ratings, and remediation tracking.

Continuous coverage, not annual snapshots. MindFort's agents plug into the tools your team already uses. They trigger security scans on every push or deploy, file findings with full context, and automatically re-test on fix. This builds the ongoing evidence trail that CC7.1 demands.

Compressed remediation cycles. MindFort's AI agents can patch vulnerabilities directly in the application codebase, dramatically reducing manual remediation time and addressing the exact remediation timeline concerns that auditors scrutinize.

Depth beyond scanning. The platform discovers and validates vulnerabilities including those listed in the OWASP Top 10, scores and triages findings by prioritizing critical risks, and incorporates the latest threat intelligence. This provides the manual-grade depth that auditors require while operating at the speed of continuous deployment.

Instead of scrambling to schedule a pentest before your audit window, you walk into every audit with months of documented, ongoing security validation already in hand. That's the difference between checking a box and telling the security maturity story that auditors, and your customers, actually want to hear.

Start continuous security testing with MindFort →