What to send when an enterprise customer asks for your pentest

When a buyer asks for your latest penetration test, they are usually asking a broader question: can we trust this vendor with our data and workflows? A report alone rarely answers it. The buyer needs to understand what was assessed, how recently, what was found, and whether serious issues remain open.

For a startup, this request can arrive in the middle of a sales cycle, a security questionnaire, or an audit. The fastest useful response is a small, current set of evidence that answers those questions directly. That evidence should be prepared as part of the assessment, not assembled in a rush after procurement asks.

A pentest of a marketing site does not prove that a customer-facing application or API was tested. A strong assessment record names the products, environments, APIs, cloud resources, and identity flows included in the engagement. It also names significant exclusions and testing constraints.

Dates matter just as much. A point-in-time assessment describes a specific system at a specific time. If your product has changed substantially since then, explain what changed and whether that change was assessed separately. Clear boundaries build more confidence than an unqualified claim that the company is secure.

Your engineering team needs the technical report: reproduction steps, affected assets, evidence, impact, and actionable remediation. A prospect normally needs a narrower packet. That might include an independent assessment attestation, an external version of the executive summary, a scope and methodology statement, and a current remediation status.

This separation protects sensitive details. Exploit payloads and system internals should not circulate through every procurement inbox. A buyer can still request deeper review under suitable controls if their risk process requires it.

A list of findings without an outcome leaves the most important question unanswered. Which issues were fixed, which were partially fixed, and which remain open? Retesting should tie each original finding to a dated result and supporting evidence. If a high-severity issue remains open, explain the status accurately rather than hiding it behind a broad summary.

The strongest record connects an initial assessment to a remediation plan and formal retest. That makes the security story understandable to a customer while giving engineers a clear way to finish the work.

Keep a current assessment letter or attestation, a buyer-facing summary, a statement of scope and methodology, a remediation status, and a path for controlled access to the detailed report. Make sure the documents agree on dates and open findings.

If you are preparing for a first enterprise customer, scope the assessment around the product they will actually use. Test the application, APIs, identity boundaries, and infrastructure that can affect their data. Then retest the fixes and package the evidence. That gives Sales a credible answer and gives Engineering work that reduces real risk.