SOC 2 reports have become the default proof point for enterprise security. If you’re selling software to other businesses, you’ll eventually face a vendor questionnaire asking for your SOC 2 report. But here’s what catches many companies off guard: auditors increasingly expect penetration testing as part of the evidence supporting your security controls. Not because the SOC 2 framework explicitly requires it (more on that in a moment), but because it’s one of the few ways to demonstrate that your security controls actually work under adversarial conditions.

The shift is happening because static evidence is cheap and easy to fabricate. You can document policies, screenshot configurations, and produce logs without actually being secure. Penetration testing forces you to prove your defenses work when someone actively tries to bypass them. As the SOC 2 standard has matured, auditors have gotten smarter about distinguishing between “we have security controls documented” and “we have security controls that actually prevent breaches.”

This guide covers what SOC 2 auditors expect from penetration testing, how to scope and time your tests to align with audit periods, and how continuous testing approaches like Praetorian Guard are changing the economics and effectiveness of SOC 2 compliance.

Is Penetration Testing Required for SOC 2?

The short answer: it depends on your auditor and the Trust Services Criteria you’re attesting to. The SOC 2 framework itself doesn’t explicitly mandate penetration testing. Instead, it establishes principles (the Trust Services Criteria) that your organization must meet, and you get to choose how you provide evidence that you meet them.

However, in practice, most auditors will expect penetration testing for the Security category (which is mandatory for all SOC 2 reports). The Common Criteria CC7.1 states that the entity “evaluates security events to determine whether they could or have resulted in a failure of the entity to meet its objectives.” Penetration testing is one of the most direct ways to evaluate whether security controls are effective before an actual breach occurs.

If you’re attesting to the Availability criterion, auditors will almost certainly expect penetration testing focused on denial-of-service scenarios and resilience. For Confidentiality, they’ll want to see testing of access controls and data protection mechanisms. The Processing Integrity and Privacy criteria may also trigger testing expectations depending on the sensitivity of data you handle.

The real driver isn’t the text of the standard but auditor liability. If an auditor issues a clean SOC 2 opinion and your organization gets breached shortly after, questions will be asked about whether the audit was thorough. Penetration testing gives auditors defensible evidence that security controls were tested adversarially. As a result, the absence of penetration testing often leads to audit qualifications or requirements to include it in future periods.

Praetorian Guard addresses this by providing continuous penetration testing throughout the audit period, not just a point-in-time assessment. This gives auditors rolling evidence of control effectiveness and eliminates the risk of significant vulnerabilities emerging between annual tests.

Trust Services Criteria That Rely on Penetration Testing Evidence

The Trust Services Criteria are organized around five categories: Security, Availability, Processing Integrity, Confidentiality, and Privacy (the Security category is mandatory). Within each category, Common Criteria define specific control objectives. Penetration testing provides evidence for several of these.

CC7.1 (Security Event Detection): This criterion requires organizations to detect security events in a timely manner. Penetration testing validates that your monitoring and detection systems actually work. A good pen test will include post-exploitation activity to see if your SIEM, IDS, or EDR tools generate alerts. If an attacker gains initial access but goes undetected for days, that’s evidence your detection controls are insufficient.

CC6.6 (Logical and Physical Access Controls): This addresses restricting access to assets based on business needs. Penetration testing validates that access controls are properly implemented and can’t be bypassed through privilege escalation, credential theft, or lateral movement. External pen tests check perimeter controls, while internal tests validate segmentation and least-privilege enforcement.

CC6.1 (Unauthorized Access Prevention): Closely related to CC6.6, this criterion focuses on preventing unauthorized access. Web application penetration testing, for instance, validates that authentication mechanisms, session management, and authorization logic can’t be bypassed by attackers.

CC7.2 (Security Incident Response): This requires monitoring, detecting, and responding to security incidents. Penetration testing provides a safe way to test incident response procedures. When a pen test is detected, does your security team follow documented runbooks? Do escalation procedures work? How long does containment take?

A1.2 (Environmental Protections for Availability): If you’re attesting to Availability, this criterion addresses protecting against environmental threats. Denial-of-service testing validates that rate limiting, traffic shaping, and capacity planning actually prevent service disruptions. It also tests failover mechanisms and redundancy.

