Does SOC 2 Require a Penetration Test? What Auditors Actually Expect

SOC 2 never names penetration testing, yet auditors expect it as evidence for CC4.1 and CC7.1. Here's what actually satisfies the Trust Services Criteria.

Rachel Osei· GRC ConsultantMay 16, 2026· Updated July 20, 202614 min read

TL;DR

SOC 2 never uses the words "penetration test." The framework is built on the AICPA Trust Services Criteria, which describe outcomes, not tools. But two common criteria push hard toward testing: CC4.1 (monitoring activities) lists penetration testing among its points of focus, and CC7.1 (vulnerability detection) expects you to find configuration changes and newly discovered vulnerabilities. A scoped pentest plus continuous scanning is the cleanest way to produce that evidence — and for a Type II report, auditors want to see testing and remediation across the whole audit period, not a single snapshot.

Does SOC 2 require a penetration test?

Technically no, practically yes. SOC 2 does not explicitly or literally mandate a penetration test — the AICPA Trust Services Criteria never name "penetration testing" as a required control. What the criteria require are outcomes: management must evaluate whether controls are present and functioning, and the organization must detect vulnerabilities and configuration changes that introduce new risk. A penetration test happens to be the most widely accepted evidence that those outcomes are being met. Show up to a Type II audit without one and, in practice, expect your auditor to ask where it is — and expect prospects to ask for it during vendor security reviews regardless of what the standard says on paper.

The nuance matters because it changes how you should think about scope, frequency, and evidence. You are not "checking a box called pentest." You are producing artifacts that let an auditor conclude your monitoring and vulnerability-management controls operated effectively. Understanding which criteria a pentest supports — and where a pentest alone falls short — is what separates a clean report from a qualified opinion.

Key takeaways

SOC 2 does not literally require a pentest. The AICPA Trust Services Criteria describe outcomes, not specific tools or techniques.
CC4.1 is the anchor. Its points of focus explicitly cite penetration testing as an example of a "separate evaluation" of internal controls.
CC7.1 covers vulnerability detection — finding configuration changes and susceptibility to newly discovered vulnerabilities, which is where scanning earns its keep alongside a pentest.
Security is the only mandatory Trust Services Criteria. The other four (Availability, Processing Integrity, Confidentiality, Privacy) are in scope only if you elect them.
For a Type II report, the pentest must fall inside the observation period. A test dated before the window generally will not count as evidence for it.
Remediation and retest close the loop. A report full of open criticals is weaker than a smaller report where findings are fixed and independently re-validated.
Scanning and pentesting are not interchangeable. Auditors expect to see both, mapped to different criteria and doing different jobs.

What are the Trust Services Criteria, and which relate to pentesting?

SOC 2 is evaluated against the AICPA Trust Services Criteria (TSC), published as TSP Section 100 and last revised with updated points of focus in 2022. There are five criteria categories, and you choose which apply to your report based on the commitments you make to customers:

Trust Services Criteria	Required?	Relevance to penetration testing
Security (Common Criteria, CC1–CC9)	Always required	High — this is where all the pentest-relevant controls live
Availability	Optional	Moderate — resilience and DoS testing can support it
Processing Integrity	Optional	Low–moderate — logic and input-validation flaws can be relevant
Confidentiality	Optional	Moderate — access-control and data-exposure findings map here
Privacy	Optional	Low–moderate — matters where personal data handling is tested

The Security category — universally called the Common Criteria because its controls are shared across all five categories — is the only mandatory one, and it is where penetration testing does most of its work. Within the Common Criteria, two sections carry the weight for testing:

CC4.1 (Monitoring Activities). This criterion requires the entity to select, develop, and perform ongoing and/or separate evaluations to confirm that components of internal control are present and functioning. It descends from COSO Principle 16. Critically, the AICPA's points of focus for CC4.1 list penetration testing as one example of a separate evaluation, alongside items like independent certifications and internal audit assessments. This is the single clearest place the standard nods at pentesting.
CC7.1 (System Operations / Vulnerability Detection). This criterion expects the entity to use detection and monitoring procedures to identify (1) changes to configurations that introduce new vulnerabilities and (2) susceptibility to newly discovered vulnerabilities. Its points of focus call for defined configuration standards, monitoring of infrastructure and code, and vulnerability scans run on a periodic basis and after significant change.

A useful mental model: CC4.1 is "did we evaluate whether controls work?" and CC7.1 is "can we detect vulnerabilities and configuration drift?" A pentest is strong evidence for CC4.1; ongoing scanning is strong evidence for CC7.1. You want both, and they support each other rather than compete.

