SOC 2 has never required a pen test

The belief comes from vendors, not the rulebook

On sales calls I keep hearing the same sentence: we know we need the pen test for SOC 2. When I ask who told them that, the answer is a vendor's checklist, a blog written by a penetration testing firm, or another founder who assumed it. Nobody has ever pointed me at the SOC 2 rules themselves, because the rules do not say it.

A report we issued this summer contains no penetration testing control at all. The company does not run pen tests, so there was nothing to claim and nothing to test. That is a normal outcome, and it surprises almost everyone I tell.

A penetration test, for anyone new to the term, is a paid engagement where security specialists attempt to break into your systems the way an attacker would, then write up what they found. It is useful work, and it is also one of the most expensive line items a small company gets told to buy before a first report.

The requirement is written down, and a pen test is not in it

A SOC 2 audit, which the standards call an examination, measures your controls against the AICPA's Trust Services Criteria. Controls are the specific things you do to keep your system safe: who gets access, how changes ship, what gets monitored. The criteria are the requirement, and they are written at the level of principle.

Attached to each criterion are points of focus, which are illustrations of how a company might address it, and the AICPA is unusually direct about their status: they are guidance, not every one applies to every company, and you are not required to address each one.

Penetration testing appears in exactly one place in that entire document: a point of focus under criterion CC4.1, named as one example alongside independent certification against established specifications and internal audit assessments. That is the whole appearance: one example sitting in guidance next to alternatives.

CC4.1 itself is written in audit-speak: the entity selects, develops, and performs ongoing and/or separate evaluations to ascertain whether the components of internal control are present and functioning. Translated: do not just set up controls and walk away. Check that they work. The and/or is doing real work in that sentence, and I come back to it below.

The rule names two habits, and asks for either

Ongoing evaluation is the monitoring you live with: alerts, dependency scanning, posture checks, and a periodic review where someone with authority reads the outputs and signs off. Small companies are often stronger here than enterprises, because the founder sees everything.

Separate evaluation is a point-in-time look by someone who does not operate the controls. That independence is the whole value. The engineer who built your access setup reviewing that same setup is a self-check, and self-checks have a blind spot problem no amount of diligence fixes.

Now the part most articles skip, including the ones written by firms like mine. The criterion says ongoing and/or separate, so a company that only monitors, and monitors well, satisfies it on the words alone. I ask for both anyway. Monitoring is run by the same people who run the controls, and a check on your own work has a blind spot that care does not remove, so an outside look is what makes the rest of it credible to a reader. That is my standard and not the AICPA's, and you should always know which one you are being told, because a requirement someone invented is exactly how the pen test myth started.

A pen test is one way to buy that outside look. Notice its scope, though. A pen test answers one question well: how hard your systems are to break into. Whether access reviews happen, whether changes get approved, whether backups restore, those are different questions, and the criterion covers them too. The instrument everyone assumes is mandatory is the one with the tightest scope on the AICPA's own example list.

Several instruments clear the bar

Here is the bar I apply before a separate evaluation carries weight in an examination. A named party performs it and stands behind it. That party does not build or run the controls it evaluates. It produces a dated report with a stated scope and real findings. And your response to those findings is recorded, even when the response is a reasoned decision to accept a risk.

Instruments that clear it:

• A partner-led cloud security review. The major cloud providers run programs where a partner firm reviews your workload against a security framework and issues a findings report. Often free, because the provider funds it. The self-service version you click through yourself is you evaluating you, so it does not clear the bar.
• A fixed-scope assessment from an independent consultant. A review sized for a small company, pointed at access, change management, monitoring, backups, and vendors.
• A customer's security review of you. When an enterprise buyer's security team assessed your controls before they signed the contract, that was an independent evaluation, and it is probably sitting in your inbox. Keep the questionnaire, the findings, and your replies.
• An independent certification. ISO 27001, for companies that already hold it.
• A prior examination. From your second cycle on, the completed prior report is itself an independent evaluation of your controls.
• A penetration test. It stays on the list, and it remains good work. The framework treats it as one option.

A tool you run on yourself does not count

The failures I see share one shape: no independent party ever stood behind an evaluation of the controls.

A vulnerability scanner export is a list of software flaws, not an evaluation of your controls. A monitoring dashboard, however green, is ongoing monitoring rather than a separate look. A tool you run against your own systems is a self-check no matter how advanced the tool, and that includes the new generation of AI security agents: the tool got smarter, but the independence did not change, because you are still the one running it. An IT provider that manages your environment cannot independently review the work it does for you. And a certificate with no findings, no scope, and no method behind it is a logo.

Your contract can require a pen test even when SOC 2 does not

There are two cases where you should still get one.

Your customer contracts may require annual penetration testing outright. Plenty of enterprise agreements do. SOC 2 staying silent does not quiet a contract you signed, so read the contract before you spend anything.

And sometimes a pen test is simply the right security decision: you are shipping something attackers will genuinely target, and you want specialists trying to break it. Whether SOC 2 requires a pen test is a question about a framework, and the answer is no. Whether your product needs one is a question about your threat model, and no compliance article should answer it for you.

What I hope changes is the reflex. The pen test became the default answer to this criterion because a single tidy PDF is the easiest thing in the chain for everyone to point at, and your report will show what was tested either way. Working out what the rule asks for takes more effort up front, and considerably less money from you.