C1.1 (Confidentiality Commitments): For Confidentiality attestations, this criterion requires identifying and maintaining confidential information. Penetration testing validates that confidential data can’t be accessed through SQL injection, broken access controls, API vulnerabilities, or other attack vectors.

Praetorian structures its penetration testing methodology around these criteria. When we conduct assessments for clients preparing for SOC 2 audits, test cases directly map to Trust Services Criteria so auditors can trace findings and remediations back to specific control objectives. This makes the audit process significantly faster and reduces back-and-forth requests for evidence.

What Auditors Expect from a SOC 2 Penetration Test

Auditors reviewing penetration testing evidence care about three things: scope, methodology, and findings management. They need to see that the test covered systems relevant to Trust Services Criteria, followed a credible methodology, and that your organization responded appropriately to findings.

Scope documentation is critical. Your pen test report should clearly define what was tested (IP ranges, applications, APIs, infrastructure) and what was excluded. The scope should align with the boundaries of your SOC 2 environment. If your SOC 2 report covers your production SaaS platform but excludes internal corporate IT, your pen test scope should match. Auditors will flag scope mismatches as an audit qualification.

Methodology credibility matters because penetration testing is an unregulated industry. Anyone can call themselves a penetration tester. Auditors look for evidence that the testing firm follows recognized frameworks like PTES (Penetration Testing Execution Standard), OWASP Testing Guide, or NIST SP 800-115. They want to see that both automated scanning and manual exploitation techniques were used, because automated tools alone miss logic flaws, business logic vulnerabilities, and complex attack chains.

The testing firm’s qualifications matter too. Auditors look for certifications like OSCP, GPEN, or GXPN, and they want to see evidence that testers have relevant experience. A generic vulnerability scan from a compliance mill won’t satisfy rigorous auditors. Praetorian’s penetration testing team includes former red team operators from government agencies and security researchers who discover and publish vulnerabilities in major software platforms. This level of expertise gives auditors confidence that testing was thorough.

Findings management demonstrates security program maturity. Auditors expect to see high and critical findings remediated before the audit opinion is issued. Medium findings should have documented remediation plans with timelines. Low findings can often be accepted as residual risk, but you need documented risk acceptance decisions, ideally signed by management.

Auditors will also look at how quickly you remediated findings. If a pen test identified a critical SQL injection vulnerability in June and it wasn’t fixed until November, that’s a control failure. The CC7.3 criterion requires evaluating and responding to security events in a timely manner. Slow remediation suggests your incident response processes don’t work effectively.

This is where continuous testing models like Guard provide significant advantages. Instead of annual testing that produces a report with 50 findings that all need to be remediated in a panic before the audit, Guard provides rolling discovery and remediation of issues throughout the year. Auditors see evidence of a mature security program that continuously identifies and fixes vulnerabilities rather than a last-minute scramble.

Type I vs. Type II: How Audit Type Affects Testing Requirements

SOC 2 comes in two flavors: Type I and Type II. Type I reports assess whether controls are suitably designed at a specific point in time. Type II reports assess both design and operating effectiveness over a period (typically six or twelve months). The type of report you’re pursuing significantly affects penetration testing expectations.

For Type I reports, a single penetration test conducted shortly before the audit date can suffice. The auditor is evaluating whether your security controls are designed appropriately, not whether they’ve been operating effectively over time. A clean pen test report from the past 30-60 days provides evidence that controls are properly designed and configured.

However, Type I reports are increasingly seen as insufficient by enterprise buyers. They prove you were secure on a specific date, not that you maintain security over time. Most organizations pursuing SOC 2 for the first time start with Type I (because it’s faster and cheaper) but quickly move to Type II when customers demand it.

Type II reports create much higher expectations for penetration testing. Auditors need evidence that security controls operated effectively throughout the audit period. A single pen test, even if conducted midway through the period, only provides evidence for a specific point in time. If the test was in March and the audit period ends in December, what evidence demonstrates controls remained effective for the remaining nine months?

This is where testing frequency becomes critical. Many organizations respond by conducting penetration tests at the beginning and end of the audit period. This provides bookend evidence but still leaves gaps. What if a critical vulnerability was introduced in a May deployment and not discovered until the November retest? For those six months, your security controls were inadequate, which could result in a qualified audit opinion.

