SOC 2 and Penetration Testing: What Auditors Actually Expect

Every audit season, the same message lands in our inbox. A founder forwards a note from their auditor asking for “evidence of penetration testing,” the audit window closes in three weeks, and attached is a vulnerability scan from last quarter with the question: does this count? It does not. And that gap, between what a team assumes satisfies the requirement and what an assessor will actually sign off on, is where SOC 2 penetration testing quietly falls apart.

Let me say the unpopular part first. SOC 2 does not mandate a penetration test. There is no clause in the Trust Services Criteria that reads “thou shalt pentest annually.” What the framework demands is that you monitor for vulnerabilities and prove your security controls actually operate. A real pentest happens to be the cleanest evidence you can put in front of an auditor to show both, which is why almost every Type II report we support ends up leaning on one.

So stop asking “do I need a pentest for SOC 2.” Ask the two questions that matter: what does the test have to prove, and what does the report have to say.

Key takeaways

• SOC 2 never names penetration testing outright, but it requires vulnerability monitoring and evidence that controls operate, and a pentest is the strongest evidence for both.
• A pentest maps most directly to the Common Criteria on risk assessment and system operations, especially CC7.1, with support from CC3.2 and CC4.1.
• Auditors want scope that matches your production system boundary, plus proof that findings were tracked and fixed, not a tidy summary page.
• Annual testing is the accepted baseline, with a retest after significant changes and after remediating high and critical findings.
• A vulnerability scan is not a penetration test, and passing one off as the other is the most common reason evidence gets rejected.

What SOC 2 actually asks for

SOC 2 sits on the AICPA Trust Services Criteria. The Security category, the Common Criteria, is mandatory in every SOC 2 report. The criteria that touch testing live in the risk assessment and system operations areas.

CC7.1 is the one worth memorizing. It expects you to run detection and monitoring procedures that catch configuration changes introducing vulnerabilities and susceptibilities to newly discovered ones. A penetration test is a direct, defensible way to show you are doing exactly that against your own attack surface, instead of assuming your defenses hold. CC3.2 covers identifying and analyzing risk. CC4.1 covers ongoing evaluation of whether controls are working. A well-built pentest report speaks to all three at once. That is why assessors like receiving one.

Here is the part SOC 2 is genuinely fussy about: operating effectiveness over time. In a Type II report, which covers a review period rather than a single date, it is not enough to say a control exists. You have to show it did its job across the whole window. A test that surfaces real issues plus a remediation trail that closes them tells that story far better than a policy PDF ever will.

How a pentest maps to the Common Criteria

The recurring mistake is treating the pentest as a standalone artifact instead of wiring it to specific criteria. Auditors think in control mappings. So hand them the mapping.

Concretely: the scope and methodology section supports CC3.2, identifying and analyzing risk. The findings themselves are evidence for CC7.1, vulnerability detection. The remediation and retest activity supports CC7.4, responding to and resolving identified security issues. Structure the report so an assessor can point at a finding, then at the ticket that fixed it, then at the retest that confirmed the fix, and you have covered the thing that trips up most companies: proving the control operated, not just that it existed on paper.

The report an auditor loves is boring in the best way. Clear scope, real findings, tracked remediation, confirmed retest. No drama, full traceability.

What scope should a SOC 2 pentest cover?

Scope should mirror the system boundary described in your SOC 2 report. In practice that means your production application and the infrastructure behind it. If your SaaS platform, its API, and the cloud environment supporting it are all named in the report, they belong in the test. A pentest that quietly carves out the very thing your customers log into every day is a red flag, and an experienced assessor will catch it.

For most SaaS companies heading into SOC 2, that breaks down into a handful of concrete workstreams. A web application test across both the authenticated and unauthenticated surface, because broken access control and authorization flaws are what we report most often on these engagements. An API test, since so much of the real attack surface now hides in undocumented or under-tested endpoints. And, where it applies, an external network test of the internet-facing services in scope.

We nail the boundary down in writing before a single request goes out. The single biggest cause of an evidence dispute later is a fuzzy scope statement where nobody can say whether a component was in or out. Pin it down. List the in-scope hosts and applications. Note any carve-outs and the reason for each.

