Does SOC 2 Require a Penetration Test?

Not by name. The AICPA's Trust Services Criteria, the criteria a SOC 2 examination is performed against, use the words "penetration testing" exactly once, and the sentence they appear in is a point of focus rather than a criterion. The AICPA is explicit about what that means: "Use of the trust services criteria does not require an assessment of whether each point of focus is addressed." So there is no clause you can point to that says a SOC 2 report needs a penetration test. What there is instead is a pair of criteria, CC4.1 and CC7.1, that require you to evaluate whether your controls are present and functioning and to detect new vulnerabilities, and an auditor who has to be satisfied that you did. In the engagements we see, a penetration test with a remediation trail is the evidence that closes that conversation fastest, and the enterprise buyers reading your report ask for the test report directly, criteria or no criteria.

This article is the text of the criteria, the reason "not required" does not mean "optional", where the report lands in the examination, the timing mistake that wastes the test, and the cases where we would tell you not to buy one yet. It deliberately does not restate what our HIPAA version of the same question says about that regime, or what how often to run a penetration test says about cadence across frameworks.

Key takeaways

• The Trust Services Criteria do not contain a penetration testing requirement. The words appear in one point of focus under CC4.1, and the AICPA states that use of the criteria does not require an assessment of whether each point of focus is addressed.
• CC4.1 requires evaluations to ascertain whether the components of internal control are present and functioning; CC7.1 requires detection and monitoring procedures for new vulnerabilities. A penetration test is evidence for both, and it is the evidence auditors and buyers recognise on sight.
• The 2022 revision of the points of focus widened the CC4.1 list to name vulnerability scans, security assessments, penetration testing and third-party assessments side by side. It did not promote any of them to a requirement.
• Timing decides whether the test counts. A Type II opinion covers a period, and a test completed before the observation period opens is evidence about a different period.
• Scope the test to the system boundary in your description, ask for a retest of fixes, and keep the remediation trail. A clean report with no trail evidences less than a report with findings and closed tickets.

What the Trust Services Criteria actually say

The document is TSP section 100, the AICPA's 2017 Trust Services Criteria for Security, Availability, Processing Integrity, Confidentiality, and Privacy, which the AICPA now publishes with revised points of focus dated 2022. Two criteria carry the weight.

CC4.1, which the document labels 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." Beneath it, listed as an additional point of focus specifically related to engagements using the trust services criteria, is the only mention of penetration testing in the 2017 text: "Management uses a variety of different types of ongoing and separate evaluations, including penetration testing, independent certification made against established specifications (for example, ISO certifications), and internal audit assessments."

CC7.1: "To meet its objectives, the entity uses detection and monitoring procedures to identify (1) changes to configurations that result in the introduction of new vulnerabilities, and (2) susceptibilities to newly discovered vulnerabilities." Its points of focus include "Conducts Vulnerability Scans", which in the 2017 text reads: "The entity conducts vulnerability scans designed to identify potential vulnerabilities or misconfigurations on a periodic basis and after any significant change in the environment and takes action to remediate identified deficiencies on a timely basis." Scans, note, not tests. CC7.1 never says penetration.

Now the status of a point of focus, in the AICPA's own words. Paragraph .03 of the 2017 text says the points of focus "may assist management when designing, implementing, and operating controls" and "may assist both management and the practitioner when they are evaluating whether the controls were suitably designed and operated effectively to meet the trust services criteria." Paragraph .04 then says: "Use of the trust services criteria does not require an assessment of whether each point of focus is addressed." The 2022 red-lined revision keeps that sentence word for word, renumbered as paragraph .07.

One more line from the 2017 text matters for scoping: paragraph .08 says "the common criteria should be applied regardless of which trust services category is included within the scope of the engagement." CC4.1 and CC7.1 are common criteria. You cannot scope your way out of them by selecting Security only, because Security is the category they live in.

What the 2022 revision changed, and what it did not

