Writing an Attestation Letter an Auditor Will Actually Accept

A penetration test attestation letter an auditor will accept names your firm and the client's legal entity, the scope in recognisable terms, the type of assessment, the actual testing dates, the methodology, the remediation position in two sentences, and a named signatory. The report is for engineers; the letter is for everybody else, from the auditor closing a control to the customer running a supplier assessment, and it travels much further than the report it summarises.

Most firms treat it as an afterthought and produce it on request, by hand, in a hurry. That is a mistake twice over. It is the artefact most likely to be forwarded to somebody who has never heard of you, and it is the one most likely to be rejected for a reason nobody explains.

What the letter is actually for

An attestation letter answers one question for a third party: did an independent tester assess this thing, when, and was it left in an acceptable state? It is not a summary of findings and it must never become one. The moment it lists vulnerabilities it stops being something your client can hand out freely, which defeats its entire purpose. Auditors working to ISO 27001 and SOC 2 use it as one link in an evidence chain, not as the chain itself.

What has to be on it

Element	Why a reviewer looks for it
Who you are	Legal entity, address, and any accreditations. A letter from an unnamed party proves nothing.
Who was assessed	The client’s legal entity, not a trading name, because the auditor is matching it against a contract.
What was in scope	Named applications, environments or ranges at a level that identifies them without exposing them.
The type of assessment	External infrastructure, web application, internal, red team. A reviewer needs to know whether it covers the control they are closing.
The dates	Start and end of testing, not the date the report was issued. These get compared against an audit period.
The methodology	The standard your approach follows, named. It tells a reviewer this was structured rather than ad hoc.
The outcome	Whether issues were identified and whether they have since been retested and resolved. Two sentences, no detail.
Signature and date	A named individual with a role. An unsigned letter is a draft.

The reasons letters get sent back

• The dates do not cover the audit period. The most common rejection by a distance. A letter dated after testing, with no testing dates on it, cannot be matched to anything.
• The scope is unrecognisable. "The client environment" tells an auditor nothing. It has to name what was tested in terms their own documentation uses.
• Remediation is left hanging. If issues were found and the letter stops there, the reviewer has to ask what happened next. Say it: retested on a date, resolved, or outstanding with the client accepting the risk.
• It reads as marketing. A letter that talks about your firm’s excellence rather than the engagement invites doubt about the engagement.
• It arrives as a photocopy of a print-out. Petty, and it still costs you credibility.

The letter is a factual record with a signature on it. Every sentence that is not a fact weakens it.

When findings are still open

The awkward case is the letter requested before remediation is finished, which is most of them. The temptation is to write around it. Do not. State the position in general terms: issues were identified, the highest at a given severity, some have been retested and confirmed resolved on a date, and the remainder are scheduled for retest or have been accepted by the client.

That sentence is uncomfortable to write and easy for an auditor to accept, because it is specific and checkable. A letter that implies everything was resolved when it was not is the single document most likely to be relied on by a stranger, and the one most damaging to your firm if it turns out to be wrong. Where the client has chosen to keep a risk, when a client accepts the risk instead of fixing it sets out how to record it, and the letter simply reflects that record. Where a retest is coming, issue a second letter after it, as described in how to run a retest properly.

Why it is worth producing before it is asked for

The request almost never arrives on a good day. It comes from a client mid-audit, or mid-deal, with a deadline measured in hours, about an engagement your team finished eight months ago. Whoever picks it up then has to reconstruct the dates, the scope and the retest outcome from a report, an inbox and somebody’s memory.

Produce it at delivery instead, alongside the report, and the request becomes a link rather than a task. Clients notice this more than almost anything else you do, because you have solved a problem they were expecting to chase you about.

A template worth standardising on

1. Opening statement. Your firm, engaged by the client entity, conducted an assessment of the named scope between the stated dates.
2. Methodology sentence. The approach followed, the standard it aligns to, and that it was carried out by qualified testers.
3. Outcome sentence. Whether findings were identified, at what highest severity, in general terms only.
4. Remediation sentence. What has since been retested and confirmed resolved, with the retest date.
5. Limitations sentence. That the assessment reflects the environment as it stood during the testing window. This protects you and reviewers expect it.
6. Signature block. Named signatory, role, date, company registration and address.

The test before you send it

• Could a stranger match this letter to an audit period without asking a question?
• Does the scope name things the client’s own documentation also names?
• Is the remediation position stated rather than implied?
• Would your client be comfortable sending this to their largest customer unedited?
• Does it look like it came from your firm rather than from a template pack?

Get those five right and the letter does its job silently, which is the only way you will ever know it worked.