How we run it, and what shows up in the report

A SOC 2-aligned test still runs like an actual pentest, not a compliance ritual. We work from established methodology, the OWASP testing guides for web and API plus standard network methodology for infrastructure, pair automated tooling with manual verification, and confirm every finding by hand. Burp Suite for the interactive work, ffuf for content and parameter discovery, nuclei for sweeping known issues at scale. Those get us coverage. The criticals almost always come from the manual layer: chaining an authorization gap into another tenant’s data, or turning a verbose stack trace into an information leak that feeds the next step.

That manual work is exactly what SOC 2 is probing for. An auditor wants to know whether your controls hold up against a motivated attacker. A scanner flagging a weak TLS cipher does not answer that. A tester demonstrating that a low-privileged account can reach an admin-only function does.

Say a test account is scoped to account ID 1042 and we walk the object identifier by hand:

$ curl -s https://app.acme-corp.example.com/api/v2/accounts/1043/invoices \
    -H "Authorization: Bearer <low-priv-user-token>"

{"account_id":1043,"invoices":[ ... another tenant's billing data ... ]}

An insecure direct object reference like that, CWE-639, reads far more convincingly to an auditor than a page of scanner output. It shows a control that should have existed simply was not there.

The report needs a few specific things to survive audit review. A clear scope and boundary statement. A methodology description. Findings rated by severity, with enough technical detail to reproduce and to prove they are real, not theoretical. Remediation guidance per finding. Test dates that fall inside or sensibly before the audit period. And, ideally, a retest attestation confirming the high and critical items were closed. That last piece is what converts “we found problems” into “our control worked and we closed the gap.” That sentence is the entire SOC 2 narrative.

How often do you need to test for SOC 2?

Annually is the accepted baseline, and it is what most auditors expect for a recurring Type II report. Beyond the yearly cadence, retest after any significant change to the in-scope system, and retest to confirm remediation of high and critical findings. Ship major functionality mid-year and a test from before that release becomes weaker evidence for the current period. A sharp assessor will flag the mismatch.

For a first-time SOC 2, test during the readiness phase, before the observation window opens. You get time to fix findings and build a clean remediation trail, instead of scrambling to close criticals while the auditor is already watching.

How CyberXplore helps

We run SOC 2 penetration testing built to go straight to your auditor. Scope aligned to your system boundary, manual-led testing that catches what scanners miss, findings mapped to the relevant Common Criteria, and a retest to close the loop on high and critical items. If you are preparing for a Type I or Type II, our SOC 2 readiness service handles the testing and the evidence packaging together, so you are not stuck translating a raw pentest report into audit language yourself. When you are ready to scope it, get a quote and we will map the engagement to your report boundary and audit timeline.

FAQ

Does SOC 2 require a penetration test?

Not by name. SOC 2 requires you to monitor for vulnerabilities and demonstrate that your controls operate effectively, primarily through the Common Criteria such as CC7.1. A penetration test is the most direct and widely accepted way to produce that evidence, so most SOC 2 reports rely on one even though the standard never uses the exact phrase.

Is a vulnerability scan enough for SOC 2?

No, and this is the most common reason evidence gets pushed back. A scan lists known issues from a signature database. A penetration test adds manual testing, exploitation, and business-logic analysis a scanner cannot perform. Auditors increasingly know the difference and will ask whether manual testing was part of the work.

How often should we run a SOC 2 penetration test?

Annually is the baseline, plus a retest after significant system changes and after remediating high or critical findings. For a first audit, test during the readiness phase so you have time to fix issues before the observation window opens.

What should the pentest report include for the auditor?

A defined scope and system boundary, a methodology description, findings rated by severity with reproduction detail, remediation guidance, test dates within or before the audit period, and ideally a retest attestation. The remediation and retest trail is what proves the control actually operated, which is the heart of a Type II report.

Who defines the scope, us or the auditor?

You and your testing partner define it, but it has to match the system boundary in your SOC 2 report. If the audit covers your production application, API, and supporting infrastructure, the test should cover the same. Testing a narrower slice than the report describes is the classic scope mismatch that causes disputes later.