What is a security attestation letter?

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. Every article on this blog mentions 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:

1. Scope, stated concretely. Which hosts, domains, or applications. "Your production environment" is not a scope; a list of names is.
2. Dates. When testing started and finished. A letter with no date ages badly and reviewers know it.
3. Method. Automated, manual, or both, and whether the tester had credentials. Authenticated and unauthenticated testing answer very different questions.
4. 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.
5. Remediation status. What was fixed, and crucially whether the fix was re-tested. An unverified fix is a claim.
6. Limitations. What was not covered. A letter that admits its own boundaries is more credible, not less.
7. An identifiable signer. A named person or firm the buyer can look up and, if they want, contact.

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.

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 how to pass a security questionnaire.

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 penetration test, 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 re-test.
• 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; the arithmetic is in penetration test cost for startups. 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 re-test in the same cycle, so the letter can state remediation as confirmed rather than reported. That is the sequence: test, prove, fix, re-verify, then sign.

Keep reading: The review came back with conditions · Do you need SOC 2 to sell to enterprise? · How to pass a security questionnaire · SOC 2 vs pentest vs continuous scanning

This article describes how enterprise security reviewers commonly treat attestation letters and is general guidance, not legal or compliance advice; your buyer's own policy governs. Vulnytics combines exploit-verified automated assessment with hands-on expert review by a person. We are not an accredited penetration-testing firm, so our attestation complements, and does not universally replace, a letter from an accredited firm where your buyer specifically requires one.