Give the customer a short pen test summary: who tested, when, what was in scope, how many findings by severity, and whether the serious ones are fixed. Keep the full report private. The summary answers the real question, which is whether someone independent tried to break the product and what happened.
Why the full report stays internal
A pen test report lists exploitable weaknesses in detail. Sent to many customers, it becomes a map of your product for anyone who sees a forwarded copy. A summary gives a reviewer the assurance without the exposure.
NIST SP 800-115, the technical guide to security testing and assessment, describes testing for purposes such as finding vulnerabilities and verifying compliance with a policy. It also stresses that each technique has benefits and limits. That is a useful reminder when you write a summary: say what the test did and did not cover.
What a good summary contains
| Field | Example of wording |
|---|---|
| Tester | Independent firm or internal team, stated plainly |
| Date range | Start and end dates of the work |
| Scope | Which apps, APIs and environments were tested |
| Out of scope | What was not tested |
| Method | Manual testing, automated tools, or both |
| Results | Count of findings by severity |
| Status | How many are fixed, accepted or open |
| Retest | Whether fixes were verified, and when |
Wording that stays honest
Say "no critical findings were open at the end of the test", not "we passed". A pen test is not a pass or fail exam, and it is only valid for the version tested. Say "tested version 4.2 in the staging environment" so the reader knows the boundary.
Do not call a vulnerability scan a pen test. A scan is automated and finds known patterns. A pen test involves a person trying to chain weaknesses. If your last independent test was two years ago, say two years ago. Reviewers care about dates, and a stated old date is still more credible than a vague "regularly tested".
Steps to prepare the summary
- Ask the testing firm whether a customer facing summary format is available.
- Remove hostnames, internal paths and any exploit detail.
- Add the fix status from your tracker, with dates.
- Have security and legal review owners approve the final wording. This is a business sign off, not legal advice.
- Label the file with the test date and product version.
- Store it in your evidence folder and record who approved it.
When a customer insists on the full report
Offer a supervised read under NDA, with notes allowed but no copies. Or invite their security team to a call where you walk through the findings and fixes. Record who saw what. If a customer wants to run their own test, set written scope, dates and contacts first, and never let it touch production data without agreement.
Where Safeguard fits
Safeguard's compliance and evidence automation keeps summaries, approvals and fix evidence tied together, and reachability analysis helps you show which findings affect code you actually run. Try the free scan at https://gold.safeguard.sh/scan.
Quick check
Is an automated scan report a substitute for a pen test summary?
No. Describe it as a scan, state the tool category and date, and keep the term pen test for manual, scoped testing.
How old can a pen test be before it looks stale?
There is no fixed rule. Some reviewers ask for the last twelve months, so state the actual date and any retest since.
Sources
Last reviewed: 19 October 2026.
