Criteria · Evidence · Price

SOC 2 Penetration Testing Cost

SOC 2 does not contain a control that says "perform a penetration test". Auditors expect one anyway, and most readiness firms insist on it. Understanding why explains what the test has to produce, and therefore what you actually need to buy.

Why a framework that never mentions testing still requires it

SOC 2 is built on the Trust Services Criteria, which are written as outcomes rather than as a checklist of activities. There is no control numbered "penetration testing". This confuses people into one of two mistakes: assuming no test is needed, or buying a large one because a readiness vendor said so.

The useful framing is that a penetration test is evidence, not a requirement. It is the most practical way most organisations demonstrate two things:

  • CC4.1 - that you perform evaluations to determine whether your controls are actually present and functioning. An independent test is a direct, dated, externally-produced evaluation, which is exactly what this criterion is looking for.
  • CC7.1 - that you detect vulnerabilities and unauthorised changes to configuration. Scanning covers part of this continuously; a test covers the part scanning cannot reach.

Because it is an evidence question rather than a compliance checkbox, your auditor's opinion is the one that counts. Ask them specifically what they will accept, in writing, before you scope anything. Auditors differ, and the difference is sometimes thousands of dollars of scope.

What the evidence has to look like

A report on its own is the most common way this control still picks up a finding. The complete evidence chain has four parts, and the gaps are almost always in the last two.

  • Scope. The tested scope has to be recognisably the system described in your SOC 2 report. If your description of the system covers a multi-tenant SaaS platform and the test covered an unauthenticated marketing site, the mismatch is visible immediately.
  • Findings. Severity-rated, with a stated rationale rather than an unexplained colour, and with reproduction steps.
  • Remediation. Documented, with dates, and with a decision recorded for anything accepted rather than fixed. Risk acceptance is allowed; silence is not.
  • Verification. Evidence that fixes were retested and confirmed. This is the part most often missing, and it is the part that turns a report into proof a control works.

An attestation letter stating what was tested, when, by whom and with what result is what ties this together for the auditor, and it is what your customers will ask for later. It should be part of the engagement rather than a separate purchase.

Timing against your observation window

For Type I, which assesses design at a point in time, a recent test and a credible remediation plan generally suffice. For Type II, which assesses operating effectiveness across a period of typically three to twelve months, the test, the remediation and the retest all need to fall inside the window. Booking a test three weeks before the window closes leaves no room for the fix-and-retest cycle, and it is the single most common scheduling error.

Working backwards: allow three to five business days of testing for a small application, one to three weeks for your engineers to fix what matters, and a few days for the retest. A month inside the window is comfortable. A week is not.

Scoping for SOC 2 without overbuying

The scope should be the system in your description of the system, which for most SaaS companies is the product and the infrastructure it runs on. In practice that means the authenticated application including every user role, the boundary between customer tenants, the API, and the cloud environment hosting it.

What is frequently sold into SOC 2 scope and rarely belongs there: your corporate laptop fleet, if it is outside the system description; a full Active Directory assessment, if you have no corporate domain; and a red team engagement, which answers a different question entirely and is not what CC4.1 is asking for. If a readiness vendor has quoted you for all of these, ask them which criterion each one evidences.

What it costs

SOC 2 does not change the cost of testing, only the documentation you need from it. For a typical SaaS product, an application-scope engagement starts at $500 and covers the authenticated product, roles, tenant isolation and the API. Once cloud infrastructure or a corporate network is genuinely inside the system description, that becomes an infrastructure scope from $1,500.

Remediation support, the retest and the attestation letter are included rather than billed separately, which matters more here than on most engagements because those are precisely the artefacts the auditor is going to ask for. The SOC 2 penetration testing service page covers the testing itself in more depth, penetration testing cost explains the general pricing model, and the sample report shows the format an auditor will receive.

If you are also subject to PCI DSS, the two can frequently share one engagement, though the evidence requirements differ. See PCI DSS penetration testing cost, or compliance-driven testing for how overlapping frameworks are handled.

SOC 2 testing questions

Not by name. The Trust Services Criteria are deliberately written as outcomes rather than prescribed activities, and no criterion says the words "penetration test". In practice a test is the normal way organisations evidence CC4.1, which covers evaluations of whether controls are functioning, and it supports CC7.1 on detecting vulnerabilities and changes to configuration. Your auditor decides what satisfies the criteria, so the only definitive answer comes from them. Ask early, because the answer determines your scope and your timeline.
It changes the timing more than the test. Type I examines whether controls are designed appropriately at a point in time, so a recent test and a remediation plan generally suffice. Type II examines operating effectiveness across a period, typically three to twelve months, so the auditor wants to see the test, the remediation and the retest all falling within the observation window. Scheduling a test too late in a Type II window is a common and expensive mistake.
Usually four things: a defined scope that plausibly covers the system in your SOC 2 description, findings with severity ratings and a stated rationale, documented remediation with dates, and evidence the fixes were verified. An attestation letter stating what was tested and when ties it together. A report alone, with no remediation trail, is the most common reason this control gets a finding.
The framework does not change the underlying cost of testing, only the evidence you need from it. For a typical SaaS product that means an application-scope engagement from $500, or from $1,500 once cloud infrastructure or a corporate network is genuinely in scope. Firms that market a specific "SOC 2 pentest" product are usually selling the same test with the documentation packaged differently.
Annual testing is the common baseline that auditors accept, with an additional test after significant architectural change. Because Type II looks at a period rather than a date, the practical requirement is that evidence of testing and remediation exists within each observation window rather than that a test happens on a particular date.

Scoping a test for a SOC 2 window?

Bring your auditor's requirement and your observation window and I will scope backwards from the date.

Contact