Guard solves this problem by providing continuous penetration testing throughout the audit period. Instead of point-in-time snapshots, auditors receive evidence of ongoing security validation. When new assets are deployed, they’re automatically discovered and tested. When vulnerabilities are identified, they’re tracked through remediation. This provides the continuous operating effectiveness evidence that Type II reports require.

Another consideration: major changes during the audit period often trigger requirements for interim testing. If you deploy a new API, redesign your authentication system, or migrate to new infrastructure, auditors may expect penetration testing of those changes before issuing an opinion. Continuous testing eliminates this concern because new systems are tested as part of the ongoing program.

Scope Considerations: What to Include in Your SOC 2 Pen Test

Determining penetration testing scope for SOC 2 compliance requires aligning the test with your System Description. The System Description defines the boundaries of what you’re attesting to, and your pen test scope needs to cover the security-relevant components within those boundaries.

External perimeter testing is almost always required. This covers internet-facing assets like your web application, APIs, authentication endpoints, and any services customers interact with. External tests validate that unauthorized attackers can’t compromise your systems from the internet. For SaaS platforms, this is the primary attack surface customers care about.

Internal network testing depends on your System Description scope. If your SOC 2 environment includes corporate infrastructure (employee laptops, internal tools, on-premise data centers), internal penetration testing validates segmentation and lateral movement controls. Many cloud-native SaaS companies exclude corporate IT from scope, which means internal testing may not be required. However, if developers can access production systems from corporate networks, that trust relationship often needs to be tested.

Cloud infrastructure testing is critical for AWS, Azure, or GCP-hosted applications. This includes testing IAM configurations, S3 bucket permissions, security groups, API authentication, and container orchestration security. Cloud misconfigurations are one of the most common root causes of breaches, and auditors increasingly expect evidence that cloud controls are tested adversarially.

Application-layer testing goes deeper than external perimeter scans. This includes testing business logic vulnerabilities, authorization flaws, API abuse scenarios, and data validation issues that automated scanners miss. For example, can a user access another customer’s data by manipulating API parameters? Can workflows be bypassed to skip payment requirements? These issues require manual testing by experienced penetration testers.

Third-party integrations often create security gaps. If your application integrates with Stripe for payments, Auth0 for authentication, or Twilio for communications, those integration points should be tested. Can API keys be exfiltrated? Are OAuth flows implemented correctly? Do webhooks validate sender authenticity?

One mistake organizations make is testing too much. If you include systems outside your SOC 2 scope in the pen test, you may discover vulnerabilities in systems the auditor doesn’t care about, which can create confusion. Worse, if those out-of-scope vulnerabilities aren’t remediated, auditors may question whether you take security seriously.

Praetorian Guard handles scope management automatically through asset discovery and attack surface mapping. When you define your SOC 2 environment boundaries, Guard continuously maps all assets within scope and tests them as part of the managed service. This eliminates scope creep and ensures testing aligns with audit requirements.

Timing and Frequency: When to Conduct Penetration Tests for SOC 2

Timing your penetration test relative to your SOC 2 audit is more strategic than most organizations realize. The goal is to provide fresh evidence to auditors while leaving enough time to remediate critical findings before the audit opinion is issued.

For Type I audits, schedule penetration testing 30-60 days before your anticipated audit date. This gives you time to remediate critical findings and re-test if necessary, while keeping evidence fresh. If you test six months before the audit, auditors may question whether controls remained effective in the interim.

For Type II audits with a 12-month period, best practice is testing at three points: beginning, middle, and end of the period. This provides evidence of continuous control effectiveness and catches issues introduced by deployments or infrastructure changes. However, this approach is expensive and operationally disruptive.

Many organizations compromise by testing at the beginning and end of the audit period, which provides bookend evidence but leaves a gap. If a critical vulnerability existed for months in the middle of the period and wasn’t discovered until the final test, auditors may issue a qualified opinion or require interim testing for future periods.

Continuous penetration testing eliminates these timing concerns entirely. Guard provides ongoing testing throughout the audit period, which means auditors can pull evidence from any point in time. When new vulnerabilities are discovered, they’re tracked from identification through remediation, giving auditors a complete chain of evidence.

