SOC 2 does not require a penetration test. The AICPA Trust Services Criteria never use the phrase. In practice most auditors accept a penetration test as the evidence for CC4.1 and CC7.1, and a company with no security testing evidence at all should expect questions.
The question gets asked constantly and answered badly. Vendors say yes because they sell tests. Compliance platforms say it depends. The precise answer is more useful than either.
SOC 2 does not require a penetration test. Search the AICPA Trust Services Criteria for the phrase and it is not there. What the criteria require is evidence that controls are present and functioning, and a penetration test happens to be the cleanest way most companies produce it.
What the criteria actually say
Two of the common criteria create the expectation.
CC4.1 asks the organization to select, develop and perform ongoing or separate evaluations to ascertain whether the components of internal control are present and functioning. That is COSO Principle 16, imported into the Trust Services Criteria. It asks for an evaluation. It does not say what kind.
CC7.1 asks the organization to use detection and monitoring procedures to identify changes to configurations that introduce new vulnerabilities, and susceptibilities to newly discovered vulnerabilities. Again: an outcome, not a technique.
Neither criterion names penetration testing, vulnerability scanning, code review or anything else. The Trust Services Criteria are written as outcomes on purpose, which is also why two auditors can look at the same control environment and reach different conclusions about it.
Why auditors expect one anyway
An auditor has to put something in a workpaper. A penetration test report is a dated artifact with a defined scope, a stated method, a list of findings with severities, and a record of what was fixed. It is easy to sample, easy to reference, and hard to argue with.
Compare that to the alternatives a startup usually has on hand. A vulnerability scan export shows that a tool ran. A code review shows that someone looked. Neither establishes that a control is functioning in the way CC4.1 asks about, and an auditor who accepts them is making a judgment call that a more conservative auditor will not make.
There is also a reader on the other side. Enterprise security reviewers read SOC 2 reports properly, and they have started asking two specific questions: was there security testing, and was it performed by someone independent of the team that built the system. Neither question comes from the criteria. Both come from buyers who have been burned.
The part that is actually a requirement
Something close to a requirement does exist, and it is not the test itself.
If you say you do it, you have to do it. The system description in a SOC 2 report is written by management, and control descriptions in it become testable commitments. A description that says the organization performs annual penetration testing creates an obligation that the auditor will then test against. Companies routinely write an aspirational control description and then fail it.
The safer order is to decide what you actually do, describe that, and let the description be boring and true.
Type I and Type II change the timing, not the answer
For a Type I, the report covers control design at a single date. A recent test dated before the report date is clean design evidence. The mistake here is scheduling: a test dated after the report date is not evidence for that report.
For a Type II, the report covers an observation window. The test has to fall inside the window. This is the single most common scheduling error in a first Type II, and it is expensive because there is no way to fix it retroactively. A test performed the month before the window opened does not evidence the window.
The second Type II mistake is testing too late inside the window. Find a critical issue in the final two weeks and there is nowhere for it to go except into the report, still open. Test early enough that remediation and a retest also fit.
What to do with this
If an auditor has told you they expect a penetration test, they expect one, and the criteria give you no argument to make. That is their judgment to exercise.
If nobody has told you yet, the useful questions are these. Does the system description commit you to testing. Does the observation window have room for a test plus remediation plus a retest. And will the buyers reading this report be the kind who ask who performed the testing.
For most companies selling into enterprise the answer lands in the same place regardless of what the criteria compel. The distinction still matters, because knowing the difference between what a standard requires and what your auditor expects is how you have a productive conversation with them instead of paying for something nobody asked for.
Questions people ask
Does SOC 2 require a penetration test?
No. The AICPA Trust Services Criteria do not name penetration testing anywhere. A penetration test is the most common evidence used to satisfy CC4.1 and CC7.1, and most auditors expect some form of security testing, but the requirement is for an evaluation showing controls are present and functioning rather than for a specific technique.
Which SOC 2 criteria relate to penetration testing?
CC4.1, which requires evaluations to ascertain whether components of internal control are present and functioning, and CC7.1, which requires detection and monitoring procedures to identify new vulnerabilities and configuration changes that introduce them.
Can a vulnerability scan replace a penetration test for SOC 2?
Sometimes, for a Type I, with a cooperative auditor. It is weaker evidence because a scan demonstrates that a tool ran rather than that a control is present and functioning, and enterprise reviewers reading the report increasingly notice the difference.
When should the penetration test happen for a SOC 2 Type II?
Inside the observation window, and early enough in it that remediation and a retest also fit. A test dated before the window opens does not evidence the window, and a test in the final weeks leaves a critical finding nowhere to go but into the report.