Does SOC 2 require penetration testing?

Not by name. The Trust Services Criteria do not list a penetration test as a mandatory control. They expect you to evaluate whether your controls are present and working (CC4.1) and to detect and fix vulnerabilities (CC7.1), and a penetration test is one common way to produce evidence for both. Four outside guides agree that it is not strictly required and differ on how firmly they recommend one. In practice, customers and auditors often expect one, and if your own policy commits you to an annual test, the auditor can test whether you ran it. The decision to skip a test is yours to make and document, and it is the CPA firm that judges whether your other evaluations are enough.

How often should we run a penetration test for SOC 2?

As often as your own policy says, because that is what the auditor tests. The Policyseed templates commit to an independent test at least annually and after major architectural changes. One guide quoted on this page calls annual the minimum, and another says a test for a Type II report must fall inside the review period. Neither is a rule in the criteria, so confirm the timing with your CPA firm before you book.

Can vulnerability scans replace a penetration test?

Possibly for the criteria, but check what your customers expect. A scan is automated and finds known weaknesses; a penetration test is a person trying to exploit them and chain them together. One of the cited guides describes smaller organizations using scanning as an alternative evaluation, but the Policyseed templates require both a scanning cadence and an annual test, so if your policy says both, you need both. Ask your largest customer which they expect.

Do we need a penetration test for a Type I report?

The criteria do not say so, and the sources here speak mostly about the review period of a Type II report. A Type I report looks at whether controls are designed and in place on one date, so an auditor is likely to ask what your policy says and whether you have a test planned or done. If the policy says annual and nothing has happened yet, expect that question. Ask the CPA firm what it will want to see for your scope.

What should we ask the tester to deliver?

Three things: the full report for your engineers, a short letter you can send customers without exploit details, and a retest of the Critical and High findings after you fix them. The Policyseed policies require the report and the retest letter to be kept as audit evidence, so a quote that leaves out the retest or the letter is incomplete. Put all three in the written scope you send every firm.

Can we test ourselves, or must it be an independent firm?

The generated policies say the test is performed by an independent tester. Whether an internal or open-source scan satisfies a given customer or CPA firm is their decision, not a rule in the criteria. If you want a different arrangement, change the policy to describe what you will actually do before you adopt it, and keep the evidence for that.

How much does a SOC 2 penetration test cost?

It depends on scope, and this page cannot give you a price of its own. One vendor, Bright Defense, lists tiers from $2,750 to $10,000 for compliance-focused testing, $15,000 to $30,000 for expanded testing and $50,000 and up for advanced environments. Treat that as a seller's published range, get two or three quotes against the same written scope, and see the SOC 2 cost guide for other cited figures.

Does SOC 2 require a penetration test? What the sources say and what to do

Updated 25 October 2026

No criterion in SOC 2 names a penetration test as a mandatory control. The Trust Services Criteria expect you to check that your controls work and to find and fix vulnerabilities, and a penetration test is one common way to show both. The four outside guides cited here agree it is not strictly required and differ on how firmly they recommend one, and many customers and auditors expect one anyway. The part that binds you most is your own policy: if it commits you to an annual test, the auditor tests whether you did what you wrote.

Short answer: not named in the criteria, and widely expected

A SOC 2 report is written by a CPA firm after it examines your controls against the Trust Services Criteria. Those criteria describe outcomes, not a list of tests. Four guides on this exact question land in the same place on the requirement and in different places on the advice:

Source	On whether it is required	On what to do
Bright Defense	Says a test is "not a formal requirement" and the standard does not mandate a list of technical assessments.	Describes auditors as viewing it as a practical tool, with a risk-based schedule and a test that falls inside the review period, especially for Type II.
Scytale	Says SOC 2 does not explicitly mandate one but "strongly implies" it under the security category.	Calls a test "highly recommended", with no cadence given.
IS Partners	Says SOC 2 does not explicitly require one.	Calls it "highly recommended" and suggests testing at least annually.
Drata	Says a test is technically not a requirement but one of several evaluations you may choose, based on your risk assessment.	Notes that customers and prospects may expect one, and that auditors will likely question a decision to skip it.

