Auditor expectations on penetration-test evidence have shifted again. The 2024 trust-services-criteria update created room for interpretation; the 2025 fieldwork cycle is when individual firms started enforcing the stricter reading. By Q2 2026, we are seeing the same set of pushbacks across every Big Four-tier SOC 2 audit and across most of the regional firms.
Here is what passes review now, what gets flagged, and what your engineering team can prepare before the auditor walks in.
The report must name a methodology
In 2023, "follows industry best practices" was acceptable boilerplate. In 2026, that line gets a comment. Auditors want a specific methodology cited: PTES, OWASP WSTG, OWASP MSTG for mobile, OSSTMM, NIST SP 800-115, or a defensible custom framework.
Custom frameworks pass review when they include the standard phase structure (planning, intelligence gathering, threat modeling, vulnerability analysis, exploitation, reporting) and cite where they deviate from a public framework and why.
What does not pass review: "our team uses proprietary methodology developed over twenty years of testing." That sentence is a signal to the auditor that there is no methodology.
Severity must map to a named scoring system
CVSS 4.0 is the current expectation. CVSS 3.1 is still accepted but flagged as a finding-management gap. Risk-rated severities (Critical / High / Medium / Low) without a scoring system behind them get rejected; the auditor cannot evaluate consistency without a method to point at.
If you use a custom severity tier, document the mapping. We include a one-page severity rubric in every report that ties our High / Medium / Low calls to CVSS vector ranges. Auditors stop asking after they see the rubric.
Retest evidence is now expected
The biggest 2026 shift. Auditors used to accept "remediation in progress" as a control narrative. The 2024 update tightened this. Now most fieldwork expects:
- A re-test report from the same vendor that ran the original engagement
- Each finding marked resolved, partially resolved, or accepted (with documented risk acceptance)
- Retest dated within the audit period, not before
- Evidence of the technical change (commit hash, configuration screenshot, IaC diff) attached to each resolved finding
"Accepted" findings are particularly scrutinized. Auditors want the risk-acceptance memo signed by an executive, not just an engineering manager. Plan for this.
Scope must match the system description
Your SOC 2 system description names the systems, components, and boundaries in audit scope. Your pentest report needs to name those same systems. A pentest of app.example.com when the system description says app.example.com and api.example.com means you are short half of the in-scope surface.
We see this fail more often than any other check. The fix is simple: include the relevant text from the system description in the pentest SOW, and require the engagement to cover every named asset (or get explicit auditor sign-off on a scope reduction).
The engineer who tested must be named
Independence and competency questions now ask for the named individual. Their relevant certifications and experience must be available on request. "Our team of senior engineers" no longer passes muster; the auditor wants to confirm that a real, qualified person did the work and that they were sufficiently independent from the system owners.
For us, this is unchanged from how we have always run engagements. For larger firms that staff-augment, this is where audit pushback starts. If your vendor cannot name the person who tested your system, that is a procurement risk going into 2027.
The attestation letter format matters
An attestation letter signed by the engineer (not just the firm) is the artifact auditors want to see attached to the control. The letter should state:
- What was tested (scope reference)
- When it was tested (engagement window)
- What methodology was followed
- Who performed the test
- That the retest was completed and what findings remain open
A one-page attestation that includes all six items will pass review at every audit firm we have worked alongside. Anything less, and expect questions.
What to prepare before fieldwork
If your audit window is in the next six months, here is the short checklist:
- Confirm your most recent pentest cites a named methodology in writing
- Verify severity ratings map to CVSS 4.0 or a documented custom rubric
- Schedule the retest if it has not happened (or insist your vendor include it)
- Cross-check the pentest scope against your system description, line by line
- Confirm the attestation letter names the engineer who ran the test
None of this is expensive to fix. Most of it is conversational with a competent vendor. The cost shows up when the audit lands and the gap discovered is two months from a fix.
"We had to push our SOC 2 Type 2 issuance by a month because our vendor's report did not name the engineer. The retest came back fine; the format was the blocker." — a CISO we spoke with in March 2026
What to ask your vendor next time
If you are about to commission a SOC 2 penetration test, four questions to ask before signing the SOW:
- Which methodology does the report cite (PTES, OWASP, NIST SP 800-115, or other named)?
- Is the engineer who runs the test named in the attestation letter?
- Is retest included in the engagement, and what does the retest report look like?
- Will you cross-reference our SOC 2 system description against your scope, in writing, before kickoff?
"Yes" to all four means your auditor's review of the pentest control will go smoothly. "No" to any of them means budget time for follow-up.
For our part, the answers are yes, yes, yes, and yes. They have been since 2019; the difference in 2026 is that auditors now ask the questions out loud.