A customer asks for your penetration test report. You have one. You should not send it.
The full report is a current inventory of how to attack your application, including the findings you have not fixed yet, written by someone paid to be thorough about it. Emailing that to a prospect, who will store it in a shared drive and forward it to two colleagues, is a worse decision than it looks.
What you send instead is a summary, and the fact that you know the difference is itself a good signal to the reviewer. This post is what goes in one, what to leave out, and how to handle the awkward cases. For founders and engineering leads at vendors selling into enterprises.
Why the full report is the wrong artifact
Three reasons, and the first one is the one reviewers respect.
It is live attack documentation. Open findings with reproduction steps. Your customer's security team has no obligation to protect it, and at most companies it ends up somewhere broadly readable.
It is scoped to a moment. A report from March describes March. Sending it in November invites questions about everything that shipped since, which is a conversation you do not want structured around a stale document.
It contains your tester's methodology and often their tooling, which may be under an agreement that does not permit redistribution. Check your engagement letter before you forward anything.
Reviewers who know the field expect a summary and are mildly surprised when they get a full report, because it suggests nobody on your side thought about it.
What the summary contains
One to two pages. Every item below has a job.
Scope. What was tested, named precisely: the web application at a given hostname, the API, the mobile client, the infrastructure. Just as importantly, what was not. A summary that implies a wider scope than the engagement had is the one thing here that can turn into a real problem later.
Dates and duration. When the testing ran and for how many days. Effort is a proxy for depth and reviewers read it that way. Two days against a large platform tells them something.
Who performed it. The firm, and whether the testers hold recognised certifications. An independent third party is worth considerably more than an internal exercise, and if it was internal, say so rather than letting the phrasing imply otherwise.
Methodology. Which standard was followed, OWASP Testing Guide, PTES, or the firm's own, and whether the test was black box, grey box, or white box. Grey box with credentials is the useful answer for a SaaS application, because an unauthenticated test of an authenticated product covers very little.
Findings by severity, as counts. Critical, high, medium, low, informational. Numbers only. No titles, no descriptions, no affected endpoints.
Remediation status. For each severity band: how many are fixed, how many remain, and the target date for the remainder. This is the section reviewers actually read.
Retest confirmation. If the firm verified your fixes, say so and give the date. A retest letter is the strongest single line in the document because it is third-party confirmation that you closed what you said you closed.
Attestation. One paragraph from the firm confirming the engagement took place, on their letterhead. Most firms provide this on request and many will produce the whole summary for you.
What stays out
Finding titles, affected endpoints, parameters, payloads, versions, internal hostnames, IP addresses, screenshots, and the names of individual testers.
The test for any line: could a reader use this to attack us faster than they could without it. If yes, it belongs in the full report, which stays with you.
The shape
PENETRATION TEST SUMMARY
Engagement: Web application and REST API
Performed by: [Firm], independent third party
Dates: 14 to 25 July 2026 (10 business days)
Methodology: OWASP Testing Guide v4.2, grey box with
standard and administrative credentials
FINDINGS
Critical 0
High 2 both remediated, retested 12 Aug 2026
Medium 5 4 remediated, 1 accepted with compensating control
Low 9 6 remediated, 3 scheduled for Q4
Info 11 tracked, no fix planned
RETEST Confirmed by [Firm], 12 August 2026
NEXT TEST Scheduled July 2027 (annual cadence)
Full report available under NDA on request.
That last line matters. It tells the reviewer the detail exists and gives them a route to it that puts a legal agreement in the path. Most never take it.
The awkward cases
You have never had one. Say so, and give the date you have booked. Do not offer your vulnerability scanner output as an equivalent, because it is not one and every reviewer knows the difference. At most enterprises the absence of any test is a hard stop, so the booking is the answer, not the explanation.
The results were bad. A critical finding, fixed and retested, is not a problem. It is evidence the process worked. What damages you is a summary showing findings still open past their own target date, so either fix them before you circulate the document or state a date you will meet.
They insist on the full report. Some regulated buyers will. Then: under NDA, watermarked, with open findings redacted, delivered through a portal rather than email, with an expiry. And ask why. Sometimes the real requirement is evidence of an annual cadence, which the attestation letter satisfies more cleanly.
It is eighteen months old. Then it is not evidence any more. Annual is the expected cadence for most enterprise buyers, and more often if you ship substantial changes. Put it on the calendar with the SOC 2 work rather than treating it as a response to a request.
The concession
A summary is a document about a document, and a reviewer cannot verify most of it. Someone willing to misrepresent the full report can misrepresent the summary more easily, which is exactly why the attestation letter and the retest confirmation carry the weight here: they are the parts that come from the testing firm rather than from you.
So the honest reading is that the summary buys you credibility on the strength of the third party in it. Pick a firm whose name means something to your buyers, and let their paragraph do the work.
The implication
This is a half-day of work that recurs once a year and unblocks a question asked in every enterprise deal you will ever run. The teams that struggle with it are the ones producing it under time pressure, from a report they have not read since it arrived, for a customer who is already waiting.
Write it the week the report lands, while the context is fresh. Keep the fixed and open counts current as you remediate. Then the request for it is an attachment rather than a project.