How does pentest evidence map to specific common criteria?

Auditors do not accept a pentest report as a blanket "we're secure" artifact. They map specific findings and activities back to specific criteria. Here is how a typical engagement lines up:

Common Criteria	What it expects	How pentesting / scanning maps
CC4.1 — Monitoring activities	Ongoing/separate evaluations of controls	The pentest is the separate evaluation; the report is the artifact
CC7.1 — Vulnerability detection	Detect config changes and new vulnerabilities	Recurring vulnerability scans; pentest confirms exploitability
CC6.1 — Logical access controls	Restrict access to authorized users	Auth, session, and privilege-escalation findings test these controls
CC6.6 — Boundary protection	Protect against external threats	External network and perimeter testing
CC6.8 — Unauthorized/malicious software	Detect and prevent unauthorized software	Findings on unmanaged components and injection points support this
CC7.2 / CC7.4 — Monitoring and incident response	Detect and respond to anomalies	A pentest exercises whether your detection and response actually fire

The practical lesson: a well-written pentest report is not one piece of evidence, it is several. When your remediation tracker, scan cadence, and pentest findings all reference the same criteria, the auditor's job gets easy — and easy audits are clean audits.

What's the difference between Type I and Type II expectations?

The report type changes what "enough testing" means. A Type I report assesses whether controls are designed appropriately at a single point in time. A Type II report assesses whether those controls operated effectively across a period — typically three to twelve months.

	Type I	Type II
What it assesses	Control design at a point in time	Control operation over a period
Typical window	A single date	3–12 months (observation period)
Pentest evidence	A current test showing controls exist	Testing that falls inside the period, plus remediation
Auditor question	"Is this designed to work?"	"Did this actually work the whole time?"
Practical cadence	One assessment	Test after major changes; close findings on an SLA

For Type II, timing is everything. A penetration test dated two months before your observation period opened generally will not serve as evidence for that period — the auditor needs testing that occurred while the window was open. A common practitioner recommendation is to schedule the test around month three or four of a twelve-month observation period, which leaves your engineering team a full remediation window before the auditor reviews controls near period end.

A single annual pentest maps awkwardly onto a Type II period. It can leave the majority of the observation window without fresh testing evidence. Auditors increasingly want to see that you tested after significant changes and closed findings on a defined SLA — not just once, twelve months ago.

How do you scope a SOC 2 pentest and set rules of engagement?

Scope is where audits quietly go wrong. The golden rule: your pentest scope must be consistent with your system description and data-flow diagrams. Auditors compare the two. If your system description says customer data flows through three services but your pentest only touched one, that gap gets flagged.

A defensible scope and rules of engagement (RoE) document should cover:

In-scope assets — the applications, APIs, network ranges, and cloud accounts that store or process in-scope data. For cloud estates, common gaps like publicly exposed storage buckets belong squarely inside this boundary.
Test perspective — external (unauthenticated / black-box) versus internal or authenticated (grey/white-box). SOC 2 gives you latitude here; authenticated testing generally yields deeper coverage of access controls.
Methodology — a recognized standard (for example the OWASP Top 10 for web and API testing, or a network methodology) so the auditor can see rigor, not ad-hoc poking.
Timing and constraints — test windows, rate limits, and any production-safety guardrails, agreed in writing before testing starts.
Exclusions and why — anything out of scope should be justified, not just quietly omitted.

Do not scope your pentest to only the easy or low-risk systems. The fastest way to draw an auditor's scrutiny is a pentest scope that is conspicuously narrower than the boundary described in your SOC 2 report. Match the scope to the data.

How often do you need a pentest for SOC 2?

Annually, at minimum — plus after any significant change. SOC 2 itself does not state a frequency, but the practical baseline auditors expect is a full assessment at least once every twelve months, with additional targeted testing after material changes to architecture, authentication, or the systems handling in-scope data.

Why do auditors accept "current" evidence rather than demanding continuous manual testing? Because CC7.1's points of focus explicitly frame vulnerability detection as something done periodically and after significant change — the standard is built around a rhythm of ongoing monitoring punctuated by deeper evaluations, not a single perfect moment. That is precisely why a once-a-year manual pentest paired with continuous automated scanning is such a common pattern: the annual test provides depth, and the continuous scanning provides the period-wide coverage that a Type II report demands.

What must a SOC 2 pentest report contain for auditors?

