Is a security assessment required before a SOC 2 audit?

SOC 2 does not explicitly mandate a penetration test, but its Common Criteria expect a working vulnerability-management process. A non-intrusive external exposure audit beforehand reduces the risk of auditor exceptions by surfacing exposed services, misconfigurations, and forgotten assets before the observation period begins.

Should I run an external exposure audit or a penetration test for SOC 2?

Most teams run the external exposure audit first — it is fast, external-only, and non-intrusive, and it cleans up obvious exposure before the audit. A penetration test follows if your auditor or a key customer specifically requires exploit-level evidence.

← Blog

June 24, 2026 · Prox Offensive · Compliance, Guides

Security Assessment Before a SOC 2 Audit: What You Actually Need

Q: Does SOC 2 require a penetration test?

Not by name. The Trust Services Criteria (notably CC7.1) require that you identify and remediate vulnerabilities; auditors and enterprise customers commonly expect evidence of testing, which is why vulnerability scanning and often a penetration test appear in most SOC 2 engagements.

SOC 2 doesn't name a penetration test as a hard requirement — but its criteria expect vulnerability management, and an external exposure assessment beforehand is the cheapest way to avoid findings. Here's what to run, and when.

Key takeaways

SOC 2 does not explicitly mandate a penetration test by name — but the Security (Common) Criteria expect you to identify, evaluate, and remediate vulnerabilities, and most auditors and customers expect evidence of testing.
An external exposure assessment before the audit is the cheapest insurance — it surfaces the obvious internet-facing issues (exposed admin panels, weak TLS, missing headers) that would otherwise become audit findings or customer-review red flags.
Run the exposure assessment first, fix the quick wins, then test deeper if your auditor or customers want a full penetration test.

Does SOC 2 require a penetration test?

This is the most common question we hear, and the honest answer is: not by name. SOC 2 is built on the AICPA’s Trust Services Criteria. The Security category — the “Common Criteria,” mandatory for every SOC 2 report — never says “you must run a penetration test.”

What it does require is that you can demonstrate a working process for managing vulnerabilities and monitoring your environment. In practice, two criteria drive most of the relevant evidence:

CC7.1 — you identify and evaluate vulnerabilities and configuration changes.
CC4.1 / CC7.2 — you monitor your systems and detect anomalies.

So while the framework is technology-neutral, your auditor will ask how you find and fix exposed weaknesses. “We don’t” is not an answer that passes. That’s why vulnerability scanning, and often a penetration test, show up as evidence in nearly every SOC 2 engagement — and why enterprise customers increasingly ask for a recent test during vendor security reviews.

Why run an external exposure assessment before the audit

Discovering problems during your SOC 2 window is the expensive way to find them. An external exposure assessment is a fast, low-cost way to see what your auditor — and any attacker — will see first:

Exposed administrative interfaces reachable from the public internet
Outdated TLS/SSL configurations and weak ciphers
Missing security headers that fail automated compliance scans
Forgotten subdomains and shadow infrastructure outside your asset inventory
Information disclosure from verbose errors and misconfigurations

These are exactly the kinds of issues that turn into findings, remediation deadlines, or a stalled customer deal. Catching them before the audit period lets you fix the quick wins on your own schedule rather than under audit pressure — and it strengthens the asset inventory and vulnerability-management story your auditor wants to see.

Exposure assessment vs. penetration test for SOC 2

Both have a place; they answer different questions.

External Exposure Audit — broad, external-only, non-intrusive. Best as your first step: it maps what’s reachable and misconfigured across your public footprint and gives you a prioritized fix list. Fast and affordable, so it’s ideal for getting clean before an audit.
Penetration Test — deeper and goal-driven, often authenticated. Best when your auditor or a key customer specifically expects evidence of exploit-level testing, or when you need to prove real-world impact.

For most teams approaching their first SOC 2, the smart sequence is: exposure assessment → remediate → (if required) penetration test. You don’t want to pay for deep testing of assets you didn’t even know were exposed.

A practical pre-SOC 2 sequence

Map your external exposure — get an accurate inventory of internet-facing assets and their misconfigurations.
Fix the quick wins — the 48–72 hour items (headers, TLS, exposed panels) that reduce findings immediately.
Document your vulnerability-management process — scanning cadence, triage, remediation, verification. This is the evidence CC7.1 asks for.
Run a penetration test if expected — for stronger assurance or to satisfy a specific customer requirement.
Re-verify — confirm each fix actually closed the issue before your audit window.

How we help

Our External Exposure Audit Sprint is built precisely for step 1 — a fixed-scope, external-only review that delivers a prioritized findings list, a quick-wins checklist, and a 30-day remediation roadmap in 3–5 business days. It’s designed for teams preparing for compliance audits (SOC 2, ISO 27001, PCI) who need clarity on their exposure without the complexity of a full penetration test.

You can see exactly what you’d receive, read about our evidence-based methodology, or step up to a deeper penetration test when your auditor or customers require it.

This article is general guidance, not compliance advice — your auditor’s expectations and your customers’ requirements should drive the specifics of your program.