SOC 2 Penetration Testing Requirements: Is a Pen Test Required?

Quick answer: SOC 2 does not contain a sentence that says "you must run a penetration test." But the Trust Services Criteria require you to detect vulnerabilities and evaluate your controls, and most auditors and customers treat an annual third-party penetration test as the expected evidence. In practice, if you are pursuing SOC 2 Type 2, plan on having one.

One of the most common questions from SaaS founders and security leads preparing for an audit is simple: "Does SOC 2 require a pen test?" The honest answer is that the framework is flexible, but the audit reality is not. If a customer has asked for your report, or an auditor is about to review your controls, a penetration test is almost always part of the evidence you will be asked for.

This guide explains the SOC 2 penetration testing requirements in practical terms: what the criteria actually say, why auditors still ask for a test, how timing works for Type 1 and Type 2, what to scope and what evidence to keep. If you want help with the testing itself, see Privaxi's SOC 2 penetration testing service.

Does SOC 2 Require Penetration Testing?

Strictly speaking, no. SOC 2 is built on the AICPA's Trust Services Criteria, and those criteria describe objectives rather than prescribing specific technical activities. Unlike PCI DSS, which names penetration testing and its frequency, SOC 2 leaves the choice of controls to the organization, as long as those controls meet the criteria.

That flexibility is why you will see two answers online. The framework text does not mandate a pen test. Your auditor, however, has to be satisfied that your controls are operating effectively, and a penetration test is the most widely accepted way to show that you test your defenses. Many enterprise customers also write an annual pen test into their security questionnaires and contracts, which turns an optional control into a commercial requirement.

Which SOC 2 Criteria Relate to Penetration Testing?

Two Common Criteria are most often cited when auditors ask for testing evidence.

CC7.1: detection and monitoring of vulnerabilities

SOC 2 CC7.1 expects the organization to use detection and monitoring procedures to identify changes to configurations that introduce new vulnerabilities and susceptibilities to newly discovered vulnerabilities. Vulnerability scanning is the baseline control here. A penetration test supports it by validating which vulnerabilities are actually exploitable and which configurations an attacker could abuse.

CC4.1: ongoing and separate evaluations

CC4.1 requires the organization to select, develop and perform ongoing or separate evaluations to confirm that controls are present and functioning. An independent penetration test is a textbook "separate evaluation" of your security controls, which is why auditors link the two.

Related criteria, including risk assessment (CC3) and change management (CC8), also benefit from test results: a pen test report feeds your risk register, and testing after major changes shows that change management is working.

Why Auditors and Customers Still Expect a Pen Test

• It is independent evidence. A third-party report is stronger than an internal assertion that controls work.
• It maps cleanly to the criteria. A single report supports vulnerability management, risk assessment and monitoring.
• It answers customer questionnaires. Procurement teams routinely ask, "When was your last penetration test, and who performed it?"
• It reduces audit friction. Auditors who see a recent report with remediation evidence ask fewer follow-up questions.

In short, the SOC 2 pen test requirements you face are set by your auditor's expectations and your customers' contracts, not by a line in the criteria. Treat them as real requirements.

SOC 2 Type 1 vs Type 2: When Should You Test?

Timing depends on the type of report you are pursuing.

For SOC 2 Type 2 penetration testing, schedule the test early in the observation window. That leaves room to fix issues, retest and still have the full evidence trail inside the period. Waiting until the final weeks is the single most common reason teams are forced to explain findings that are still open.

What Should a SOC 2 Penetration Test Cover?

Your scope should reflect the systems that are in your SOC 2 boundary, meaning the production environment and supporting infrastructure that deliver your service and handle customer data. For most SaaS companies that includes:

• The customer-facing web application, including authenticated and role-based testing.
• APIs used by your product, partners and mobile apps.
• External network infrastructure, such as public IP ranges, VPN and remote access.
• Cloud infrastructure and configuration, including identity and access management and storage exposure.
• Internal network testing if corporate or production networks are in scope.

Your trust services categories matter too. If you include Confidentiality or Privacy in your report, testing should look specifically at how customer data is protected and segregated, particularly in multi-tenant applications. For guidance on defining boundaries, see our guide to penetration testing scope.

What Evidence Do SOC 2 Auditors Want to See?

1. A final penetration test report from an independent tester, with date, scope and methodology.
2. A description of the testing approach and the standards followed, such as OWASP and NIST SP 800-115.
3. A findings log showing severity, owner and status for each issue.
4. Remediation evidence such as pull requests, tickets, patch records or configuration changes.
5. A retest report or attestation confirming that critical and high findings are resolved.
6. A policy or procedure that states how often testing is performed and who reviews the results.

Teams that keep this evidence together as they go find audit windows far less stressful. A short summary letter from the tester that you can share with customers is also useful, so you are not circulating a full technical report in every sales cycle.

How Often Should You Perform SOC 2 Penetration Testing?

The common standard is at least once a year, plus after significant changes to the application or infrastructure, such as a major release, a cloud migration or a new authentication flow. Annual testing aligns neatly with annual SOC 2 reporting cycles.

