2026-07-19 · GUIDE · The Offensive Technology team

Does SOC 2 require a penetration test?

Short answer: no, and also yes. SOC 2 has no line in it that says "you must run a penetration test." But most auditors expect one anyway, and if you are reading this because a customer or a sales deal is waiting on your report, that gap between the letter of the standard and what your auditor accepts is exactly what you need explained. Here it is, without the vendor spin.

What SOC 2 actually is

SOC 2 is not a checklist of controls. It is an attestation report produced by a licensed CPA firm, measured against the AICPA's Trust Services Criteria. The AICPA (the American Institute of Certified Public Accountants) publishes those criteria publicly, and they are written as broad objectives, not specific tools. That design is deliberate. The standard cares whether you meet the objective, not which product you bought to meet it.

This is why you will never find "penetration test" listed as a hard requirement. SOC 2 does not work that way. It asks whether you monitor your systems, manage vulnerabilities, and evaluate your controls, and it leaves the how to you and your auditor.

Where the pentest expectation actually comes from

Read the criteria and two of them do the heavy lifting here.

CC4.1, the monitoring criterion, is about how management evaluates whether its controls are working. The AICPA's own supporting language lists penetration testing as an example of the kind of separate evaluation an organization can use for this. It is named as an illustration, not a mandate, but it is named.
CC7.1 covers detecting vulnerabilities and configuration changes. Vulnerability scanning is the natural fit here, and most auditors expect to see it running on a schedule.

So the pentest is not required by the text. It is the most common, most defensible way to produce evidence that satisfies CC4.1, and auditors have converged on expecting it because it is the evidence they trust. When people say "SOC 2 requires a pentest," this is what they actually mean: your auditor will very likely ask for one, even though the standard does not.

What that means in practice

A few honest realities that the criteria imply but do not spell out:

Your auditor sets the bar, not a blog. Two audit firms can accept different evidence for the same criterion. Before you buy anything, ask your auditor directly what they expect for CC4.1 and CC7.1. Their answer is the only one that governs your report.
A scan is not a pentest, and auditors can tell. Vulnerability scanning supports CC7.1. It does not, on its own, demonstrate the kind of independent evaluation CC4.1 is pointing at. If you hand over a rebranded scan and call it a penetration test, an experienced auditor will notice, and so will the enterprise customer reading your report.
Type 2 has a timing trap. A SOC 2 Type 1 is a point-in-time snapshot. A Type 2 covers a window, often several months to a year. For the test to count as evidence for a Type 2, it generally needs to fall inside that observation window. A pentest from eighteen months ago may not help you.
Annual is the common cadence. Most auditors treat a test performed at least once a year as the baseline expectation, with a fresh one before each renewal. We cover the full picture across frameworks in how often should you get a penetration test?

Do not confuse SOC 2 with a security guarantee

This is where we have to be plain, because it is the part buyers get wrong. A SOC 2 report tells a customer that a CPA firm evaluated your controls against a set of criteria during a period. It does not mean you cannot be breached, and it does not mean the pentest inside it was deep. A test scoped narrowly enough to tick a box, run by whoever was cheapest, can technically support the report and still miss the way an attacker actually gets in.

If you are running a pentest only to pass the audit, you get a certificate. If you are running one to actually find out where you are exposed, you get security. Those can be the same test. They are not automatically the same test, and the difference is who does the work and how honestly the scope is drawn.

So what should you actually do?

If SOC 2 is on your roadmap, the sensible order is: confirm with your chosen auditor what they expect for CC4.1 and CC7.1, then scope a penetration test that meets that expectation and is timed to your observation window. Do not buy a test blind, and do not accept a scan dressed up as an engagement.

But there is a cheaper step that belongs before all of that. Before you commit to a five-figure audit-grade engagement, it is worth knowing what an attacker already sees from the outside, so you walk into the process without obvious exposures waiting to surprise you. That will not replace the pentest your auditor wants, and we will tell you so plainly. It just means you start the SOC 2 process with your eyes open instead of shut.

Our $100 check is that first look: a focused review of your external attack surface, run on scope you have verified you own and authorized in writing, reviewed by a senior operator, and delivered with a 30-minute readout. If your SOC 2 auditor needs a full penetration test, the check will not satisfy them, and we will say so before you pay, not after. But it is the honest, cheap place to begin.

SOC 2 and penetration testing: quick answers

Does SOC 2 require a penetration test?

No. SOC 2 has no line that requires one; the AICPA Trust Services Criteria are written as broad objectives, not specific tools. But most auditors expect a penetration test as evidence for the monitoring and vulnerability criteria, so in practice you almost always need one.

Which SOC 2 criteria point to penetration testing?

CC4.1 (monitoring) and CC7.1 (detecting vulnerabilities). The AICPA's supporting guidance names penetration testing as an example of the separate evaluation that can satisfy CC4.1. It is an example, not a mandate.

How often do you need a pentest for SOC 2?

Most auditors expect testing at least annually, timed to fall inside your Type 2 observation window. Confirm the exact cadence with your own auditor.

Does a vulnerability scan satisfy SOC 2?

A scan supports vulnerability-management evidence but does not, on its own, show the independent evaluation auditors look for. A scan rebranded as a penetration test tends to get noticed.