What a SOC 2 auditor actually wants from your penetration test

Here is the sentence that confuses almost everyone the first time through this: the SOC 2 Trust Services Criteria do not, anywhere, explicitly require a penetration test. And yet almost no company gets through a SOC 2 Type II audit — or an enterprise security questionnaire — without producing one. Both are true at once, and understanding why is most of what you need to navigate this without wasting money.

Why you need one anyway

SOC 2's CC7.2 control asks you to demonstrate that you "monitor system components for anomalies that are indicative of malicious acts, natural disasters, and errors." It does not name a penetration test as the method. It does not have to — in practice, a penetration test is the cleanest, most auditor-recognizable way to demonstrate that a control exists and actually works, rather than exists only on paper.

So the requirement is indirect but the outcome is not: your auditor will expect evidence of testing, your cyber insurance renewal will often ask for it directly, and any enterprise customer's security team reviewing you before a contract will almost certainly have "penetration test within the last 12 months" as a checkbox on their vendor questionnaire. Skipping it does not make the audit easier. It just moves the same question to a later, more awkward point in the sales process.

Scope: the decision that determines everything else

Before any testing starts, scope is the single decision with the most leverage over cost, timeline, and whether the report will actually satisfy the person reading it. Get this wrong and you either pay for testing nobody asked for, or you hand over a report that gets bounced back with "this doesn't cover what we need."

Scope has to answer, specifically, in writing, before testing starts:

• Which systems are in the SOC 2 boundary? A production API and customer-facing web app almost always are. An internal admin tool that never touches customer data sometimes is not — that is a decision for you and your auditor to make together, not something a testing firm should quietly assume.
• External, internal, or both? External means the internet-facing attack surface. Internal means what someone already inside — a compromised laptop, a malicious insider — could reach. Most SOC 2 windows call for external at minimum; internal depends on your architecture and what your auditor asks for.
• Web application, API, or both? These are different disciplines with different methodologies. If your product is API-first with a thin frontend, a UI-only test will miss almost everything that matters.
• Authenticated testing or not? A test with no valid login only sees what an anonymous outsider sees. Almost everything interesting in a modern SaaS product — access control between tenants, privilege boundaries between roles — is invisible without test accounts at each permission level.

Every one of those answers should be written down in an engagement scope document before the first request goes out, not reconstructed afterward from what happened to get tested.

The difference between a scan and a test, restated for this audience

This distinction matters more here than almost anywhere else, because it is also the most common way companies get sold something cheaper than what their auditor actually needs. A vulnerability scan runs known signatures against your systems and reports what matched — genuinely useful, genuinely fast, and genuinely not what most SOC 2 auditors and enterprise security teams mean when they ask for a "penetration test."

A scan cannot find that a customer on one tenant can read another tenant's data by changing an ID in a URL — that requires understanding your specific authorization model, not matching a signature. It cannot find a business-logic flaw in a checkout flow, because there is no generic signature for "your process is missing a check." A test is a person, using scanning tools as one input, then reasoning about your application the way an attacker would. A report that reads like a scanner printout — CVEs with no narrative, no chained findings, no evidence of manual verification — will get pushed back by anyone who has seen a real pentest report before.

What the report must contain

This is the checklist we run against our own deliverables, and it is a reasonable one to hold any provider to, because these are the specific things an auditor or a customer's security reviewer will look for:

Retest: the step people try to skip

A first-round report with unresolved findings does not satisfy most SOC 2 auditors on its own — they want to see that findings got fixed, and that someone verified the fix rather than trusted it. This is not box-checking. Fixes fail more often than people expect: a patch closes the specific reproduction path but leaves the underlying logic error in a slightly different form, or a fix is deployed to staging and never promoted, or it is correct but a regression a month later quietly reopens it.

A retest is a second, shorter engagement that re-runs the specific findings from the original report to confirm each one is actually closed, and it is the piece of evidence that turns "we had some findings" into "we had findings and we can prove they're resolved." If a provider's quote does not include a retest, or prices it as a separate large engagement rather than a lighter-weight verification pass, ask why — auditors specifically look for this step, and treating it as optional is treating the part they actually check as optional.

The honest boundary

This is worth saying plainly, the same way we say it in every engagement: Quantis Sphere is not a QSA (Qualified Security Assessor for PCI), an ASV (Approved Scanning Vendor), or a CPA firm. We do not issue SOC 2 attestations, PCI Reports on Compliance, or any other formal compliance certification — those specifically require a licensed firm authorized to issue them, and no penetration test provider, however good the testing, can substitute for that license.

The honest answer costs us nothing to say and saves you from finding out the hard way, three weeks before your audit window closes, that a report doesn't cover what your auditor actually needed.

If you are heading into a SOC 2 window, renewing cyber insurance, or answering an enterprise customer's security questionnaire and need a report that will actually hold up, that is exactly the conversation our security testing starts with — scope written down first, methodology stated plainly, retest included, no certification we are not licensed to give.