What is a penetration test attestation letter?
It is a one- or two-page letter, signed by the firm that ran the test, that tells a third party a test happened and what it covered without handing over the exploit details. The full report contains working proof of every weakness in your system, so almost nobody sends it to a prospect. The letter is the shareable summary.
There is no standard format. None of the framework bodies (PCI SSC, AICPA, ISO, NIST) publishes a template or defines required fields, so every firm writes its own. That is why letters vary from a useful page of scope and dates to a vague paragraph that says almost nothing. The template below is what a reviewer can actually use.
What does an attestation letter contain?
A useful letter answers five questions: who tested, what, when, how, and what state the findings are in now. Here is a realistic example with placeholder names.
[Testing firm letterhead] Issued: March 14, 2026
To: Security review teams of Acme Payments, Inc. customers and prospects
Re: Penetration test attestation, Acme Payments web platform
1. Client: Acme Payments, Inc. (legal entity as contracted)
2. Tester: Example Security LLC, independent of Acme's engineering
and operations teams
3. Test window: February 9, 2026 to February 20, 2026
4. Scope: https://app.acme.example (customer web app, build 2026.02.3)
https://api.acme.example/v2 (public REST API, 142 endpoints)
Admin console at https://admin.acme.example
5. Out of scope: Corporate network, mobile apps, third-party payment
processor, social engineering, denial of service
6. Environment: Production, with dedicated test tenants
7. Approach: Gray-box, authenticated. Accounts provided for four roles:
owner, admin, member, read-only, in two separate tenants.
API specification provided; no source code access.
8. Methodology: OWASP Web Security Testing Guide, OWASP API Security
Top 10 2023, NIST SP 800-115
9. Findings at test close: Critical 0, High 2, Medium 4, Low 3
10. Retest: Completed March 11, 2026. Both High and three Medium
findings verified fixed. One Medium accepted as risk by
the client with a documented rationale. Low findings open.
11. Limitations: Results reflect the systems as tested during the window.
Later changes are not covered.
12. Signed: Jane Doe, Principal Consultant, Example Security LLC
Verification: attest@example-security.exampleFields 4, 5, 7 and 10 do most of the work. A letter that names targets loosely ("Acme's applications") or skips the out-of-scope list implies coverage the test never had.
How is it different from the full report and from a SOC 2 report?
The letter summarizes one test; the full report is the evidence for it; a SOC 2 report is an opinion on a whole control environment.
| Document | Who issues it | What it covers | Who normally sees it |
|---|---|---|---|
| Attestation letter | The testing firm | Scope, dates, method, finding counts, remediation status of one test | Customers, prospects, partners |
| Full pentest report | The testing firm | Every finding with reproduction steps, evidence, severity and fixes | Your engineers, your auditor, sometimes a customer under NDA |
| SOC 2 report | A licensed CPA firm under AICPA standards | Whether controls across security (and any other chosen criteria) were designed and, for Type II, operated effectively | Customers under NDA |
The word "attestation" causes confusion here. A SOC 2 examination is an attestation engagement in the accounting sense, performed by CPAs under professional standards. A pentest attestation letter is a vendor's signed statement with no such standard behind it. Treat it as a summary from an interested party, and weigh it by how specific it is.
The PCI SSC's penetration testing guidance lays out what a full report should include (executive summary, scope, methodology, limitations, narrative, findings, cleanup) and a separate retest report with original and retest dates. A good letter compresses those same headings into one page.
Who asks for one?
Mostly your customers' security and procurement teams. Common triggers:
- Vendor security questionnaires. Many ask whether you run third-party penetration tests. The Cloud Security Alliance's Cloud Controls Matrix, which its CAIQ questionnaire is built on, includes TVM-06 on periodic penetration testing by independent third parties. A "yes" answer invites a request for evidence.
- Enterprise security reviews before a contract is signed or renewed.
- Partner and platform programs, such as marketplace listings or bank partnerships, that ask for recent test evidence.
- Your own auditors sometimes accept the letter as a pointer, then ask for the full report anyway.
What do reviewers check?
Experienced reviewers read a letter in a few minutes and look for the gaps. A practical checklist:
- Does the scope match what we are buying? If you sell an API and the letter covers only the marketing site, it answers the wrong question.
- Is the test recent? Compare the test window to today and to your release history.
- Was it authenticated, and with which roles? An unauthenticated test says little about tenant isolation. See authenticated penetration testing.
- Black-box, gray-box or white-box? This sets how deep the tester could go. See black-box, gray-box and white-box testing.
- Are high and critical findings closed, and was closure verified by a pentest retest? "Remediation in progress" on a critical finding usually triggers follow-up questions.
- Who signed, and are they independent? A named person at a separate firm carries more weight than an unsigned PDF.
- Can it be verified? A contact for confirming the letter is genuine is a small detail reviewers appreciate.
How long is a letter valid?
No rule sets an expiry. In practice, many reviewers treat a letter covering a test more than about 12 months old as stale, largely because PCI DSS and most auditors expect testing at least annually. A team shipping weekly may find a six-month-old letter questioned too, since the product it describes no longer exists in that form. Putting the build or version in the scope line (as in the template) lets a reader judge this.
Common mistakes
- Omitting the out-of-scope list.
- Reporting findings without their current status, or reporting "all fixed" without a retest date.
- Listing a methodology name with no statement of approach (authenticated or not, which roles).
- Wording that suggests a certification. A pentest firm does not certify you as secure, and a letter that reads that way is a red flag to reviewers.
[ Sources ]
Written by Parameter · Last reviewed