Most of these publishers sell testing, compliance software or audit services, so read them as one side of the question. They agree on the fact that matters: there is no SOC 2 rule that says "you must buy a penetration test". They also point to the same practical risk, which is that a customer's security review or an auditor's question will land on it anyway. Drata's framing is the most useful one: the test is a choice, and you should be able to explain the choice.

The criteria a test supports

The generated Vulnerability and Patch Management Policy is mapped to three criteria, and a penetration test is evidence under each:

CC4.1 (Ongoing and separate evaluations): The company checks that its controls actually work, through routine monitoring (scans, reviews) and periodic separate checks such as a penetration test or internal audit.
CC6.8 (Malicious software): The company prevents and detects unauthorized or malicious software on endpoints and in its software supply chain, and keeps systems patched.
CC7.1 (Detecting vulnerabilities and configuration changes): The company watches for new vulnerabilities and for unexpected changes to its infrastructure configuration, and fixes what it finds within defined timeframes.

CC4.1 is where outside guides tie penetration testing most directly. Bright Defense quotes a point of focus that lists penetration testing among the kinds of ongoing and separate evaluations management may use, and Drata reads the same criterion as letting you choose which evaluations fit your risks (Drata). Points of focus are guidance for how a criterion can be met, not separate requirements. CC7.1 is the vulnerability side: you have a process that finds weaknesses and fixes them within defined timeframes, which scans, a test and a findings register together evidence. The penetration test scope template repeats this mapping and adds CC4.2, which covers reporting what an evaluation found to the people who must fix it.

Vulnerability scans vs a penetration test

Bright Defense puts the difference as complementary evidence: scans identify potential weaknesses, while penetration tests validate exploitability and impact (Bright Defense). Some guides use the two terms almost interchangeably, which makes it easy to buy a scan with a report template when you meant a test. Keep them separate when you scope work:

	Vulnerability scan	Penetration test
Who or what runs it	A tool, on a schedule or in your pipeline	A person, with tools, over days or weeks
What it finds	Known weaknesses and misconfigurations	Exploitable paths, including authorization and business-logic flaws a scanner cannot judge
What it leaves behind	Scan reports with dates, and tickets in your register	A report, a customer-facing letter and a retest letter
How the policy treats it	Continuous and scheduled, with fixed remediation timelines	An annual independent test, plus a test after major architectural changes

Drata presents scanning as an alternative evaluation that a smaller organization with limited resources might choose under CC4.1 (Drata). That is a legitimate position to take in your risk assessment, but your policy has to say it. The generated policies keep scans and the test as separate commitments:

Vulnerability and Patch Management Policy, 4.10: Internet-facing systems are scanned at least quarterly and after significant changes, in addition to continuous pipeline scanning.

Network and Infrastructure Security Policy, 4.13: The external attack surface of Northwind is scanned for open ports, exposed services and known vulnerabilities at least monthly, and an independent penetration test of production is performed at least annually and after major architectural changes. Findings are remediated under the Vulnerability and Patch Management Policy.

What your own policies commit you to

This is the section that decides your workload. A policy is a statement of what you do, and the auditor tests it against records. The Policyseed templates commit to an independent test in several places, and the excerpts below are rendered from the policy templates for the Northwind Cloud Inc sample intake, so they change when a template does. The company and product names in them are the sample's.

Vulnerability and Patch Management Policy, 4.12: Penetration test findings enter the register at the tester's severity, adjusted under 4.2 where warranted, are remediated within the 4.3 timelines, and Critical and High findings are retested by the tester before closure. The Security Owner reports monthly to Executive Management on open findings by severity, the percentage remediated on time, overdue items and active exceptions.

Vulnerability and Patch Management Policy, 5.6: Penetration test. The Security Owner engages an independent tester annually, scopes Northwind (Web SaaS) and its infrastructure, agrees the rules of engagement in 4.13, provides accounts and documentation, enters findings into the register, tracks remediation and obtains a retest letter for Critical and High findings; the report and letter are retained as audit evidence.

Secure Software Development Policy, 4.12: Northwind receives an independent penetration test at least annually and after major architectural changes; findings are remediated under the Vulnerability and Patch Management Policy and Critical and High findings are retested before closure.

