SOC 2 Penetration Testing: What Auditors Actually Check For (And Where Most Programs Fail)

Most SOC 2 pentest programs fail on missing retest reports, bad timing, or scope gaps. Here's what auditors ask and how to build audit-ready evidence.

_💥 _Master AI & Tech Skills 🎓 Get Up to 50% OFF Premium Courses ⏰ Limited-Time Offer 👉 Enroll Now & Start Learning

Day three of a SOC 2 Type II audit. The auditor pulls up the penetration testing section of the audit program and asks: "Can you show me evidence that exploitable vulnerabilities identified during your penetration test were corrected, and that the corrections were tested?"

Not "did you do a pentest." Not "can I see the report." The question is specifically about correction and verification.

The engineering lead can produce the pentest report without much trouble. A retest report that confirms each finding was actually patched and verified in production is harder to find. A documented timeline from finding to fix to verification, harder still. Evidence that the retest ran against the same environment, same methodology, as the original test, almost nobody has that on hand.

The control gets marked as an exception. The report ships with a qualified opinion on CC7.1. The enterprise sales cycle gets a little longer.

This plays out constantly, not because companies skip security testing, most don't, but because they run testing without understanding what SOC 2 specifically needs that testing to produce as evidence.

SOC 2 is an opinion, not a certificate

SOC 2 (Service Organization Control 2) is an AICPA auditing standard. It evaluates whether your controls meet the Trust Services Criteria relevant to your service. It is not a certification body handing out badges, it's an attestation: an independent CPA firm's formal opinion that your controls meet the criteria. That opinion is the report you hand to customers.

Five TSC categories exist. Security (CC) is mandatory. The other four are optional add-ons depending on what you handle:

Category Required? Pentest relevance Security (CC) Yes Direct — CC6, CC7, CC8, CC9 Availability (A) Optional Infra resilience, DDoS Processing Integrity (PI) Optional Business logic, data validation Confidentiality © Optional Data access, encryption Privacy (P) Optional PII handling, access verification

Here's the part that trips people up: SOC 2 barely uses the phrase "penetration testing" anywhere in its text. Companies search for an explicit line item, don't find one, and conclude testing is optional.

It isn't.

The requirement is implicit in CC6.6 (protection against external threats) and CC7.1 (detection of security events), and AICPA's supplemental guidance explicitly names penetration testing as an appropriate way to satisfy them.

Every Big Four firm and most regional CPA firms with a SOC 2 practice treat annual pentesting as table stakes for the Security category.

The real question was never whether you need a pentest. It's whether the one you ran generates the specific evidence an auditor is trained to look for.

Type I vs Type II: different questions entirely

