Match the document to the stage. Early in a deal, share a short summary of scope, date and outcome. Mid review, offer a letter from the tester. Provide the full report only under NDA, and only to a reviewer who needs it. The full detail is a map of your weak points.
Why not send the full report to everyone
A complete penetration test report lists findings, proof of concept steps and sometimes system names. Even after fixes, it describes how your product was attacked. Sending it to every prospect multiplies the number of people holding it, and some will forward it internally with no controls. That is why the sharing level should rise only as trust and need rise.
NIST's technical guide to security testing describes the purpose of testing as finding vulnerabilities and verifying compliance, and stresses analyzing findings and developing mitigation strategies. Buyers care most about the last part: what you did after the test.
The four documents
| Document | What it contains | When to share |
|---|---|---|
| One page summary | Date, tester type, scope, method, count of findings by severity, status | Early questionnaire stage, public or on request |
| Tester letter | A statement from the testing firm that a test of stated scope took place on a date | Mid review, when a buyer wants third party confirmation |
| Redacted report | Findings with sensitive detail removed | When a reviewer wants depth but you cannot release raw detail |
| Full report | Complete findings and steps | Under NDA, to a named security reviewer, when specifically requested |
What the summary should say
Keep it factual and short. Include the test date, the scope (which applications, APIs and environments), the approach (for example grey box with authenticated roles), the count of findings by severity, and the status of each category: fixed, retested, or accepted with reason. Do not use the words "passed" or "clean". Penetration tests find issues; a report with none usually means the scope was narrow. Reviewers know this.
For what a good summary looks like from the reader's side, see how to read a vendor's pen test summary.
Show the retest
The strongest single piece of evidence is a retest. It shows findings were fixed and verified, not only written down. The post on pen test retest evidence for SOC 2 and questionnaires covers what to keep.
Handling the "send us the full report" request
Reply with a plan, not a refusal. Offer the summary and tester letter now, and a full read under NDA in a supervised session, or a redacted copy. Many reviewers accept a screen share walk through in place of a file transfer. Never email an unencrypted report to a distribution list.
Controls on whatever you send
- Watermark the file with the recipient's name and date.
- Use a link with expiry and view logging, not an attachment.
- Keep a record of who received which version.
- Decide how long recipients may keep it and say so in the NDA.
Scope matters more than the logo
A test of only your marketing site proves little to a buyer who will use your API. Make sure scope covers the product surfaces they will touch, including authentication, tenant separation and any customer facing integrations. The pen test scope checklist for a multi-tenant SaaS lists the items to include.
Try it yourself
Open the exploitability check demo to see how a finding is assessed for real world risk, the same reasoning a reviewer applies when reading your test summary.
Click through it at your own pace, or open it full screen.
Safeguard offers SAST, dependency scanning and reachability analysis that can supplement a periodic test between engagements, though they do not replace an independent one.
Quick check
Is a tester letter enough for a reviewer?
Sometimes. Many reviewers accept it alongside a summary. Larger or regulated buyers may still ask for depth under NDA.
Should we share the report before an NDA is signed?
No. Share the summary and letter first, and release deeper material only after confidentiality terms are in place.
Sources
Last reviewed: 19 October 2026.
