Nothing in the AICPA's Trust Services Criteria requires a penetration test. Every auditor you will meet in 2026 expects one anyway. And almost nobody talks about what the artifact proves once it lands in the evidence folder: a few weeks of adversarial attention, sampled once, inside a Type II opinion that attests to 3-12 months of control operation.
I have scoped these engagements, sat through the auditor interviews, and watched clean opinions ship for products that deployed exploitable code two weeks after the testers left. This piece is about that gap, and how to close it without buying things you do not need.
The requirement that isn't one
Start with the text. CC4.1 (Monitoring Activities) names penetration testing first in its list of example ongoing and separate evaluations. It is an example, not a mandate. The criteria can technically be satisfied through internal audit, third-party certifications, or continuous monitoring, and vulnerability scanning is not explicitly required either.
None of that survives contact with an actual audit. By 2026 the de facto standard for a Type II is an annual pentest plus testing after significant environment changes. SOC 2 itself is voluntary, but enterprise buyers gate deals on the report, which makes it mandatory for practical purposes across US B2B SaaS. Type I reports on controls at a point in time. Type II covers whether they operated effectively across a 3-12 month period, and that period is where the trouble starts.
Every neighboring framework is more explicit. PCI DSS v4.0 Requirement 11.4 mandates annual testing plus retesting after significant changes, covering the cardholder data environment and segmentation controls. ISO 27001 gets there through Annex A.12.6.1 and A.18.2.3, FedRAMP requires it annually across the entire cloud service offering boundary, and HIPAA implies it through the Security Rule's risk analysis. SOC 2 stays silent and lets the auditor set the bar.
They set it because of liability. A clean opinion followed by a breach invites questions about whether the audit was thorough, and the absence of penetration testing often turns into qualifications or a requirement to add it in future periods. So treat the pentest report for what it is: a document written for the auditor's file, protecting their signature as much as your perimeter.
What the artifact proves to an auditor
The accepted minimum is an annual external and web application test with a formal report, remediation evidence, and retesting of critical findings. The full package auditors expect you to retain: scope, methodology, the final report, remediation tickets, retest results, risk acceptance records, and an attestation letter or executive summary.
Read strictly, that package proves five things. Testers worked these dates, against this scope, with this methodology. You triaged findings by severity. You remediated on a timeline, tracked in a ticketing system with assignees and due dates (Jira, Linear, Asana, it does not matter which). Someone verified the fixes in a retest. Where you declined to fix, you recorded risk acceptance.
What it does not prove is that the system resisted anything on any other day of the period. The opinion says controls operated effectively across 3-12 months, with exceptions noted. It never says no exploitable vulnerability existed during that time, and everyone in the audit meeting knows it.
The constraints are mechanical. The test must fall inside the examination period; a 14-month-old test does not count. Schedule within the first six months of a 12-month period so remediation and retesting close before the window does. Auditors compare the scope against your system description line by line: if the description lists a web app, an API, and cloud infrastructure but only the web app was tested, the gap gets noted. Incomplete scope is the most common reason a first attempt fails review, usually because the public site was tested while internal APIs, admin panels, and the controls isolating sensitive systems were not.
Severity expectations run opposite to what founders assume. Critical and high findings are expected and fine. An unresolved critical sitting open inside the period is what produces an exception. In my experience a zero-findings report invites harder scope questions than a bloody one, because it suggests the test was not trying. And depending on what you attest, the bar shifts: Availability brings expectations of denial-of-service and resilience testing (A1.2), Confidentiality brings access control and data protection testing (C1.1).
The four questions behind the checklist
Strip the paperwork away and the auditor is asking four things: 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.
Where the gap opens
Scope freeze
Scope is negotiated and signed weeks before the test window. By kickoff the application has already moved; by the time the auditor reads the report, it describes a system that no longer exists in that form. This is structural, not sloppy. Scoping is a contracting event and your codebase is a continuous process. The third-party integrations alone, each one an OAuth grant or API key into customer data, change monthly for most SaaS products, and they are exactly the surface that tends to escape the scope document.
One sample inside a long period
Type II attests to controls operating across the whole period. The pentest is a single separate evaluation sampled from a narrow window inside it. Auditors understand sampling, which is why they also pull change tickets, incident records, and scanning output for the rest of the period. One test is one data point, and everyone treats it that way except the sales deck quoting the report.
Retest theater
A retest confirms a fix at retest time. Six weeks later a refactor rewrites the endpoint, and your retest evidence now describes dead code. The weaker version is worse: tickets closed with "fixed" and no verification at all. My position after years of this: a retest proves a commit, not a control. If the code that held the finding changes again inside the period, the evidence chain has a hole whether anyone checks or not.
Why the annual cadence broke in 2026
The official cadence is annual, plus after major application, API, cloud, authentication, authorization, or infrastructure changes. That trigger list was written for quarterly releases. AI-assisted development now pushes teams to ship more code per engineer and entirely new feature classes, LLM integrations being the obvious one, with attack surfaces most annual scopes never mention (we covered how prompt injection differs from classic command injection, and how to test for it).
Taken literally, the guidance would have you testing after every sprint. Nobody does that, because a manual point-in-time test runs $10,000 to $30,000. So teams quietly redefine "significant" to mean "nothing until next year's test," and the distance between the tested system and the running system grows every sprint. Meanwhile IBM's Cost of a Data Breach 2024 puts the average breach at $4.88M, a record, up 10% in a single year. You cannot buy fifty-two manual tests a year, and you do not need to. You need written triggers, scoped retests when they fire, and continuous exposure evidence between manual engagements so the other 364 days are not blank.
A framework you can defend twice
Once in the audit, once after an incident. Five rules.
- Schedule by period math. On a 12-month period I book the test in months one to four and close remediation plus retesting by month six, consistent with the standard guidance to test inside the first half of the period. Shorter period, same logic: the fix loop must close inside the window.
- Write your significant-change triggers down, with an owner. Mine: a new internet-facing service or API surface, any change to the authentication or authorization model, a new cloud account or network boundary, a new vendor integration touching customer data, a major framework or dependency migration. Trigger fires, scoped retest within 30 days. The 30 is my recommendation, not a standard. What matters is that the number exists before the trigger fires.
- Put severity SLAs in writing. A defensible start: critical in 7 days, high in 30, everything else scheduled or formally risk-accepted with an expiry on the acceptance. Tune to your staffing, but an undocumented SLA is indistinguishable from no SLA.
- Diff the scope against the system description before signing the SOW. If the description says web app, API, and cloud, the quote had better say the same. The auditor will compare them, and "we only budgeted for the web app" is not a control.
- Keep the evidence package as a standing folder, not a two-week scramble before fieldwork:
soc2-evidence/
2026/
pentest/
scope-and-methodology.pdf
final-report.pdf
attestation-letter.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.pdfThen make the honest regime call. Monthly releases and a stable surface: annual manual testing plus trigger retests is defensible, and if nobody owns this calendar yet, a 90-minute threat modeling session is the fastest way to define your triggers. Weekly or daily deploys with AI features and multiplying integrations: you need continuous monitoring between manual tests, or your CC4.1 story is one data point and a good auditor will press on it.
"But the auditor signed off"
The pushback I hear: the opinion was clean, customers accept it, why gold-plate. Three answers. First, the opinion attests that controls operated as described, with exceptions; it never claimed no exploitable vulnerability existed, and you know that even if the procurement portal does not. Second, expectations ratchet. Auditor liability means that after incidents, yours or someone else's, scopes get compared harder and missing testing becomes a qualification. The firm that signed your clean opinion has its own file to protect. Third, if sales tells buyers the report proves you were secure and something shipped between tests burns you, the clean opinion becomes evidence that you oversold, not that you were careful.
The reflexive counter, that continuous testing is a vendor pitch, is half right. The pitch is real. But the four questions behind the checklist stand without it, and a trigger log plus scoped retests plus monitoring you already own answers most of them. Buy tooling when the trigger log fires so often that retests start costing more than the tool.
Between the tests
If this matches what your auditor has been hinting at, the next step is an engagement scoped to your system description with retest verification built in, rather than a one-off PDF. For evidence between point-in-time audits, Axeploit pentesting for audits is the page to send a buyer or auditor.
Key takeaways
- SOC 2 never mandates a pentest. CC4.1 names it first among examples, and in 2026 auditors treat an annual test inside the Type II period as the floor.
- The artifact proves a sampled window: scope, findings, triage, remediation, retest. It says nothing about the rest of the 3-12 month period, and unresolved criticals inside the period are what produce exceptions.
- The assurance gap is structural: scope freezes before the test, the test samples the period, and retests verify commits rather than controls.
- AI-accelerated release velocity makes the "test after significant changes" trigger fire constantly. Replace the annual-only posture with written triggers, severity SLAs, and continuous evidence between manual engagements.
- Diff your pentest scope against your system description before signing anything, because your auditor will do it after.