Another timing consideration: major releases. If you deploy significant new features or infrastructure changes during the audit period, those changes should be tested before the audit. Auditors may specifically ask whether penetration testing covered systems deployed during the period. If your annual pen test happened in January but you launched a new API in October, that API hasn’t been tested, which creates an evidence gap.

Praetorian recommends aligning penetration testing with your release cycle rather than your audit cycle. If you deploy monthly, quarterly testing provides reasonable coverage. If you deploy continuously, traditional penetration testing can’t keep pace, which is why continuous testing models exist.

One final timing consideration: auditor scheduling. Audit firms are busiest in Q4 and Q1 when calendar-year companies close their books. If your SOC 2 audit is scheduled for December, you want penetration testing completed by October at the latest to give yourself remediation time. Missing this window often means delaying the audit or accepting qualifications.

Reporting Requirements: What Auditors Need in Your Pen Test Report

SOC 2 auditors don’t just want to see that you conducted penetration testing. They need specific documentation to validate that testing was rigorous and findings were managed appropriately. The penetration test report is the primary evidence artifact, and it needs to include several key components.

Executive summary: Auditors often start here to understand the overall security posture. This section should summarize scope, methodology, key findings, and remediation status. It should be understandable by non-technical auditors while providing enough detail to demonstrate thoroughness.

Scope documentation: This must clearly define what was tested (specific IP ranges, URLs, applications, APIs) and what was excluded. Scope should align with your SOC 2 System Description boundaries. Auditors will cross-reference scope against your system inventory to ensure coverage is adequate.

Methodology description: This should reference industry frameworks like OWASP Testing Guide, PTES, or NIST SP 800-115. Auditors want to see that both automated and manual testing techniques were used. The report should describe reconnaissance, vulnerability identification, exploitation attempts, and post-exploitation activities (where applicable).

Findings detail: Each vulnerability needs severity rating, technical description, proof-of-concept, affected systems, and remediation recommendations. Severity ratings should follow a consistent framework (CVSS, DREAD, or custom risk matrix). Findings need enough detail for developers to reproduce and fix issues, but not so much that the report becomes a hacker’s playbook if it’s compromised.

Evidence artifacts: Screenshots, command output, HTTP requests/responses, and other evidence prove that vulnerabilities are real and reproducible. Auditors may spot-check evidence to verify testing actually occurred. Generic vulnerability descriptions without supporting evidence raise red flags.

Remediation validation: If you fixed vulnerabilities and had them re-tested, the report should document validation testing. This shows auditors that findings weren’t just acknowledged but actually resolved. Re-test results are some of the strongest evidence of control effectiveness.

Tester qualifications: Auditors want to see that penetration testers have relevant certifications (OSCP, GPEN, GXPN) and experience. The report should include brief bios or credential summaries. This establishes credibility and gives auditors confidence that testing was conducted by competent professionals.

One challenge with traditional penetration testing: reports are static documents that quickly become outdated. If you remediate vulnerabilities after the report is issued, you need supplemental documentation proving remediation. If new vulnerabilities are discovered between annual tests, they’re not reflected anywhere.

Guard provides auditors with a live portal showing current security posture, historical vulnerability trends, and remediation timelines. Instead of shuffling PDF reports and spreadsheets tracking remediation, auditors can see real-time evidence of security control effectiveness. This dramatically reduces audit preparation overhead and speeds up the audit process.

Common Gaps in SOC 2 Penetration Testing Programs

Even organizations that conduct penetration testing often make mistakes that create audit issues. These gaps are common and easily avoidable with better planning.

Insufficient scope: Testing only the main application while ignoring APIs, mobile apps, or administrative interfaces creates blind spots. Attackers don’t limit themselves to the primary user interface. If your SOC 2 environment includes multiple components, they all need to be tested. We regularly find that the worst vulnerabilities exist in admin panels, API endpoints, or internal tools that weren’t included in the initial test scope.

Over-reliance on automated scanning: Vulnerability scanners are useful for finding common issues like missing patches or SSL misconfigurations, but they miss business logic flaws, authorization issues, and complex attack chains. A “penetration test” that’s just an Nessus scan rebranded is not credible to experienced auditors. Manual testing by skilled penetration testers is required to satisfy SOC 2 expectations.

Poor findings management: Discovering vulnerabilities but not tracking them to remediation creates compliance gaps. Auditors expect to see ticketing system records, re-test validation, and timeline documentation. Organizations often lose track of medium and low findings, which can accumulate into systemic security debt. Using a unified platform like Guard ensures findings are tracked automatically from discovery through remediation.

