Penetration Test Attestation Letter: What It Proves and What It Doesn't
Published September 24, 2026
By Kelvin O. Medina
An enterprise prospect asks for proof that your application has been penetration tested. Your engineering team has a detailed report, but sending every finding and exploit step to a prospective customer may disclose more than they need. A short penetration test attestation letter can help. It gives a customer a concise account of the engagement while the full technical report stays with the people responsible for remediation.
The word attestation needs care here. A letter issued by a penetration-testing provider summarizes that provider's own work. It is not a SOC 2 report, a certification, a guarantee that the application is secure, or an independent audit opinion. A buyer may ask for the full report under appropriate confidentiality terms, and a short letter does not replace it.
What a useful letter should say
A credible letter lets the reader answer five questions without guessing:
- Who performed the test and for whom? Name the testing organization and the client, with an authorized signature and a way to verify the letter.
- What was actually tested? Identify the applications, APIs, environments, and major boundaries at a level that does not expose unnecessary sensitive detail. Say whether authenticated roles and important workflows were in scope. Do not imply that an entire company or platform was tested when the engagement covered one application.
- When and how was it tested? Give the test dates and a concise description of the approach. Distinguish a manual penetration test from an automated vulnerability scan. State material limitations such as unavailable accounts, excluded endpoints, or a short test window.
- What was the outcome? Summarize findings by severity and remediation status as of a specific date, subject to the client's disclosure agreement. If a retest occurred, identify what was retested and when. A retest of selected findings is not automatically a new assessment of the whole application.
- What does the letter not cover? State that results are point-in-time and limited to the agreed scope. New code, integrations, permissions, and configurations may change the risk afterward.
OWASP's Web Security Testing Guide reporting guidance emphasizes scope, limitations, dates, findings, and retest status in the underlying report. The letter should be consistent with that report, not a substitute for its detail.
Letter, executive summary, and full report are different artifacts
| Artifact | Best use | Important limitation |
|---|---|---|
| Provider letter | Concise initial customer response. | Cannot show every test or finding. |
| Executive summary | Leadership or customer risk context. | Omits technical reproduction detail. |
| Full technical report | Engineering remediation or deeper review under confidentiality. | May contain sensitive architecture and exploit information, so distribution should be controlled. |
If a buyer requires evidence against a particular contractual or regulatory requirement, ask what evidence they will accept before commissioning the test. A generic letter may not demonstrate that the required systems, testing methods, frequency, or remediation steps were covered. For PCI DSS, a penetration test must be evaluated against the applicable requirement and actual cardholder-data environment. PCI SSC's penetration-testing guidance describes documenting scope, methods, results, remediation, and retesting. The guidance is supplemental, not a substitute for the current standard.
What a letter cannot honestly claim
Avoid phrases such as “the platform is secure,” “no vulnerabilities exist,” or “the company is SOC 2 certified.” A penetration test samples a defined target during a defined period. A clean result means the tester did not identify reportable issues within that scope and test window; it does not establish that untested components or later releases are free of vulnerabilities. A provider's penetration-test letter also does not replace a SOC 2 examination by a CPA firm. AICPA describes SOC 2 as an examination of controls at a service organization, a different engagement with a different report.
Be equally precise about remediation. “All critical findings fixed” should only appear if supported by an agreed validation process and dated retest record. If remediation is underway, say so. Honesty about an open issue, its owner, and planned treatment is more credible than an ambiguous statement of completion.
Before sharing it with an enterprise customer
Confirm the scope in the letter matches the product the customer uses. Check test and retest dates, obtain the testing provider's approval for final wording, and agree on how the recipient may use or redistribute it. Keep the full report in a restricted channel. If the customer needs more evidence, offer a controlled review of the executive summary or report rather than broadly emailing sensitive exploit details.
The best customer-assurance package starts with a well-scoped test and useful technical report. The letter is the concise cover note, not the security work itself.
If an enterprise customer is requesting testing evidence for your web application or API, ControlSolid's Web Application & API Penetration Testing service can help define scope, test relevant workflows, and produce findings engineers can act on. Book a Call to discuss the application and the customer's evidence request.
This article is general guidance. Documentation required for a specific contract, SOC 2 examination, or PCI DSS assessment depends on applicable criteria and scope.