Executive summary or full report
Choose evidence for the reader and decision without exposing unnecessary technical detail.
Read nextCustomer request guide
A customer asked for your pentest report. What now?
Preserve the request, identify the customer contact and deadline, note the product or system involved, and check what existing testing actually covered. Then clarify whether the customer wants to review existing evidence or expects new testing. You do not need to translate the request into security language before asking for help.
Do not send a full technical report automatically. First check the engagement terms, report sensitivity, permitted recipients, age and scope of the test, and whether the customer will accept a summary or controlled review instead.
Published by Trespass Security
Why the request is incomplete
“Your latest pentest report” sounds specific. It usually leaves several decisions open.
The customer may be asking for existing evidence, current testing, a questionnaire answer, or proof tied to one product. Those are different jobs.
- Existing or new?
Are they asking to review a report you already have, or requiring a new engagement?
- Which system?
Does the request concern one application, the environment supporting it, or the company more broadly?
- How recent?
“Latest” does not establish the customer’s acceptable testing date, remediation status, or retest expectation.
- Which evidence?
The customer may expect a full report, executive summary, attestation, questionnaire response, or a controlled review.
- Who may receive it?
A technical report can contain sensitive system details and may be subject to contractual sharing restrictions.
Your first move
Forward the request before you rewrite it.
The original email, questionnaire, or contract language is often more useful than a polished summary. Words such as “latest report,” “independent test,” “annual assessment,” and “vendor review” can point to different questions.
Send non-sensitive context first. Do not send credentials, keys, source code, vulnerability evidence, production data, or a technical report through an ordinary intake message.
Gather these details first
This is enough to start a useful conversation without creating security-procurement homework.
- The customer’s exact wording
- The person or team that made the request
- The product, application, or service involved
- The requested date or business deadline
- The date and scope of any existing pentest
- The evidence they specifically named
- Any known confidentiality or sharing restrictions
A practical customer response
Acknowledge the request without promising the wrong evidence.
You can keep the deal moving while you confirm the details.
Example response: “Thanks—we’re reviewing the request. Can you confirm which product or environment the evidence should cover, how recent the testing needs to be, and whether you expect a full report, an executive summary, or another form of confirmation? We’ll come back with the appropriate next step and timing.”
Adapt the wording to your contract, customer relationship, and internal review process. Do not imply that evidence is available or shareable until you have confirmed that it is.
Reuse or retest
Do not answer based only on the date printed on the report.
A useful decision considers what was authorized, what was tested, what was excluded, what changed afterward, which findings were retested, and what the customer actually expects.
The customer makes the final decision about whether existing or new evidence satisfies its request.
- The existing report may fit
The scope, date, remediation status, recipient, and sharing terms match what the customer needs.
- The existing report may be incomplete
It may cover a different application, omit a relevant environment, predate major changes, or lack the evidence the customer requested.
- New testing may be appropriate
A new engagement may be needed when the requested system was not tested, the evidence is too old, the requirement calls for current work, or material changes affect the prior scope.
If new testing is needed
Urgent does not have to become frantic.
Start with the request, deadline, and likely systems. The testing plan follows from those facts.
- Confirm the authorized systems, environments, roles, and third-party boundaries.
- Write down permitted techniques, exclusions, contacts, and stop conditions.
- Allow time for access preparation, testing, reporting, remediation, and retesting.
- Confirm what the customer expects to receive and how it may be shared.
- Do not begin testing without written authorization and an approved scope.
Next step
Send the request, not a finished testing plan.
Tell us who asked, what they said, which systems may be involved, and when they need an answer. We’ll help identify the next questions.