Nearly every enterprise buyer asks for your latest penetration test. The request is short. The decision behind it is not: the full report describes your weak points in detail, sometimes with working proof, and you are being asked to send it to a company that has not signed a contract with you yet.
Most buyers do not want the full report, and most companies should not send it. What the buyer needs is evidence that you test, that the test covered what they are buying, and that serious findings were fixed. This article covers what to share, what a good summary contains, how to talk about findings that are still open, and what to do when a buyer wants to test you themselves.
What the buyer is trying to learn
A reviewer asking for penetration test results is usually checking four things:
That you test at all, and recently, with a qualified tester who is independent of the team that built the system.
That the scope covered the product they are buying, including the interfaces their users and data will touch.
That material findings were remediated, ideally with a retest to confirm it.
That you have a process for findings, not only a one-off fix.
None of those requires exploit details, hostnames, or screenshots of your internal systems. Knowing that lets you choose the right document to send.
What you can share
You have three levels of detail available. Most requests are satisfied by the first.
| Document | Who writes it | Contains | Typical use |
|---|---|---|---|
| Summary or attestation letter | The tester | Dates, scope, method, tester, overall result, remediation status | Most buyer requests, under NDA |
| Executive summary | The tester, as part of the report | Findings by title and severity, with status | Buyers who want more than a letter |
| Full report, redacted | The tester, redacted by you | Findings with technical detail, sensitive items removed | Rare cases, decided individually |
You can add your own remediation summary to any of these: a short document listing each material finding, its severity, the fix, and the retest date.
What a good summary letter contains
A summary letter is only useful if it answers the four questions above. Check that yours includes:
- Not done:
The testing firm and a statement of its independence from your team
- Not done:
Test start and end dates
- Not done:
Scope: which applications, APIs, infrastructure, and environments
- Not done:
Exclusions, stated plainly
- Not done:
Test type, such as authenticated or unauthenticated, and how much information the testers were given
- Not done:
The methodology, or a reference to a recognized one such as the OWASP Web Security Testing Guide
- Not done:
Findings summarized by severity
- Not done:
Remediation status and retest date for material findings
Talking about findings honestly
The question you will hear most is some version of "were there any critical or high findings?" Answer it accurately.
Almost every test finds something. Reviewers know this, and a letter claiming no findings at all tends to raise questions about the scope rather than settle them. What matters is what happened next. "Two high-severity findings were identified and remediated, confirmed by retest" is a strong answer. So is "One medium finding remains open, with a compensating control in place and a fix scheduled within our remediation window."
Be precise about time. "No open critical or high findings" is only true as of a date. State the date of the retest that confirmed it. If a finding was closed after the retest, say how you verified the fix.
For findings still open, give the severity, the fact that a compensating control exists if one does, and the target date. Do not give the technical detail. If the buyer asks how long you take to fix findings in general, answer from your remediation policy and its timelines. Vulnerability management SLAs auditors accept covers how to set those so they hold up.
The questionnaire questions about testing
Questionnaires ask about penetration testing in predictable ways, and the answers should match your summary letter exactly. Expect questions on:
Frequency. How often you test, and whether major releases trigger an additional test.
Independence. Whether an external firm performs the test, or an internal team separate from the developers.
Scope. Which products, environments, and interfaces are covered.
Remediation. Who owns findings, the timelines by severity, and whether fixes are retested.
Disclosure. Whether you will share results, and in what form.
Write one approved answer for each and keep it with your other questionnaire answers. Update them together when a new test completes, on the same day the new summary letter goes up. A questionnaire answer that says you test annually, sitting next to a summary letter dated two years ago, undoes the work the letter was meant to do.
Redaction, when you share more
Occasionally a buyer has a real need for the full report: a security team evaluating a deep integration, or a regulated buyer with a specific requirement. Decide those requests one at a time, and redact before sending.
Remove hostnames, IP addresses, internal URLs and endpoints, payloads and proof-of-concept code, credentials or tokens, screenshots showing data or internal tools, and the technical detail of anything still open. Keep finding titles, severity, affected component in general terms, root cause category, and status.
Share the redacted version under NDA, watermarked, with access logged. The mechanics are covered in gating documents behind an NDA.
Scope and timing mismatches
Two mismatches cause more trouble than findings do.
Scope. Your test covered your web application. The buyer is purchasing an API integration, or a mobile app, or a product you acquired last year. Say so before the buyer works it out. Then explain when the remaining scope will be tested, or what other evidence covers it.
Age. Buyers generally expect a test from the last year. Some frameworks set this expectation formally. PCI DSS, for example, requires penetration testing at least once every 12 months and after significant changes. If your last test is older, or a major release has shipped since, tell the buyer when the next test is scheduled.
When a buyer wants to test you themselves
Some buyers ask to run their own penetration test, or write a right to do so into the contract. Treat that as a negotiation, not a yes-or-no question.
In a multi-tenant service, a buyer's test can affect other customers, so many providers decline testing against production. Alternatives include a dedicated test environment, a joint scoping call with your tester, or sharing the results of your own test in more detail.
If you do agree to a buyer-run test, set the terms in writing first:
Scope, timing, and the source addresses the testers will use
Who to call if something breaks, and how to stop the test
How any customer data encountered will be handled
That findings are shared with you, in full, promptly
Your cloud provider's own testing policy, which may limit what is allowed
Contract language about customer testing rights is worth reading closely. The same is true of any clause that obliges you to fix their findings within a set time.
How TrustLynce helps
A TrustLynce Trust Center can hold your summary letter behind an approval step, with an access log of who viewed it. Standard answers about your testing program can sit in the reviewed library behind questionnaire automation, so every buyer receives the same accurate description.