Safeguard
Security Guides•

Pen test reports in due diligence: what to share and how to read one

How sellers should present penetration test results to a buyer, and how buyers should read a report: scope, age, retest status and open findings.

Safeguard Security Team
3 min read

A pen test report tells a buyer less than the headline suggests. Read the scope, the date, who tested, what was excluded and whether findings were retested. Sellers should share a summary early, the full report late, and always include the status of each finding.

For buyers: five things to check

  1. Scope. Which applications, APIs and environments were tested? A test of the marketing site says little about the product.
  2. Date. A report older than the last major release may describe a different system.
  3. Method. Black box, grey box or code assisted testing finds different things. Check the tester's stated limits.
  4. Findings status. Are issues fixed, accepted or open? Is there a retest?
  5. Tester independence. Was it a separate party, or the team that built the system?

For sellers: how to present

Lead with a one page summary: scope, dates, counts by severity and current status. Then offer the full report under NDA at the later stage of the deal. See sharing security documents in a data room.

Add a remediation table: finding, severity, owner, fixed date, retest evidence. This turns a scary list into a managed process.

What a clean report does and does not mean

A report with few findings may reflect a narrow scope or a short engagement. A report with many findings and fast fixes can be a better sign than a thin clean one. Neither replaces continuous scanning, because the system changes after the test date.

What if there is no pen test

Say so and show what you do instead: dynamic and static testing in the pipeline, dependency scanning, and a planned test with a date. Avoid describing automated scans as a penetration test.

Compliance angle

Some customers and frameworks expect periodic testing. Check the specific requirement in the framework text rather than assuming a cadence.

Safeguard offers dynamic, static and API scanning that can run continuously between formal tests, and a free scan is at https://gold.safeguard.sh/scan.

Questions for the tester

If a buyer has access to the testing firm, a short call helps. Ask what they were not able to test, how much time they had, whether they had source code or credentials, and which finding worried them most.

Sellers can prepare for the same questions. Know the answers, and know why scope was set as it was. If a high risk area was excluded for cost or timing, say so and plan a follow up test.

Also keep the retest letter or evidence for every fixed finding. A fixed claim without retest evidence is only a claim. Buyers often ask for the retest first, because it shows the process closed the loop.

Quick check

Is a vulnerability scan the same as a pen test?

No. A scan finds known issues automatically. A pen test adds human judgment and chained attacks.

Last reviewed: 19 October 2026.

Never miss an update

Weekly insights on software supply chain security, delivered to your inbox.

Self-healing security runs on Safeguard.

Your first fix PR is minutes away.

No sales call required, even your agent can complete the purchase over MCP.