# Pentest attestation letter: what it contains and what it cannot prove

Source: https://penetrationtestservices.com/guides/pentest-attestation-letter/
Publisher: Excession Labs (penetrationtestservices.com)
Last updated: 2026-11-09

Pentest attestation letter: what it contains, a letter outline you can adapt, how it differs from a full report, and what no letter can prove to a buyer.

> **Short answer:** A pentest attestation letter is a short document from the testing provider that confirms a test took place. It usually states the dates, scope, method, tester and a results summary. No standard defines it, and acceptance varies by buyer or auditor. A letter cannot show that a system is secure. Ask your provider whether they issue one.

A pentest attestation letter is a short document from the party that did a penetration test. It confirms that the test took place and gives a few facts about it. It is not a report, and no standard defines its form. People ask for letters because full reports hold sensitive detail.

> **Note:** Excession Labs' published materials do not say we issue attestation letters. If you want one, ask your provider whether they issue one and what it says. A letter does not make anyone compliant, and no auditor or customer is bound to accept it.
## What is a pentest attestation letter?

A pentest attestation letter is a summary statement signed by the testing provider. It says what was tested, when, by whom and, in broad terms, with what outcome. It is also called a letter of attestation, a pentest summary letter or a pentest certificate.

The terms vary. We found no standard, including PCI DSS, SOC 2 or ISO/IEC 27001, that defines the letter. Descriptions come from providers, who note that acceptance varies. PCI SSC's own guidance says even its report outlines "are only suggested outlines and do not define specific reporting requirements for PCI DSS penetration tests."

## What does a letter usually contain?

Most letters share the core items below. Each answers a question a reader would ask.

| Item | Why the reader wants it |
|---|---|
| Provider name and contact | To know who stands behind the statement |
| Client name | To tie the letter to the right company |
| Test dates (start and end) | To judge how recent the test is |
| Scope: apps, APIs, environments, roles | To see what was and was not covered |
| Test type: black, grey or white box | To judge the depth of the view |
| Method and reference (for example OWASP WSTG, NIST SP 800-115) | To see the approach |
| Tester names or roles, and independence statement | To judge competence and objectivity |
| Result summary: counts by severity | To see the size of the issues found |
| Fix and retest status | To see whether issues were closed |
| Limits and exclusions | To prevent over-reading |
| Date of the letter, and a signature | To tie the statement to a person |

## A letter outline you can adapt

This outline is generic. No auditor requires it as a form.

```text
[Provider letterhead]

Penetration test summary letter

Client:            [Company name]
Provider:          [Provider name]
Report reference:  [Report ID and date]
Test period:       [Start date] to [End date]
Retest date(s):    [Dates, if any]

1. Scope
   Applications / APIs / environments tested: [list]
   Accounts and roles used: [list]
   Out of scope: [list and reason]

2. Approach
   Test type: [black / grey / white box]
   Method references: [for example OWASP WSTG, OWASP API Security Top 10]
   Testers: [names or roles]; independent of the client's build team: [yes/no]

3. Results at the end of the test
   Critical: [n]  High: [n]  Medium: [n]  Low: [n]
   Status at [date]: [n] fixed and retested, [n] open

4. Limits
   This letter summarizes a point-in-time test limited to the scope above.
   It does not state that the systems are free of vulnerabilities, and it
   does not replace the full report.

Signed: [Name, role]   Date: [Date]
```

## What are the limits of a letter?

A letter has five limits. State them to anyone who reads it.

1. Point in time. The system changes after the test. The letter covers the test window only.
2. Scope bound. Anything outside the listed scope is not covered.
3. No proof of absence. A test finds issues in the time and scope it had. It does not show that none remain.
4. Not a standard. No framework defines it, so acceptance depends on the reader.
5. Thin evidence. A reader cannot check findings, severity or fixes from a letter alone. They rely on the signer's word.

For those reasons, an auditor or buyer may ask for the report, or for a call with the tester. NIST SP 800-115 describes the value of reporting findings with enough detail to act, and a letter is deliberately short.

## When is a letter useful?

A letter fits when:

- A buyer's security team wants proof of a recent test, but you cannot send a report with details of weaknesses.
- A questionnaire asks for a "pentest certificate" and a summary meets the need. See [security questionnaire pentest questions](/guides/security-questionnaire-pentest-questions/).
- The buyer screens first and will ask for the report later if you pass.