Network and Infrastructure Security Policy, 5.6: External scanning and penetration testing. Engineering scans all public endpoints at least monthly and triages results within five business days. The Security Owner engages an independent penetration testing firm annually, tracks findings to closure in the vulnerability register and retains the report and remediation evidence. Owner: Security Owner. Cadence: monthly scan; annual test.

The Secure Software Development Policy also assigns Executive Management to fund an annual penetration test in its roles section, and its metrics procedure has the Security Owner report penetration test status each quarter. The Network and Infrastructure Security Policy also commits to an independent test of production in its statements and procedures.

That is a real commitment. Three honest ways to handle it:

Run the test. Keep the report, the retest letter and the scope approval as evidence.
Change the policy before you adopt it. If you will not test annually, edit the statement to say what you will do and why, and record that choice in your risk assessment. Drata notes that auditors will likely look at the reasoning, so write it down.
Record a time-limited exception if you need a few months, with compensating controls such as scanning, and an expiry date. The free policy exception register is built for this.

What does not work is adopting the sentence and letting the year pass. An auditor who samples your records for the period will ask for the test, and the gap is easier to explain before the question than after.

Scoping a first test for a small SaaS product

A small-product scope is mostly four things. Write them down before you ask anyone for a price, because the scope is what makes quotes comparable:

The application and its API. Test each user role you have, and especially that one customer cannot reach another customer's data. Provide test accounts for at least two roles in two tenants.
Internet-facing hosts. The domains and IP ranges you own, so exposed services are tested from the outside.
Cloud configuration. A read-only review of your hosting account, limited to your own resources and following the provider's published testing rules.
Out of scope. Third-party services, denial-of-service testing and anything you do not own. Say so, so no one has to guess.

Then fix the rules of engagement. The generated policy sets them:

Vulnerability and Patch Management Policy, 4.13: Penetration tests, audit tests and other technical assessments of live systems are scoped and approved in writing by the Security Owner and the Engineering lead before they start, and scheduled away from peak usage and release windows. They use a non-production environment or read-only access wherever that meets the objective, both sides name contacts who can halt the test and roll back any change, and test accounts and data are removed when testing ends.

Timing matters too. Bright Defense says a test must fall within the audit review period, especially for a Type II report (Bright Defense). Whether your CPA firm will accept a test dated just before the period is its call, so ask it first, and allow time for fixes and a retest before the period ends. The free penetration test scope template builds a Word scope and request for proposal from your generator answers (application type, hosting, data types, team size and source control) with the rules above quoted from your own policies. The SOC 2 scope guide covers deciding what is in your system boundary in the first place.

Comparing quotes without a vendor recommendation

Policyseed does not recommend a testing firm. Send the same written scope to two or three independent firms, then compare what each price covers:

Whether the work is mostly manual testing by named people, or an automated scan with a report template.
Whether a retest of Critical and High findings is included, since your policy requires one before they close.
Whether you receive a customer-shareable letter as well as the full report.
A sample report, so you can see the level of detail and how findings are rated.
Independence from anything else the firm sells you, and who actually does the work.
The start date and turnaround, against your review period.

On price, only published ranges are worth repeating, and each is a seller's. Bright Defense, which sells testing, lists "Compliance Focused Testing" at $2,750 to $10,000, "Expanded Security Testing" at $15,000 to $30,000 and advanced environments at $50,000 and up, and says cost depends on scope, complexity and provider (Bright Defense). Quotes vary on what they include, which is why the scope comes first. The SOC 2 cost guide sets other cited figures next to the rest of the audit budget. The scope template's Excel sheet scores each proposal 1 to 5 on methodology, testers, retest, letter, report, price and timeline and ranks them with weights you can change.

Tracking findings to closure and retesting

The report is not the end of the control. The auditor is likely to ask what happened to the findings, so the policy's timelines and your register are the evidence. The generated policy sets deadlines by severity and a retest before closure:

