# Penetration test report for a customer security review

Source: https://penetrationtestservices.com/customer-security-review/
Publisher: Excession Labs (penetrationtestservices.com)
Last updated: 2026-11-09

Prepare a penetration test report for an enterprise customer security review: what buyers ask for, report versus summary letter, what to share and timing.

> **Short answer:** Enterprise buyers often ask for a recent third-party penetration test as part of a security review. A useful answer is a scoped test of the system they will use, a report with evidence, and a plan for open findings. Excession Labs delivers that report. We cannot promise any buyer will accept it, so ask the buyer what they need first.

A deal is waiting on a security review, and the buyer's questionnaire asks for a penetration test report. You need a test that matches the request, a report you can share and a list of what is still open.

## What do enterprise buyers ask for?

In the Cobalt State of Pentesting Report 2025, 59% of 450 survey respondents named third-party pentest reports as the assurance customers and regulators ask for most often, ahead of vulnerability scans and compliance certifications ([Cobalt, p.5](https://resource.cobalt.io/state-of-pentesting-2025)). This is a vendor survey, so treat it as one data point.

The Cloud Security Alliance's Cloud Controls Matrix v4 includes a control, TVM-06, on periodic penetration testing by independent third parties ([CSA CCM v4](https://cloudsecurityalliance.org/artifacts/cloud-controls-matrix-v4)). Questionnaires based on it ask a similar question. Our guide to [pentest questions in security questionnaires](/guides/security-questionnaire-pentest-questions/) lists common wording and good answers.

Buyers usually want to know:

- Who tested, and were they independent of your engineering team?
- When did the test happen, and what version was tested?
- What was in scope, and what was left out?
- What did the test find, by severity?
- Which findings are fixed, and which are open?

## What is the difference between a report and a summary letter?

A report is the full technical document. A summary letter is a short statement of scope, dates, method and result. Many buyers accept a letter. Some ask for the report under NDA.

| | Full report | Summary letter |
|---|---|---|
| Content | Every finding, evidence, reproduction, fixes | Scope, dates, method, result counts |
| Risk when shared | Contains exploit detail | Low |
| Typical use | Large buyers, security teams | Questionnaire attachments |

Our guide to [attestation letters](/guides/pentest-attestation-letter/) covers what they should contain and their limits. If your buyer wants a letter or summary, tell us during scoping.

## How do we make the report useful for a review?

We write the scope in plain terms: assets, environments, roles tested and exclusions. The report states the test method, the safety constraints and the severity scale. It lists "Controls that held", so a reviewer sees the protections that worked as well as the flaws. A "Limitations and open questions" section says what we could not confirm. We label evidence as "Observed" or "Browser-observed" and keep inferred paths apart.

> **Sample report excerpt:** This is a demonstration. It uses a fictional app, Harbor Notes, and no real customer system was tested.
> 
> **Scope statement.** Assets: `app.example.com` and `api.example.com`. Roles tested: Viewer, Editor, Admin in two test tenants. Excluded: third-party payment pages and denial-of-service testing.
> 
> **Result summary.** 1 High, 2 Medium, 1 Low. Controls that held: tenant check on note read, session expiry, password-reset token reuse.
See the full layout in the [sample report](/sample-report/).

## What do you get?

The report comes in HTML, PDF and Markdown with proof-of-concept scripts, an executive summary with priority actions, a remediation plan and an evidence index. After you fix findings, we can retest them; see [retesting](/retesting/). No buyer, auditor or regulator is promised to accept a report.

## What do we need from you?

- The questionnaire or the buyer's written requirements, if you can share them.
- The system, environment and roles the buyer will use.
- Test accounts, documentation and a technical contact.
- Your target date for sharing the report, so we can plan around it.
- Written authorization from the system owner.

## What changes the quote?

Scope sets the quote: product size, roles, API surface, tenants and environment. A retest adds work. A tight deadline can change what we can offer, and we will tell you at scoping. We publish no prices; see [pricing](/pricing/).

For SaaS products, see [SaaS penetration testing](/saas-penetration-testing/). To start, [request a pentest](/contact/).

## Questions

### Should we share the full report or a summary?

Share what the buyer asks for and your policy allows. Many buyers accept a short summary letter. Some ask for the full report under NDA. The full report contains exploit detail, so share it with care. Ask the buyer which they need before you test.

### Will the buyer accept your report?

We cannot promise that. Acceptance is the buyer's decision. Ask what they require: scope, date, tester independence and a statement on open findings. Share that list with us at scoping so the report covers it.

### What if the report shows open findings?

Open findings are normal, and buyers look at how you handle them. Fix the serious ones, retest, and share the plan for the rest. See the retest page.

### How recent should the test be?

Buyers set their own rule. Many questionnaires ask about testing in the last 12 months. Check the exact wording in your questionnaire and plan the test date against your sales calendar.

## Sources

- [Cobalt State of Pentesting Report 2025, p.5](https://resource.cobalt.io/state-of-pentesting-2025)
- [CSA Cloud Controls Matrix v4](https://cloudsecurityalliance.org/artifacts/cloud-controls-matrix-v4)