A penetration test produces three separate documents, and the fastest way to fail a security review is to hand over the wrong one. Send a prospect the full technical report and you have just emailed a stranger a step-by-step guide to your unpatched flaws. Send an auditor a one-line email that says "we did a pentest" with nothing attached and you have given them no evidence at all. The document that sits between those two failures, the one you can share freely as proof without exposing anything exploitable, is the completion letter. Knowing which of the three artifacts goes to which reader is a core operational skill for any security lead who fields customer questionnaires, partner due diligence, and auditor requests.
What is the difference between a pentest completion letter and a full report, and which do I share?
The difference is detail and audience. A pentest completion letter (also called a summary letter or a letter of attestation) is a one-page document that confirms a qualified testing firm assessed a defined scope over defined dates and states the overall risk posture, with no exploitable detail. You share it with customers, prospects, partners, and auditors as proof the test happened. A full technical report is the long internal document that lists every finding with reproduction steps, payloads, and raw evidence; you keep it with your engineers and never send it outside the organization. Between them sits the executive summary, a short narrative for security reviewers who want context, which you share on request.
So the short answer to the most common version of this question: share the completion letter with customers and auditors, share the executive summary on request, and keep the full report internal. The rest of this post explains each artifact, gives you a who-gets-which matrix, and shows exactly what to redact so a shared letter proves the work without arming a reader.
The three artifacts a pentest produces
1. The completion letter (summary letter, letter of attestation)
The completion letter is the shareable proof-of-testing document. On a single page it names the testing firm and its accreditation, states the engagement type and methodology, defines the scope that was tested (applications, IP ranges, in-scope assets), gives the start and end dates, and provides an overall risk statement. A good letter also notes whether findings were remediated and retested, and names a point of contact who can verify the letter's authenticity if a third party calls to check.
Crucially, the letter carries no exploitable detail. There are no reproduction steps, no payloads, no screenshots of live data, and no unremediated critical findings described in a way an attacker could act on. That absence is the entire point. Because the letter proves testing occurred without describing how to break in, it is the one document you can attach to an outbound email with confidence.
Many buyers search for "letter of attestation," so be precise about what this letter is. In an offensive-security context, an attestation or completion letter is a deliverable from your testing firm confirming that a penetration test was performed against a stated scope. It supports your SOC 2, ISO 27001, PCI DSS, or similar program by giving your auditor evidence that testing happened. It is not a compliance attestation, an audit opinion, or a certification of any framework; the framework attestation itself is a separate document produced through a separate process. Keep those two ideas distinct so nobody mistakes proof-of-testing for proof-of-certification.
2. The executive summary
The executive summary is a two to five page narrative for people who want more than the letter but should not receive the full report. Security reviewers, GRC teams, and risk functions on the other side of a large enterprise deal often ask for it. It typically includes the same scope and date information as the letter, plus a count of findings by severity, a plain-language description of the most significant risks and their business impact, and a summary of remediation status, while still stopping short of reproduction steps and raw evidence.
Treat the executive summary as a share-on-request document rather than a default share. Many reviews are satisfied by the letter alone. When a reviewer pushes for more, the executive summary usually closes the gap without you ever needing to expose the technical report. Our guide on how to read a pentest report breaks down what a strong executive summary should contain and how to grade one.
3. The full technical report
The full technical report is the engineering artifact. It can run from twenty pages to well over a hundred and contains everything: each finding with a severity rating, business impact, precise reproduction steps, evidence such as request and response pairs, affected endpoints, and remediation guidance detailed enough for a developer to fix and confirm the fix. This is the document that makes the engagement useful to your own team, and it is exactly the document that must never leave the organization.
The reason is simple. A full report is, by design, a curated set of instructions for exploiting your systems, and in the wrong inbox it is a liability. Store it where your engineers and testers can reach it, reference it during remediation, and hand it to your retest, but do not attach it to a security-review email no matter how insistent the requester is. If a reviewer genuinely needs a specific technical detail, share that one detail through a controlled channel rather than releasing the whole report.
Who gets which document
The rule of thumb: default to the least detailed document that answers the question in front of you. Most external requests are satisfied by the letter. Reviewers who need more get the executive summary. The full report stays inside.
Audience | Completion letter | Executive summary | Full technical report |
|---|---|---|---|
Prospect in a security review | Share by default | On request | Keep internal |
Existing customer or partner | Share by default | On request | Keep internal |
SOC 2 / ISO 27001 auditor | Share by default | Share by default | On request, controlled |
Cyber insurance underwriter | Share by default | On request | Keep internal |
Your own engineering team | Reference | Reference | Primary reader |
Board or executive leadership | On request | Share by default | Keep internal |
Two rows deserve a note. Auditors sometimes ask to see more than the letter to confirm that findings were genuinely remediated; the executive summary usually satisfies that, and a controlled walkthrough of specific remediated findings can cover the rest without releasing the full report. Cyber insurance underwriters increasingly ask for proof of regular testing as part of pricing a policy, and the completion letter is exactly the artifact they are looking for. For the broader picture of how testing evidence maps to compliance frameworks, see our overview of compliance and regulation for pentesting services.
How to share proof without over-exposing detail
The whole discipline comes down to one question: does this document give the reader proof of testing, or does it give them a way to attack you? Proof belongs in the letter. Attack-enabling detail stays in the full report. The redaction guidance below keeps the two cleanly separated.
A few practical habits make this reliable:
Send the letter first, always. In most security reviews the letter is enough. Leading with it sets the expectation that this is your standard proof, and often ends the request there.
Watermark and date shared documents. A letter or executive summary that leaves your organization should carry the recipient and a date, so a leaked copy is traceable and obviously scoped to a moment in time.
Never share unremediated critical detail externally. If a critical finding is still open, the shared documents should reference remediation in progress, not describe the flaw in a way a reader could exploit before you close it.
Route full-report requests to a call, not an attachment. When someone insists on technical depth, offer a screen-share walkthrough of the relevant sections under NDA instead of emailing the report. You keep control of the document and still satisfy a genuine need.
Keep a clean chain from letter to report. The letter should reference the engagement so an auditor can, if needed, verify it against the fuller documentation through your point of contact, without that documentation being handed over wholesale.
A provider that delivers only a single monolithic PDF and no shareable letter is leaving you with a gap worth raising. A modern engagement hands you the letter and executive summary for reviewers and the full report for your engineers as a matter of course, so you are never stuck choosing between over-sharing and having nothing to show. Our note on using a pentest to unblock an enterprise security review covers how the right artifacts move a stalled deal forward.
How Stingrai delivers shareable proof
A CREST-accredited engagement with Stingrai produces the full set by design. You receive a completion letter and executive summary built for reviewers, customers, partners, and auditors, and a full technical report built for your engineers, so the right person always gets the right document. The letter states the firm, scope, methodology, and dates, and supports your SOC 2, ISO 27001, PCI DSS, HIPAA, or DORA program as evidence that testing occurred.
Stingrai focuses on offensive security: web application penetration testing, red teaming, and PTaaS powered by Snipe, our autonomous agent that hunts complex, high-impact vulnerabilities such as IDOR, broken authorization, and business logic flaws. The deliverables from that work give you shareable proof for the people who ask for it and actionable depth for the people who fix things, with a clean line between the two.
Frequently Asked Questions
What is the difference between a pentest completion letter and a full report?
A completion letter is a one-page document that confirms a qualified firm tested a defined scope over defined dates and states the overall risk posture, with no exploitable detail. A full technical report is the long internal document that lists every finding with reproduction steps, payloads, and evidence. You share the letter with customers and auditors as proof of testing; you keep the full report with your engineers.
What is a pentest completion letter (letter of attestation)?
It is an offensive-security deliverable from your testing firm confirming that a penetration test was performed against a stated scope over stated dates, with an overall risk statement and no exploitable detail. It supports your SOC 2 or ISO 27001 program as evidence that testing occurred. It is not itself a compliance attestation, audit opinion, or certification of any framework.
Which pentest document should I share with customers?
Share the completion letter by default. It proves a qualified firm tested a defined scope without exposing any detail an attacker could use. If a customer's security reviewer asks for more context, share the executive summary on request. Do not send the full technical report to customers.
What pentest document should I give an auditor?
Give the auditor the completion letter as primary evidence that testing occurred, and the executive summary if they want to see findings by severity and remediation status. Auditors verifying that specific findings were remediated can be handled with a controlled walkthrough rather than releasing the full report. The letter supports frameworks such as SOC 2, ISO 27001, and PCI DSS.
Is a pentest completion letter the same as a SOC 2 or ISO 27001 attestation?
No. The completion letter confirms a penetration test was performed and describes its scope. It supports a SOC 2 or ISO 27001 program by giving your auditor evidence that testing happened, but the framework attestation or certification itself is a separate document produced through a separate process. Keep the two distinct so nobody reads proof-of-testing as proof-of-certification.
Can I ever share the full technical report?
You should avoid it. The full report is effectively a set of instructions for exploiting your systems, so emailing it externally creates real risk. When a reviewer needs a specific technical detail, share that detail through a controlled channel such as an NDA-covered walkthrough rather than releasing the whole report.
What should never appear in a shared completion letter?
Working exploits or payload strings, step-by-step reproduction of any flaw, screenshots of live sensitive data, unremediated critical findings described in exploitable detail, internal hostnames, tokens or secrets, and raw scanner output. If a reader could act on it to attack you, it belongs only in the full report.
Does a cyber insurance underwriter need my full report?
No. Underwriters generally want proof that you test regularly and a sense of your risk posture, both of which the completion letter provides. Sending the full report would over-expose your findings without improving the outcome. Lead with the letter and offer the executive summary only if the underwriter asks for more.
References and further reading
Stingrai. How to Read a Pentest Report: A CISO's Scorecard. https://www.stingrai.io/blog/how-to-evaluate-a-penetration-test-report. What a strong executive summary and findings write-up should contain, and how to grade a report.
Stingrai. Compliance and Regulation for Pentesting Services (2026). https://www.stingrai.io/blog/compliance-regulation-pentesting-services-2026. How penetration testing evidence maps to SOC 2, ISO 27001, PCI DSS, and other frameworks.
Stingrai. Using a Pentest to Unblock an Enterprise Security Review. https://www.stingrai.io/blog/pentest-to-unblock-enterprise-security-review. How the right deliverables move a stalled enterprise deal forward.