Some organizations add more frequent external testing between annual tests. A subscription approach such as penetration testing as a service re-tests the external perimeter on a regular schedule, which helps when releases are frequent and an annual snapshot goes stale quickly. It supplements, rather than replaces, a scoped annual test for the application itself, and you should confirm with your auditor how they view it.

SOC 2 Penetration Testing for SaaS Companies

SaaS companies are the most frequent buyers of SOC 2 reports, and their risk profile shapes what a good test looks like. SOC 2 for SaaS companies is usually about protecting customer data inside a shared platform, so testers should concentrate on the places where one customer's data could leak to another or where an attacker could escalate privileges.

• Tenant isolation. Can a user in one account read or modify another account's data by changing an identifier in a request?
• Authentication and session handling. Password reset, MFA enrollment, single sign-on and token expiry are common weak points.
• Authorization in APIs. Broken object-level and function-level authorization remain among the most common API flaws.
• Admin and support tooling. Internal consoles, impersonation features and back-office tools often have weaker controls than the public app.
• Cloud configuration. Over-permissive roles, public storage buckets and exposed secrets in repositories or build pipelines.
• Third-party integrations. Webhooks, OAuth apps and customer-facing integrations that extend your attack surface.

Because most SaaS products ship continuously, many teams also run recurring external tests between annual engagements so that a new subdomain or exposed service does not sit unnoticed for months.

What Does a SOC 2 Penetration Test Report Contain?

A report that works as audit evidence is more than a list of vulnerabilities. Look for these sections:

• Executive summary. A plain-language view of overall risk that leadership and customers can read.
• Scope and methodology. Which systems were tested, from what vantage point, over what dates, and which standards (such as OWASP and NIST SP 800-115) were followed.
• Findings with severity ratings. Each issue should include a description, affected asset, evidence, business impact and a risk rating.
• Exploit narrative. Where findings were chained together, the report should show the attack path.
• Remediation guidance. Specific, prioritized steps an engineer can act on.
• Retest results. A section or addendum showing which issues were verified as fixed.

Ask your provider whether it can also supply a shorter summary letter for customers. Sharing a summary rather than the full report keeps sensitive technical details out of the sales cycle while still answering the questionnaire.

SOC 2 Pen Test Readiness Checklist

1. Confirm your system boundary and trust services categories with your auditor.
2. Inventory in-scope assets: production domains, IP ranges, applications, APIs and cloud accounts.
3. Set the test window early in the observation period, and avoid freezing releases right before it.
4. Prepare test accounts for each user role so testers can check authorization properly.
5. Agree the rules of engagement, including contacts, safe testing windows and escalation paths.
6. Assign remediation owners and a target timeline for critical and high findings.
7. Schedule the retest before the observation period ends and store the evidence together.

Common Mistakes With SOC 2 Penetration Testing

• Treating a vulnerability scan as a pen test. Auditors can tell the difference. Our guide to penetration testing services explains how they differ.
• Scoping too narrowly. If the report excludes a system inside your SOC 2 boundary, you will be asked why.
• Skipping the retest. Open critical findings with no verification are the fastest way to draw auditor questions.
• Using an unqualified or non-independent tester. The tester should not be the team that built the system.
• Testing too late in the period. A report with no time left to remediate proves little.

Choosing a Provider for SOC 2 Penetration Testing

Choose a firm that understands audits as well as exploits. Ask for a sample report, confirm that retesting is included, and check that the findings are mapped to the criteria your auditor will review. Our checklist for choosing a penetration testing company covers the questions to ask, and how much penetration testing costs explains why quotes differ.

If you are still building the program, Privaxi's SOC 2 compliance services support readiness, evidence collection and the audit itself, and our article on why enterprise deals now depend on a SOC 2 report shows why the investment pays off.

Frequently Asked Questions

penetration test required for SOC 2?

The SOC 2 criteria do not explicitly require one, but auditors and customers commonly expect an annual independent penetration test as evidence of vulnerability management and control evaluation. For SOC 2 Type 2, you should plan to have one.

Which SOC 2 criteria relate to penetration testing?

CC7.1 covers detection and monitoring of vulnerabilities and CC4.1 covers ongoing and separate evaluations of controls. A penetration test supports both, and also feeds risk assessment under CC3 and change management under CC8.

When should the pen test happen in a SOC 2 Type 2 audit?

Early in the observation period, so that findings can be fixed, retested and documented within the period. Testing in the last few weeks leaves no time to show remediation.

Does SOC 2 accept an internal penetration test?

Auditors strongly prefer independent testing. An internal test may be accepted in some cases, but a third-party report is stronger evidence and is what most customers ask for.

How often do you need a SOC 2 pen test?

At least annually and after significant changes to the application or infrastructure. Annual testing lines up with annual SOC 2 reporting.

Can a vulnerability scan replace a SOC 2 penetration test?

No. A scan lists known vulnerabilities, while a penetration test attempts to exploit them and shows real impact. Most auditors expect both.

Final Thoughts

The SOC 2 penetration testing requirements you face are set less by the text of the criteria and more by what auditors and customers expect to see: an independent, well-scoped test, a clear findings log, verified fixes and a repeatable annual schedule.

If you want a test that is scoped to your SOC 2 boundary and produces audit-ready evidence, Privaxi can help with SOC 2 penetration testing. Book a scoping call and we will map the test to your audit timeline.