Our page on [pentest reports for customer security reviews](/customer-security-review/) covers how the report and letter fit into a buyer review.

## How does a letter differ from a report and a summary?

People mix up three documents. The table shows the usual split.

| Document | Length | Holds | Typical reader |
|---|---|---|---|
| Full report | Tens of pages | Findings, evidence, reproduction, fix advice, method | Your engineers, auditors under NDA |
| Executive summary | 1 to 3 pages | Scope, risk themes, priority actions, counts | Management, some buyers |
| Attestation letter | 1 page | Dates, scope, tester, counts, limits, signature | Buyer procurement, quick screens |

Send the lightest document that answers the reader's question, and send more only when they ask.

## What mistakes make a letter weak?

- No scope. "A pentest was done" tells the reader nothing. List what was tested.
- No dates. An undated letter cannot be judged for age.
- Marketing language. Words such as "passed" or "certified secure" mislead, because a test has findings, not a pass mark.
- No limits. A letter without a limits section invites over-reading.
- Hidden open findings. If high findings are open, a letter that lists only fixed ones misleads the reader.
- Mismatch with the report. Counts and dates must match the report exactly.

## What is the difference between a letter and a retest letter?

A first letter states the results at the end of the test. A retest letter states the status after fixes, which shows the work was closed. A retest letter lists the original date, the retest date, and the count of findings fixed, partly fixed and still open.

If you plan to retest, ask the provider for one letter after the retest instead of two. That avoids two documents with different counts.

## Should the letter name your system?

Yes, by product name and environment, such as "Example Cloud web app, production". Do not list internal host names, IP addresses or account names. A letter goes to outsiders, so give enough detail to be true and specific, and none that helps an attacker.

## What should you ask your provider before ordering?

- Do you issue a letter, and is it included in the price or extra?
- Who signs it, and in what role?
- Can the letter state the retest result?
- Which items does the letter list, and can I change the template?
- What happens if findings are still open on the date of the letter?
- Do you allow me to share the letter with customers?

If a provider cannot answer these, ask for a sample letter with the client name removed.

## What should you ask the reader?

Ask the auditor or buyer first. A short email saves the cost of a letter nobody uses.

- "Will you accept a summary letter, or do you need the full report?"
- "What items must the letter list?"
- "Must the letter be dated within a set period?"
- "Do you accept a letter from the same firm that did the test, or do you need an independent source?"

## How does a letter relate to a retest?

A letter should state the date of the test and the date of any retest. A letter dated before the retest shows open findings that you may already have fixed, so order the letter after the retest. See [retesting](/retesting/) for what a retest result looks like, and [how to read a penetration testing report](/guides/how-to-read-a-penetration-testing-report/) for the report behind the letter.

For the SOC 2 view of evidence, see [does SOC 2 require penetration testing](/guides/does-soc-2-require-penetration-testing/).

## Questions

### Is an attestation letter the same as a pentest report?

No. A report holds findings, evidence and fix advice. A letter is a short statement that a test was done, with a few facts. A letter helps when you cannot share the report. Some buyers still ask for the report.

### Will an auditor or customer accept a letter instead of a report?

It depends on the auditor or customer. No standard defines a letter, and vendors who describe letters say acceptance varies. Ask the person who will read it, before you order one.

### Can we write the letter ourselves?

A letter has value because an independent party signs it. A letter written by the tested company is a self-statement. If an internal team did the test, label the letter that way and state their role plainly.

### Should the letter list the vulnerabilities?

Usually only counts by severity and the fix status. A letter goes to people outside your team. Details of open weaknesses should stay in the report, which you share under NDA if at all.

## Sources

- [Blaze Infosec: Pentest attestation letter](https://www.blazeinfosec.com/post/pentest-attestation-letter)
- [PCI SSC: Information Supplement, Penetration Testing Guidance v1.1 (Section 5.2, report outlines)](https://listings.pcisecuritystandards.org/documents/Penetration-Testing-Guidance-v1_1.pdf)
- [NIST SP 800-115: Technical Guide to Information Security Testing and Assessment](https://csrc.nist.gov/pubs/sp/800/115/final)