Scope misalignment with System Description: If your SOC 2 report covers specific applications or infrastructure, but your pen test includes out-of-scope systems, it creates confusion and potential audit issues. Conversely, if the pen test doesn’t cover in-scope systems, that’s an evidence gap. Scope alignment requires coordination between your auditor, security team, and penetration testing provider.

Inadequate testing frequency for Type II: A single annual pen test doesn’t provide evidence of control effectiveness over a 12-month period. Auditors may accept this for the first Type II audit, but subsequent years often require more frequent testing. Organizations are often surprised by this escalating expectation and find themselves scrambling to budget for additional tests.

Lack of post-remediation validation: Fixing a vulnerability doesn’t mean it’s fixed correctly. We frequently find that initial remediation attempts are incomplete or create new issues. Re-testing after remediation provides evidence that fixes actually worked. Auditors look for this validation, and its absence can trigger qualification recommendations.

Testing too early or too late: Testing six months before the audit leaves a long gap where new vulnerabilities may have been introduced. Testing two weeks before the audit leaves no time for remediation. The Goldilocks zone is 4-8 weeks before audit completion for traditional annual testing, but continuous testing eliminates this timing concern entirely.

Ignoring cloud infrastructure: Many application pen tests focus on the web app and APIs but don’t assess underlying cloud infrastructure configurations. S3 buckets, IAM roles, security groups, and API Gateway configurations are common attack vectors that need testing. Cloud-native applications require cloud-native penetration testing methodology.

Praetorian’s approach addresses these gaps systematically. Guard combines attack surface management to ensure complete scope coverage, continuous testing to eliminate timing gaps, automated findings tracking, and expert validation to catch issues scanners miss. This turns penetration testing from an annual compliance checkbox into an ongoing security capability.

Continuous Testing as a Competitive Advantage for SOC 2

Traditional annual penetration testing is becoming obsolete for fast-moving software companies. If you deploy code daily or weekly, a once-per-year security assessment provides almost no protection and creates compliance headaches when auditors ask about control effectiveness between test dates.

Continuous penetration testing changes the economics and effectiveness of security validation. Instead of a discrete project that produces a static report, it’s an ongoing managed service that provides real-time security posture visibility. For SOC 2 purposes, this creates several advantages.

Evidence throughout the audit period: Type II audits require demonstrating control effectiveness over time. Continuous testing provides rolling evidence instead of point-in-time snapshots. Auditors can see that security validation happened consistently throughout the period, not just when the annual pen test was scheduled.

Faster time to detection and remediation: Instead of discovering vulnerabilities months after they’re introduced (when the annual pen test happens), continuous testing identifies issues within days of deployment. This dramatically reduces exposure windows and provides auditors with evidence of rapid response capabilities.

Better remediation metrics: Continuous testing generates time-to-remediation data that auditors love. You can show mean time to detect (MTTD), mean time to remediate (MTTR), and trends over time. This demonstrates security program maturity far more effectively than a static pen test report from six months ago.

Reduced audit preparation overhead: Instead of frantically gathering pen test reports, remediation tickets, and re-test results when the auditor requests evidence, everything is tracked in a single platform. Guard’s audit evidence portal gives auditors self-service access to current and historical security data, which speeds up the audit process and reduces information requests.

Competitive differentiation: As SOC 2 becomes table stakes, continuous security testing becomes a differentiator. Enterprise buyers increasingly ask about security testing frequency and methodology. Being able to say “we conduct continuous penetration testing with quarterly auditor reviews” is a stronger signal than “we do annual pen tests.”

Cost efficiency at scale: For organizations with dozens or hundreds of applications and APIs, annual penetration testing becomes prohibitively expensive. Testing each asset annually requires massive security budgets. Continuous testing models like Guard use automation and intelligent prioritization to provide broader coverage at lower cost.

The shift from periodic to continuous testing mirrors the broader DevOps evolution. Just as continuous integration replaced quarterly release cycles, continuous security testing is replacing annual compliance-driven assessments. Organizations that make this shift are better positioned for SOC 2 compliance, have stronger security postures, and can move faster without accumulating security debt.

FAQ