A report an auditor can actually use is more than a list of vulnerabilities. Expect your provider to deliver — and ask before you engage — the following:

Scope and methodology — what was tested, from what perspective, using which standard, over what dates.
An executive summary — risk in business terms, suitable for the audit file.
Reproducible findings with severity ratings — enough detail that a finding can be independently verified and re-tested, each rated (for example CVSS or a defined scale).
Remediation guidance — actionable fixes, not just problem statements.
Evidence of independence — who performed the test and their qualifications; auditors value independence and a clear methodology.
A retest / validation report — the artifact proving findings were fixed.

Keep the report, the signed scope/RoE, and the remediation trail together as a single audit-ready evidence package. When they arrive as one bundle, the auditor spends minutes verifying rather than hours reconciling.

What do auditors expect for remediation and retest?

Discovery is half the job; closure is the other half, and auditors weigh it just as heavily. The expectation is a demonstrable, closed-loop process: each finding has an owner, a severity-based SLA, a fix, and independent confirmation the fix worked. You generally cannot self-attest that a vulnerability is gone — the credible proof is a retest by the independent testing firm confirming the finding is remediated.

This is why a remediation log matters as much as the pentest itself. It should show, per finding: severity, owner, remediation date, and retest outcome. A report where every high and critical is fixed and re-validated tells a far stronger story than a longer report full of open items — even if the second report technically "found more."

Pentest vs vulnerability scan: what's the difference for SOC 2?

These are not interchangeable, and auditors know it. Conflating them is a common reason evidence gets pushback.

A vulnerability scan is automated and breadth-first. It enumerates known weaknesses and misconfigurations across your estate, quickly and repeatably. It maps most naturally to CC7.1 — ongoing detection of vulnerabilities and configuration drift, run periodically and after change.
A penetration test is human-led and depth-first. A tester chains findings, validates real exploitability, and probes business logic a scanner cannot reach. It maps most naturally to CC4.1 — a separate evaluation confirming controls actually hold up under adversarial pressure.

Neither one alone is sufficient. A scan without a pentest lacks depth and exploit validation; a pentest without ongoing scanning lacks the period-wide coverage a Type II report needs. Auditors expect to see both, doing different jobs and mapping to different criteria.

Frequently asked questions

Does SOC 2 explicitly require a penetration test?

No. Neither the Trust Services Criteria nor TSP Section 100 names penetration testing as a mandatory control. The requirement is to evaluate controls (CC4.1) and detect vulnerabilities (CC7.1). A pentest is the evidence most organizations use to satisfy those outcomes — which is why it feels mandatory in practice even though it is not written as such.

Which Trust Services Criteria does a pentest support?

Primarily the Security / Common Criteria: CC4.1 (monitoring activities, which lists penetration testing in its points of focus) and CC7.1 (vulnerability detection). Findings frequently also support access-control and boundary criteria such as CC6.1, CC6.6, and CC6.8, depending on what the test uncovers.

How often do I need to run one for SOC 2?

At least annually, and again after significant changes to in-scope systems. Continuous scanning between annual tests strengthens Type II evidence considerably because it demonstrates detection across the entire observation period rather than at a single point.

Does the pentest have to happen during the audit period?

For a Type II report, effectively yes — the testing evidence should fall inside the observation period to count for it. Many teams schedule the test early in the period (around month three or four) to leave room to remediate and, if needed, retest before the window closes.

Can automated testing replace a manual pentest for SOC 2?

It complements rather than fully replaces it. Automated and continuous testing covers the gaps between deeper manual assessments and provides period-wide evidence, but auditors still expect the depth and exploit validation a skilled human tester provides. The strongest posture combines both.

Who is allowed to perform the pentest?

An independent, qualified party. Internal teams can perform testing, but auditors place a premium on independence, recognized methodology, and a clear separation between those who build the systems and those who evaluate them. Whoever performs it, keep the scope, report, and remediation trail together.

What happens if I show up to the audit without a pentest?

You are unlikely to fail purely for the absence of a document called "pentest," but you will need some credible evidence that satisfies CC4.1 and CC7.1. In practice, most auditors will ask for a penetration test, and lacking any equivalent evaluation is a common path to findings around monitoring and vulnerability management.

Continuous, current, audit-ready evidence is what turns a SOC 2 pentest from an annual scramble into a byproduct of how you already operate. When testing and remediation are ongoing, the artifacts an auditor needs for any month of the period are simply there when asked.