Nothing in the AICPA's Trust Services Criteria requires a penetration test. CC4.1 names it as an example of an evaluation, not a mandate. Every auditor you will meet expects one anyway, and the artifact they file proves something much narrower than the opinion around it: a few weeks of adversarial attention, sampled once, inside a Type II report attesting to 3 to 12 months of control operation.
I've scoped these engagements and watched clean opinions ship for products that deployed exploitable code two weeks after the testers left. The gap is structural. You can close most of it without buying fifty-two manual tests a year.
What the auditor is actually asking
Strip the paperwork and the auditor wants four answers: do you test regularly, triage by severity, remediate on a defined timeline, and verify the fix. One annual test answers the first question weakly and says nothing about the other three for the remaining 364 days. That silence is the assurance gap.
Things founders get backwards:
- Critical and high findings are fine. An unresolved critical sitting open inside the period is what produces an exception.
- A zero-findings report invites harder scope questions than a bloody one. It suggests nobody was trying.
- Auditors diff the pentest scope against your system description line by line. Description says web app, API, and cloud, but only the web app got tested? That's the most common first-attempt failure.
Where the gap opens
Scope freeze. Scope is signed weeks before the test window. By the time the auditor reads the report, it describes a system that no longer exists. Scoping is a contracting event; your codebase is a continuous process.
Retest theater. A retest confirms a fix at retest time. Six weeks later a refactor rewrites the endpoint and your evidence describes dead code. My position: a retest proves a commit, not a control. If the code holding the finding changes again inside the period, the evidence chain has a hole whether anyone checks or not.
The cadence problem got worse. The official trigger list (retest after major app, API, auth, or infra changes) was written for quarterly releases. AI-assisted development ships more code per engineer and entirely new feature classes, and a manual test runs $10k to $30k. So teams quietly redefine "significant" to mean "nothing until next year," and the tested system drifts further from the running one every sprint.
A framework you can defend twice
Once in the audit, once after an incident.
- Schedule by period math. On a 12-month period, test in months 1-4, close remediation and retesting by month 6. The fix loop must close inside the window.
- Write your significant-change triggers down, with an owner. Mine: new internet-facing service, any authn/authz model change, new cloud account or network boundary, new vendor integration touching customer data, major dependency migration. Trigger fires, scoped retest within 30 days. The 30 is my number, not a standard. What matters is that a number exists before the trigger fires.
- Put severity SLAs in writing. Critical in 7 days, high in 30, everything else scheduled or formally risk-accepted with an expiry on the acceptance. An undocumented SLA is indistinguishable from no SLA.
- Keep evidence as a standing folder, not a two-week scramble before fieldwork:
soc2-evidence/
2026/
pentest/
scope-and-methodology.pdf
final-report.pdf
remediation-tickets-export.csv
retest-results.pdf
risk-acceptance-RA-003.pdf
between-tests/
change-trigger-log.md
scoped-retest-2026-04.pdf
continuous-scan-summary-Q1.pdf
The between-tests/ folder is the actual point. It gives the other 364 days a paper trail so the period isn't blank between manual engagements. Then make the honest regime call: monthly releases and a stable surface, annual testing plus trigger retests is defensible. Shipping daily or integrating LLM features, you need continuous exposure evidence between engagements, because the annual cadence no longer matches your deploy rate.
Do this week:
- Diff your last pentest scope against your SOC 2 system description. Mismatch? Fix the next SOW before signing.
- Write down five change triggers and name an owner for each.
- Put severity SLAs in a doc, with an expiry on every risk acceptance.
- Create the
between-tests/folder, even if it's empty. Empty shows you the gap.
What does your team count as a "significant change," and has that definition ever survived a real sprint?
Longer writeup with the full argument: https://axeploit.com/blog/your-soc-2-pentest-proves-a-week-the-report-implies-a-year
