The document procurement actually files. What belongs in a credible one, who can sign it, why the signature is the whole value, and when a reviewer accepts it instead of the full report.
- Published
- Updated
- Reading time
- 8 min read
- By
- Zaaf review desk
In this guide
Somewhere in the security review, a line appears: "Please provide an attestation of recent security testing." It sounds like a formality. It is not. The attestation letter is the document procurement actually files, and getting it wrong stalls the deal just as effectively as having no testing at all.
The letter is what stage three of an enterprise vendor security review asks for. Most articles on this blog mention it, because it keeps showing up as the thing that closes the loop. This one explains what it is, what belongs in a credible one, and when a reviewer will accept it.
What a security attestation letter actually is
An attestation letter is a short signed statement from whoever performed a security test, confirming four things: what was tested, when, what was found, and what has been fixed and re-verified. Usually one page. Usually on the tester's letterhead.
Its job is narrow and specific. A reviewer needs a durable artifact that says "an independent party looked at this system on this date and here is the outcome." Your email saying the same thing is not that artifact, because it is not signed by the party who did the work.
Three things it is not
- Not a certification. Nobody accredits an attestation letter. It carries the weight of whoever signed it and nothing more.
- Not a SOC 2 report. SOC 2 is an audit of your controls over a period, performed by a licensed CPA firm. An attestation letter covers one technical test of one system on one date. A reviewer who asked for SOC 2 will not usually take a letter instead.
- Not proof that your app is secure. It states what was tested and what was found. Anything out of scope is simply unexamined, which is why the scope line matters more than the reassuring sentence at the end.
What a credible letter contains
Reviewers who read a lot of these are scanning for specific things. A letter missing them reads as marketing:
- Scope, stated concretely. Which hosts, domains or applications. "Your production environment" is not a scope; a list of names is.
- Dates. When testing started and finished. A letter with no date ages badly and reviewers know it.
- Method. Automated, manual, or both, and whether the tester had credentials. Authenticated and unauthenticated testing answer very different questions.
- Findings by severity. Counts, not adjectives. "No critical findings remained open at the close of testing" is checkable. "The application was found to be secure" is not.
- Remediation status. What was fixed, and crucially whether the fix was retested. An unverified fix is a claim.
- Limitations. What was not covered. A letter that admits its own boundaries is more credible, not less.
- An identifiable signer. A named person or firm the buyer can look up and, if they want, contact.
- # Illustrative letter summary, Northwind Pay
- Scope app.northwind.example, api.northwind.example
- Dates 2026-06-01 to 2026-06-12
- Method Authenticated and unauthenticated, verified by a researcher
- Findings 0 critical, 1 high, 3 medium, 4 low
- Status High and mediums fixed, retested 2026-06-19
- Limits Mobile clients and third-party payment pages out of scope
- Signed Named researcher, Zaaf review desk
Illustrative. Counts, dates and limits, not adjectives.
Who signs it, and why that changes everything
The signature is the whole value. The same words carry different weight depending on who put their name to them.
| Signed by | How reviewers read it | Where it carries |
|---|---|---|
| An accredited penetration testing firm | Strongest. Expected at enterprise tier and in regulated industries. | High tiers and regulated buyers. |
| An independent security vendor or consultant | Widely accepted, provided the report behind it holds up. | Most mid-market deals. |
| Your own engineering team | A self-assessment. Reviewers file it as such. | Rarely moves the deal. |
This is worth being blunt about: if a vendor sells you an attestation letter without telling you plainly who signs it and what their standing is, that is the question to ask before you buy.
When a letter is enough, and when it is not
The letter usually satisfies procurement, because procurement needs a document for the file. The security reviewer is a different reader with a different question: can I check this?
So the practical rule is that the letter gets you through the first pass, and the report behind it gets you through the second. Send a letter with nothing behind it and you have simply moved the failure point a week later, into a conversation where you now look evasive. If your buyer's questionnaire is the immediate blocker, the sequencing is covered in our questionnaire playbook.
Two cases where a letter will not carry the deal on its own: regulated industries with a hard vendor-tiering policy, and any buyer whose own compliance obligations require a named accredited firm. In both, ask early rather than discovering it at signature. The differences between SOC 2, a pentest and continuous scanning are worth knowing before that conversation, because buyers frequently ask for the wrong one.
Red flags reviewers look for
- No date, or a date more than twelve months old with no retest.
- A scope so broad it cannot be verified.
- Conclusions with no counts behind them.
- "All issues resolved" with no mention of who confirmed the fix.
- A signer who cannot be identified.
None of these are exotic. They are the ordinary result of a letter written to reassure rather than to be checked, and experienced reviewers spot the pattern quickly.
Getting one without a four-week engagement
The awkward part is timing. A traditional engagement takes weeks of scoping and scheduling before testing starts, and deals rarely wait. Continuous scanners run fast but generally do not sign anything, because an unverified alert is not something a vendor will put a signature next to.
What actually shortens the path is testing that produces verified findings and a retest in the same cycle, so the letter can state remediation as confirmed rather than reported.
- TestRun the agreed scope.
- ProveVerify each finding with evidence.
- FixRemediate what was found.
- Re-verifyRetest the same findings after the fix.
- SignPut a named signer to the outcome.
Before you send
A quick final check
Common questions
What is a security attestation letter?
A short signed statement from the party that tested your application, confirming what was tested, when, what was found, and what has been verified as fixed. It is a summary of testing that already happened, written so a buyer's reviewer can file it. It is not a certification and it does not replace an audit.
Is an attestation letter the same as a SOC 2 report?
No. SOC 2 is an audit of your controls and processes carried out by a licensed CPA firm over a defined period. An attestation letter covers a specific technical test of a specific system on a specific date. They answer different questions, and a reviewer who asked for one will not usually accept the other.
Who can sign a security attestation letter?
Whoever actually performed the testing. That can be an accredited penetration testing firm, an independent consultant, or a security vendor, and the signature carries exactly as much weight as the reviewer gives that party. A letter signed by your own engineering team is a self-assessment, and reviewers treat it as one.
Will a buyer accept a letter instead of the full report?
Often yes for the first pass, because the letter is what procurement files. Security reviewers who dig deeper will ask for the underlying findings, so the letter should reference a report you can actually produce. A letter with nothing behind it fails the moment somebody asks.
NoteThis describes how enterprise security reviewers commonly treat attestation letters; it is general guidance, not legal or compliance advice, and your buyer's own policy governs.