What auditors reject
The most common rejection reason in 2025-2026 fieldwork is a letter signed "by our security team" with no named individual. The pattern is consistent across Big Four and regional firms: the auditor requests a named engineer attestation, the vendor says they do not provide named attribution, and the audit delays two weeks while the client either switches vendors or waits for a corrected letter. This is a procurement problem that surfaces at the worst possible time.
Why does it matter who specifically signed the letter? SOC 2 requires the auditor to assess the competency and independence of the testing party. That assessment happens at the individual level. If the letter names only a firm, the auditor cannot satisfy their own documentation requirement. They ask, the vendor stalls, the schedule slips.
The second most common rejection is a letter that confirms testing happened but says nothing about remediation and retest. That letter is evidence of half the control. The control requires both identification of vulnerabilities and a response to them. Auditors reading the 2024 trust-services-criteria update consistently interpret this as requiring confirmed remediation, not just identified issues. A letter that ends at "we completed testing on [date]" and has no retest section will receive a request for supplemental evidence. At that point, if the retest has not actually happened, the gap is real and the audit stops moving until it is addressed.
Engagement dates outside the audit period are a frequent problem for organizations that run their pentest in Q1 and present it for a Q3-Q4 audit. The relevance threshold varies by auditor and framework, but retesting within 12 months of the audit date is the safe threshold for SOC 2. For PCI DSS, the annual testing window is explicit in Requirement 11.3.1. A test from 14 months ago, however thorough, may require the auditor to flag the control as out-of-cycle. The fix is another test, which costs time and money that could have been avoided with better timing.
Finally, a letter that claims "proprietary methodology with 20 years of development" fails the methodology requirement. Custom frameworks can pass review, but only when they are documented and referenced by name. A claim of proprietary methodology with no citation is indistinguishable from no methodology. The auditor needs something to point to. If the methodology is genuinely custom, it must be written down, and the letter must reference where to find it.
The format that passes review
A one-page attestation letter that includes all six elements passes review at every audit firm we have encountered. The format is straightforward when a vendor treats it as a standard deliverable rather than an afterthought.
The checklist:
- Named engineer with full name and relevant certifications (OSCP, GPEN, CEH, or equivalent)
- Scope statement matching the compliance system description verbatim or by reference
- Engagement dates (start and end of active testing)
- Named methodology (PTES, OWASP WSTG, OWASP MSTG, NIST SP 800-115, or documented custom)
- Retest confirmation with retest date and status of each finding (resolved, partially resolved, or accepted with rationale)
- Engineer signature, not just firm signature
When all six are present, the auditor attaches the letter to the control and moves on. Our full field notes on SOC 2 audit expectations cover how the review process has tightened over the last two fieldwork cycles and what to prepare before the auditor walks in.
Every pentest.systems engagement includes a signed, named-engineer attestation letter as a standard deliverable. It is not an add-on, not an upgrade tier, and not something clients need to request. See what every engagement produces and how we approach SOC 2 penetration testing specifically.