Vulnerability and Patch Management Policy, 4.3: Findings are remediated within timelines measured from detection: Critical within 7 days, High within 30 days, Medium within 90 days, and Low within 180 days or at the next scheduled maintenance, whichever is sooner. Where no fix exists for a Critical finding in an internet-facing system, a mitigating control such as a firewall rule, feature disablement or configuration change is applied within 72 hours.

Vulnerability and Patch Management Policy, 5.8: Exceptions and closure. Exception requests are submitted through the register, evaluated by the Security Owner for compensating controls, approved as required and entered in the exception register with an expiry of at most 90 days, remaining visible in reporting as accepted risk. Before closing any finding the owner attaches evidence such as a clean rescan, retest result, deployment record or dated configuration screenshot; the Security Owner spot-checks closures monthly and reopens any lacking evidence.

In practice that is a column in one register for each finding: the tester's severity, your adjusted severity if different, an owner, a due date from the policy, a link to the change that fixed it, and the retest result. Anything you decide not to fix on time becomes an approved exception with an expiry. The security metrics report turns open and overdue findings into the quarterly report to management, and the risk register is where a finding that you accept belongs. To see how your whole posture looks before an auditor does, take the free SOC 2 readiness assessment.

If you would rather start from a full folder, the Audit Kit ($59, one time) includes a penetration test scope and request for proposal in its security-testing folder, built from your tailored policies. It does not run the test. That still takes an independent firm.

Frequently asked questions

Does SOC 2 require penetration testing?: Not by name. The Trust Services Criteria do not list a penetration test as a mandatory control. They expect you to evaluate whether your controls are present and working (CC4.1) and to detect and fix vulnerabilities (CC7.1), and a penetration test is one common way to produce evidence for both. Four outside guides agree that it is not strictly required and differ on how firmly they recommend one. In practice, customers and auditors often expect one, and if your own policy commits you to an annual test, the auditor can test whether you ran it. The decision to skip a test is yours to make and document, and it is the CPA firm that judges whether your other evaluations are enough.
How often should we run a penetration test for SOC 2?: As often as your own policy says, because that is what the auditor tests. The Policyseed templates commit to an independent test at least annually and after major architectural changes. One guide quoted on this page calls annual the minimum, and another says a test for a Type II report must fall inside the review period. Neither is a rule in the criteria, so confirm the timing with your CPA firm before you book.
Can vulnerability scans replace a penetration test?: Possibly for the criteria, but check what your customers expect. A scan is automated and finds known weaknesses; a penetration test is a person trying to exploit them and chain them together. One of the cited guides describes smaller organizations using scanning as an alternative evaluation, but the Policyseed templates require both a scanning cadence and an annual test, so if your policy says both, you need both. Ask your largest customer which they expect.
Do we need a penetration test for a Type I report?: The criteria do not say so, and the sources here speak mostly about the review period of a Type II report. A Type I report looks at whether controls are designed and in place on one date, so an auditor is likely to ask what your policy says and whether you have a test planned or done. If the policy says annual and nothing has happened yet, expect that question. Ask the CPA firm what it will want to see for your scope.
What should we ask the tester to deliver?: Three things: the full report for your engineers, a short letter you can send customers without exploit details, and a retest of the Critical and High findings after you fix them. The Policyseed policies require the report and the retest letter to be kept as audit evidence, so a quote that leaves out the retest or the letter is incomplete. Put all three in the written scope you send every firm.
Can we test ourselves, or must it be an independent firm?: The generated policies say the test is performed by an independent tester. Whether an internal or open-source scan satisfies a given customer or CPA firm is their decision, not a rule in the criteria. If you want a different arrangement, change the policy to describe what you will actually do before you adopt it, and keep the evidence for that.
How much does a SOC 2 penetration test cost?: It depends on scope, and this page cannot give you a price of its own. One vendor, Bright Defense, lists tiers from $2,750 to $10,000 for compliance-focused testing, $15,000 to $30,000 for expanded testing and $50,000 and up for advanced environments. Treat that as a seller's published range, get two or three quotes against the same written scope, and see the SOC 2 cost guide for other cited figures.

Policyseed provides governance policy templates and AI tailoring. It is not legal advice and not a compliance guarantee. Management adopts the policies; the CPA firm performs the SOC 2 examination.