Type I checks that a program exists and looks reasonable. You need: a written, dated, approved pentest policy; one completed test report inside the observation window; evidence the tester was qualified and independent; a finding list with severities; a remediation plan (doesn't need to be finished, just documented). Type I auditors will not ask for a retest report, proof that remediation worked, or evidence testing covered everything critical. They're checking existence and design, not execution.

Type II checks execution across the whole period, and the evidence bar jumps considerably:

• Pentest report(s) covering the observation period
• Evidence critical/high findings were actually remediated
• A retest report confirming remediation worked — the single most commonly missing item
• Timeline evidence: find date, fix date, retest date
• Remediation SLA documentation and proof you hit it
• Evidence the test covered systems that touch customer data
• Risk acceptance documentation for anything left unremediated

Common failure patterns at Type II, roughly in order of frequency: a pentest report exists but no retest report does; the retest didn't cover every original finding; remediation happened in staging, not production (production is what's audited, staging evidence doesn't count); remediation took longer than the stated SLA, which is worse than having no SLA; risk acceptances existed only verbally; the test ran against an older version than what's in production; the gap between the last test and the audit exceeds twelve months.

Timing rules nobody reads until it's too late

SOC 2 Type II has a minimum six-month observation period per AICPA guidance, though in practice enterprise buyers expect twelve. Your testing needs to produce evidence across that whole window, not one point inside it.

Three structural options, in order of evidence strength:

Rules that catch teams off guard:

1. The test must occur inside the observation period. A test run two months before your period started evidences the prior period, not this one.
2. For a twelve-month period, at least one test needs to land inside those twelve months.
3. The retest must also happen inside the period, after remediation.
4. The gap between your last test and period-end shouldn't exceed roughly six months. Beyond that, expect the auditor to ask about it.

The single most common mistake: running the pentest in Q1 for a Q1–Q4 audit period and never scheduling a follow-up. The auditor eventually asks what covered Q3 and Q4.

The honest answer, nothing, doesn't cause an automatic qualified opinion by itself, but it's a gap you'll have to explain, and it's rarely a satisfying explanation.

Fix: schedule a second test, or at minimum a targeted retest, around the six-month mark.

Scope: follow the data, not the architecture diagram

The scoping principle that matters more than any other: test everything that touches, stores, processes, or transmits the data your SOC 2 covers. Testing systems that don't touch customer data while skipping the ones that do is a scoping failure auditors catch quickly.

Two scope gaps auditors flag constantly: cloud infrastructure ("AWS manages that" is not a scope rationale, IAM misconfigurations and exposed buckets are CC6.1/CC6.6 findings and belong explicitly in scope) and APIs (most breaches happen at the API layer, but plenty of testing programs only cover what renders in a browser).

The retest report is the thing nobody has

If there's one document to obsess over, it's this one. Fixing a bug isn't the same as evidencing the fix worked.

The retest needs to come from the same external firm that ran the original test, re-executing the original test cases against the patched, production system, and producing a second report confirming which findings actually closed.

Internal QA can supplement this, it can't replace it.

What auditors actually ask, verbatim-adjacent

These aren't hypothetical. They're the standard interview pattern:

• "Do you have a penetration testing policy?" — wants a written, approved, dated document, not "yes, we do pentests"
• "When was your last test?" — wants a date inside the observation period
• "Who conducted it?" — wants a named external firm, not "our developer ran some scans"
• "How do you know remediations worked?" — wants a retest report, not self-attestation
• "Show me a critical finding remediated within your SLA" — wants discovery, fix, and retest dates all inside the policy timeline
• "What about findings you didn't fix?" — wants a signed risk acceptance with a named owner and compensating controls
• "Was the test conducted against production?" — many teams test staging to avoid disruption; auditors know this trick and ask directly
• "Did the test cover cloud infrastructure?" — app testing and cloud config review are not the same exercise
• "What version was running when the test occurred?" — a test of v1.2 doesn't evidence v2.8; put the version number in the authorization letter
• "Are you getting better year over year?" — wants CVSS severity trend data across periods; a flat or worsening trend is a flag in renewal audits

The pattern behind every good answer is the same: name the document, cite the date, name the firm, show the timeline. If you can't do that in one sentence, that's the gap.

Nearly every exception traces back to one of three root causes: no retest report, timing (test ran outside the observation window or was never followed up), or scope (staging instead of production, no cloud layer, browser-only coverage while the API sat untested).

Building the program by stage

First Type I audit. Start four months out, not four weeks.

Month one: write and approve the policy, pick a qualified external vendor, scope every system touching customer data, run the test.

Month two: triage findings with owners, remediate all criticals before the audit (highs strongly recommended), document risk acceptances for anything left, book the retest.

Month three: get the retest report, assemble the evidence package, get management sign-off on findings (minuted), hand it to the auditor.

Budget for a sub-50-endpoint SaaS: roughly $8K–$20K for the test, $2K–$6K for the retest, $1K–$3K for policy support if starting cold.

The most common failure at this stage is simply starting too late; four weeks isn't enough runway for test, remediation, and retest.

Growth stage, Type II with active shipping. A single annual test doesn't cover code shipped in month nine of a twelve-month period.

Reasonable structure: one comprehensive annual test as the baseline, quarterly targeted testing of high-change areas, a security review on any auth/authz change before release, and continuous DAST/SAST/SCA scanning filling the gaps.

The most common gap here is months seven through twelve with zero testing evidence, plus new features (a new payment flow, new auth method) shipped after the annual test with no review at all, which is a direct CC8.1 problem.

Enterprise, Type II with MSA obligations. Baseline SOC 2 requirements plus whatever your customer contracts separately demand, and these are two different obligation sets, don't conflate them.

Enhanced testing typically means external perimeter, internal network, API, and cloud reviewed together rather than separately, security testing embedded in the SDLC instead of bolted on annually, and a red team engagement every two to three years.

Some enterprise customers contractually require quarterly testing, full report access instead of an executive summary, specific tester certifications (CREST, for instance), or a 24–48 hour critical-finding notification window.

None of that is SOC 2, it's contract, and it needs its own evidence trail separate from the standard package.

Choosing a provider without guessing

SOC 2 doesn't name specific certifications. It requires a "qualified" party, and your auditor applies judgment to decide whether that bar was met, so you need a defensible case for your choice.

Non-negotiable floor: external to your org (internal or affiliated testers don't satisfy independence, full stop), a formal written report (a spreadsheet of findings is not audit evidence), and a formal retest included in scope, not "we'll review your remediation notes."

Signals worth paying for: CREST organizational certification, OSCP or CISSP on the individual testers, prior SOC 2-specific engagement experience (they should already know what "per-finding verification" means to an auditor, you shouldn't be the engagement where they learn it).

Questions worth asking before signing:

Can you show a sanitized sample report with unique finding IDs, CVSS scores, and proof-of-concept evidence (not scanner output with a paragraph slapped on)?

Is retest included and does it produce its own separate report?

Will you confirm in writing you're testing production?

What's your process when you find a critical mid-engagement (there should be an out-of-band escalation, not "wait for the final report")?

Will you provide a CVSS delta against last year's findings for renewal purposes?

Red flags that end the conversation: automated scanner output passed off as a formal report, no retest service, no unique finding IDs, an inability to map findings to specific TSC control numbers, a default to staging, no professional liability insurance.

The twelve mistakes that actually cause exceptions

Process failures, before the test runs: testing staging instead of production; skipping the retest or letting an internal team do it; leaving critical findings open at audit time (start 90 days out, not 30); running the test before the observation period even opens; switching testing firms every year, which kills your ability to show a CVSS trend.

Documentation failures, after the test: finding triage that happened but was never logged in a ticketing system; management review of the security posture that happened in someone's head instead of in minutes (CC5.3 needs the paper trail); risk acceptances that were a verbal "yeah, we'll live with that" instead of a signed document with a named owner; no sign-off that the scope actually covered customer-data systems.

Policy failures, the ones that look like organizational dysfunction: an SLA policy that says 48 hours for criticals next to a remediation log showing 30 days, which is worse evidence than having no SLA at all; a scope document that excludes cloud infrastructure with "AWS handles that" as the justification.

What a well-run engagement actually produces

A pentest built for SOC 2 evidence, not just technical findings, structures itself around the control mapping from the start: reconnaissance covering every external asset for CC6.6; source-level tracing of auth and authz flows for CC6.1/CC6.3; JS bundle analysis for leaked secrets and exposed endpoints under CC6.7; active exploitation with every finding confirmed working before it's reported, chained findings reported as chains (three mediums that combine into one critical shouldn't ship as three tickets your team deprioritizes); a report where every finding carries proof-of-exploit, root cause down to file and line, CVSS 4.0 with metric justification, and a mapping to the specific control ID, not a general "this relates to SOC 2."

Then unlimited retesting at no extra cost, with the retest confirming remediation in production specifically, and a named researcher sign-off, which is what satisfies the "qualified party" language in your own policy.

CodeAnt AI's penetration testing platform is built around exactly this evidence structure, which is also what makes running the semi-annual or continuous testing cadence operationally realistic instead of a once-a-year scramble.

The actual takeaway

Nobody fails a SOC 2 pentest control because their engineers can't find vulnerabilities. They fail it because the retest report doesn't exist, the test ran outside the observation window, or the scope quietly excluded the systems that actually touch customer data.

All three are process problems, not technical ones, and all three are fixable months before an auditor ever sits down across the table.

For a deeper breakdown of testing cadence tradeoffs referenced above, see continuous vs. annual penetration testing.

For what a retest engagement should actually contain, see what happens during a pentest retest.

Thank you for being a part of the community

Before you go:

👉 Be sure to clap and follow the writer ️👏️️

👉 Follow us: Medium

👉 CodeToDeploy Tech Community is live on Discord — Join now!

Disclosure: This post includes affiliate and partnership links.