EdgeBreach homeBook a demo

Insights · Compliance

SOC 2 Penetration Testing Requirements, Explained

Doug Collins · · 4 min read

A year of daily deploys shown against a single annual penetration test and a SOC 2 Type 2 observation period, with everything shipped after the pentest shaded

“Does SOC 2 require a penetration test?” comes up constantly with teams preparing for an audit, and the answers people find online contradict each other.

The short answer: the SOC 2 criteria don’t name penetration testing as a requirement, but most auditors expect to see one. The longer answer is more useful, because what the criteria actually ask for is evidence that your controls keep working as your environment changes. For a team that ships software every week, that’s a higher bar than one test a year.

Here’s what the source text says, so you can check it against your own situation. (This is a plain-language guide, not legal or audit advice. Your auditor has the final word on what satisfies a criterion in your environment.)

What the criteria say

SOC 2 reports are built on the AICPA’s Trust Services Criteria. The criteria themselves don’t mention penetration testing. It appears in the “points of focus,” the supporting guidance under each criterion.

CC4.1: monitoring your controls. This criterion asks organizations to perform “ongoing and/or separate evaluations” to confirm their controls are present and functioning. The 2022 revision of its points of focus lists the kinds of evaluations an organization might use. Depending on its objectives, those “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.”

That’s a menu, not a mandate. The AICPA is explicit that use of the criteria “does not require an assessment of whether each point of focus is addressed.”

CC7.1: finding new vulnerabilities. This one is more direct. It requires detection and monitoring procedures to identify “changes to configurations that result in the introduction of new vulnerabilities” and “susceptibilities to newly discovered vulnerabilities.” Its point of focus describes vulnerability scans run “on a periodic basis and after significant changes are made to the environment.”

Notice the shape of that language. It isn’t “once a year.” It’s “periodically, and after significant changes.”

What auditors expect in practice

In practice, most auditors expect a recent penetration test, and annual testing has become the customary baseline. But it’s custom, not text. As one SOC 2 audit firm put it, “it is up to individual audit firms (CPA firms) to decide” whether to require one, and some will accept another form of periodic security assessment instead.

That flexibility cuts both ways. It means you can’t assume your auditor will accept a minimal program, and it means you shouldn’t assume a single annual test is the ceiling of what’s useful. Ask your auditor early what they expect to see, how recent it needs to be, and what scope it should cover.

Why Type 2 changes the question

SOC 2 reports come in two types, and the difference matters here.

A Type 1 report evaluates whether your controls are suitably designed “as of a point in time.”

A Type 2 report evaluates whether those controls “operated effectively throughout the period of time” under review, and includes the auditor’s tests of controls and their results. The AICPA’s guidance notes that for a period shorter than two months, an auditor may conclude that sufficient evidence is unlikely to be obtainable, so most Type 2 periods run for several months to a year.

Now picture a twelve-month Type 2 period with one penetration test in month two. The test tells your auditor, and your customers, that the application was in good shape on the day it was tested. It says much less about months three through twelve, when your team was shipping new endpoints, new integrations, and new permission logic every week.

That’s the velocity gap, applied to an audit. A Type 2 report is a claim about a whole period. Point-in-time testing is evidence about a single day.

A practical checklist

Ask your auditor first. Find out what testing they expect, how recent it needs to be, and what report format they want, before the testing happens.

Define “significant change” for your team. CC7.1’s own guidance ties scanning to significant changes. Write down what counts in your environment (a new service, a new data flow, a new third-party integration, a change to authentication), so the decision to test is documented rather than improvised.

Match testing to the period, not just the year. For a Type 2, evidence that testing kept pace with your changes across the whole period is stronger than a single snapshot.

Keep the evidence and retest after fixes. A finding that’s closed with a retest is far more convincing to an auditor than a finding that’s simply marked resolved.

Remember who reads the report. Your customers’ security teams read your SOC 2 report too. A test from eleven months ago, for an application that ships weekly, is exactly what a careful reviewer will ask about.

Where EdgeBreach fits

EdgeBreach is continuous penetration testing built on our own reasoning model, trained specifically for software vulnerabilities. It produces audit-ready reports for frameworks like SOC 2, and it runs as often as you ship, so the changes you make during an audit period get tested during that period. You can run it alongside an annual pentest or rely on it on its own; that’s your call, and your auditor’s.

EdgeBreach is continuous penetration testing built on our own reasoning model, trained specifically for software vulnerabilities. To see what it finds in your environment, book a demo.

Sources