The 2022 revision rewrote the CC4.1 point of focus rather than adding a requirement. The inserted text says that, depending on the entity's objectives, "such risk and control evaluations may include first- and second-line monitoring and control testing, internal audit assessments, compliance assessments, resilience assessments, vulnerability scans, security assessment, penetration testing, and third-party assessments."

Read that list the way it is written. Penetration testing sits between "security assessment" and "third-party assessments" in a list introduced by "may include". The revision made the point of focus more useful as a menu and no more binding than it was. Anyone telling you the 2022 update "made pentesting mandatory for SOC 2" has not read the sentence.

Why "not required" does not mean "optional"

The criteria do not name the evidence. The examination still needs some.

CC4.1 asks whether your controls are present and functioning, and an auditor testing that criterion has to see an evaluation you performed. CC7.1 asks how you find new vulnerabilities, and the auditor has to see the procedure and its output. In our experience there are three answers a service organization can give, and they are not equally cheap to defend.

The first is a penetration test report from a qualified tester, with findings, a remediation trail and a retest. It evidences CC4.1 directly (a separate evaluation, performed by someone outside the control's operation) and CC7.1 partly (susceptibility to vulnerabilities, demonstrated rather than scanned for). Most auditors we work alongside accept it without a follow-up question.

The second is an authenticated vulnerability scanning programme on a real cadence, with findings tracked to closure. That is squarely what the CC7.1 point of focus describes, and for a small and stable environment it can be enough for CC7.1. It is weaker for CC4.1, because a scan is not an evaluation of whether the components of internal control are functioning; it is an inventory of known weaknesses in software versions. Penetration test versus vulnerability scan explains why the two answer different questions.

The third is an internal assessment: your own team, a self-evaluation, a checklist walk. It is admissible. It is also the answer that prompts the longest conversation in fieldwork, because the evaluator and the operator are the same people.

Then there is the constraint the criteria never mention. Your customers' vendor security teams ask for a current penetration test report in their questionnaires, and they ask for the report itself, not for a statement that CC4.1 was met. In our experience that request arrives with a deal attached, and it is the actual reason most companies buy the test. The SOC 2 examination is where the report gets a second use.

Where a test lands in the examination

The third row is the one people get backwards. A penetration test does not satisfy the scanning point of focus, because a test is a snapshot and the point of focus describes a periodic programme. If your only vulnerability activity is an annual test, you have CC4.1 evidence and a CC7.1 gap. Buy scanning first; it is cheaper, and it is what the text describes.

The timing mistake that wastes the test

A SOC 2 Type II opinion covers an observation period, and the auditor samples evidence from inside that period. A test completed the month before the window opens is evidence about a period the opinion does not cover. It will usually still be read, and it will usually still prompt the question of what you did during the period.

The mechanics are in how long SOC 2 takes: a control that runs once a year produces exactly one occurrence inside a twelve-month window and possibly none inside a six-month one, and one occurrence is the difference between an opinion and an exception. An annual penetration test is such a control. So the scheduling rule is simple and widely ignored: put the test inside the window, early enough that remediation and the retest also land inside it. If you are running the sequencing our Type I versus Type II guide recommends, with the Type I issued from inside the Type II window, the test belongs in the first weeks after the window opens, not in the readiness phase before it.

For a Type I, which is a design opinion as of a date, the test evidences that the control exists and was performed; the date matters less. For a Type II, the date is the whole point.

Scoping a test so it is usable as SOC 2 evidence

Three things make a report land cleanly in fieldwork.

Match the scope to the system description. Section 3 of your report describes a system with a boundary. The test should cover that boundary: the customer-facing application and its APIs, the administrative console, the production cloud control plane, and the integration surfaces named in the description. A test of your marketing site evidences nothing about the system in the report. What type of penetration test do I need covers the engagement types; for SOC 2 the answer is almost always web application plus external network, with cloud configuration review where the description leans on it.

Ask for a retest and keep the trail. The auditor is testing whether you evaluate and remediate, so a report with findings, tickets, fixes and a retest letter evidences more than a report with no findings. A clean report from a tester you cannot name the methodology of evidences the least of all.

Get a report you can hand to a customer. Methodology, scope, dates, findings with severity, evidence of exploitation, remediation status, retest results. Your enterprise buyers will ask for exactly this document, and one report should serve both audiences. Penetration testing beyond checkbox compliance explains why a test that only exists to produce a PDF finds less than one that is scoped to find things.

If you also take cards, PCI DSS is a different regime with an actual mandate and its own segmentation rule, and those belong to our PCI segmentation testing article rather than here.

What it costs, and where the number lives

We publish penetration testing prices on exactly one page, the penetration testing cost breakdown, including the band for a test scoped to produce SOC 2 evidence. We are not restating the figures here, because one page per number is how this site keeps its answers consistent.

When we would tell you not to buy one yet

Against our own interest, three cases.

No production system yet. Testing a staging environment that does not resemble production produces a report about a system the SOC 2 description will not cover. Test when the boundary exists.

Findings from the last test are still open. A second test before you have remediated the first is the most expensive way to avoid remediation, and an auditor reading two reports with the same findings is reading a CC4.1 problem, not a CC4.1 answer.

No scanning programme. If you have never run authenticated vulnerability scanning on a cadence, a penetration test will spend its first days reporting what a scanner subscription would have told you. Stand up the CC7.1 programme first, then buy the evaluation.

Where Top Floor fits

We do SOC 2 readiness and we do penetration testing, and we scope the second to serve the first: to the system boundary in your description, timed inside your observation period, with a retest. We do not issue the SOC 2 report. Only a CPA firm does that, and a readiness firm that also opines on your controls has an independence problem you should ask about. Where the question is whether your evaluation evidence would survive fieldwork before you commit to a window, that is audit and assurance advisory.

How to decide this week

Open your control list and find the control that answers CC4.1, the one that says how you evaluate whether your controls are present and functioning. If it names a penetration test, check the date of the last one against the observation period you intend to run. If it names nothing, that is your gap, and it exists whether or not you buy a test.

Then pull the security questionnaires from your three largest open deals. If any of them asks for a penetration test report, you have a date and a buyer, and the SOC 2 question has answered itself.

Frequently asked questions

Does the AICPA require a penetration test for SOC 2?

No. The Trust Services Criteria mention penetration testing once, in a point of focus under CC4.1, and the AICPA states that use of the criteria does not require an assessment of whether each point of focus is addressed. What the criteria do require is that you evaluate whether your controls are present and functioning (CC4.1) and that you detect newly discovered vulnerabilities (CC7.1). A penetration test is the evidence most auditors expect for the first and part of the evidence for the second, but the text leaves the method to you.

Is a vulnerability scan enough for SOC 2?

For CC7.1 it can be, because that criterion's own point of focus describes vulnerability scans run periodically and after significant change, with findings remediated on a timely basis. For CC4.1 it is weaker, because a scan lists known weaknesses rather than evaluating whether your controls function. A scanning programme with no penetration test is defensible for a small, stable environment; a penetration test with no scanning programme leaves a CC7.1 gap. Most companies need both, and scanning is the cheaper one to start with.

Does the test have to happen during the observation period?

For a Type II, yes in practice. The opinion covers a period, and the auditor samples evidence from inside it. An annual test produces one occurrence, and if that occurrence falls before the window opens it is evidence about a period the report does not cover. Schedule the test in the early weeks of the window so that remediation and the retest also land inside it.

Do I need a penetration test for a SOC 2 Type I?

A Type I is a design opinion as of a date, so the auditor is checking that the evaluation control exists and is suitably designed, not that it operated across a period. A recent test helps, and the date matters less than it does for a Type II. If you are issuing the Type I from inside a Type II window, as we generally recommend, schedule the test for the Type II and let the Type I benefit from it.