Pentest report: what it must contain

The problem: a report that looks like a pentest and isn’t

Picture the scene: the auditor asks for the annual penetration test evidence, the team hands over a 60-page PDF, and the first question is "where is the proof this was actually exploited?" Nobody can answer. The test cost money and weeks, and the requirement is still open. It happens more often than it should, and the cause is almost always the report, not the test.

The report is the only deliverable left after a pentest. Your security team uses it to fix things, an auditor uses it to validate a requirement, and an enterprise customer uses it to decide whether to sign. An excellent test with a weak report is worth little; a polished report built from an automated scan is worth even less.

This guide covers the sections a serious pentest report needs, how to spot a scanner dump, and a checklist you can use when you receive (or buy) the deliverable. If you are still choosing a vendor, start with 10 questions to ask before hiring a pentest.

Who reads which part of the report

A serious report serves several readers at once. Knowing who reads what helps you judge whether the structure is right:

Section	Who reads it	Question it answers
Executive summary	Board, CISO, legal	What is the real risk and what do we decide first?
Scope and methodology	Auditor, compliance	Did the test cover what the standard requires?
Risk rating	CISO, risk management	What do we fix first?
Findings with evidence	Developers, infrastructure	How do I reproduce and fix this?
Regulatory mapping	Auditor, compliance	Which requirement does this test support?
Retest	Auditor, CISO	Did the fix work?
Attestation letter	Enterprise customers, partners	Can I trust this vendor?

1. Executive summary: written for the decision-maker

The first page must be readable by non-technical people and answer four things: what was tested, what the overall result is, which risks require a decision, and what to do first. Look for:

A clear verdict (for example, "it was possible to access other customers’ data without valid authentication"), not just a count of vulnerabilities.
The three to five findings that truly matter to the business, in plain language.
Context: what was not tested and why, so nobody reads "no critical findings" as "no risk".

A summary that says "143 vulnerabilities found" with no prioritization is a red flag.

2. Scope, rules of engagement and methodology

This section is what makes the report defensible in front of an auditor. It should contain:

Targets tested: domains, IPs, applications, APIs, environments (production or staging) and the tested version.
Test window and approach: black, gray or white box, with or without credentials, and what was out of scope. See the differences in What is penetration testing and its types.
Documented methodology: references such as OWASP WSTG, OWASP API Security Top 10, PTES or NIST SP 800-115. The report must say what was applied, not just list results.
Limitations: WAF blocks, load restrictions, test accounts that were unavailable.

Without scope and methodology, an auditor cannot confirm the test covered what the standard requires.

3. Risk rating: CVSS plus business impact

CVSS is a useful common language, but on its own it misleads. A CVSS 6.5 on an API exposing every customer’s personal data can be more urgent than a 9.0 on an isolated system holding no data. A good report shows:

The CVSS score with the full vector, so you can verify and recalculate it.
A context-adjusted severity explaining the impact on your business: exposed data, possible fraud, downtime, regulatory exposure.
Real exploitability: was it actually exploited, or is it theoretical?

Be wary of reports where every vulnerability carries whatever severity the tool assigned, with no human analysis.

In practice, risk rating has two layers. The CVSS band is standardised (low 0.1 to 3.9, medium 4.0 to 6.9, high 7.0 to 8.9, critical 9.0 to 10.0), but fix priority depends on context: which data is exposed, how many customers are affected, whether exploitation needs authentication, and whether a compensating control exists. Two findings with the same score can need very different deadlines. Insist that the report shows both readings side by side, not just the tool’s score.

4. Findings: evidence, proof of concept and reproduction steps

Each finding should let your team reproduce the problem without calling the vendor. At minimum:

A stable title and identifier, to track through remediation and retest.
Description of the flaw and where it lives (URL, parameter, function, component).
Evidence: screenshots, HTTP requests and responses, command output, with sensitive data masked.
Numbered reproduction steps, in the order they were executed.
Demonstrated impact: what an attacker actually gets from this finding, including when chained with others. This is what separates a pentest from a scan; see Scanner, pentest or bug bounty.
Preconditions: does it need authentication? Internal network access?

For an auditor, exploitation evidence is what proves the testing was manual and the flaw is real rather than a false positive.

An illustrative example of a well-written finding

The example below is fictional and only shows the level of detail to expect. It does not correspond to any real client.

Field	Content
ID and title	PM-004 — Access to other customers’ orders by changing the identifier in the API
Severity	High (CVSS 8.1, full vector in the appendix); adjusted to Critical in context because it exposes personal data of every customer
Where	`GET /api/v1/orders/{id}`, production, tested version stated in the scope
Precondition	Authenticated ordinary customer account; no internal network access
Evidence	HTTP request and response with masked data; screenshot of the response showing another account’s order
Reproduction	1) authenticate as customer A; 2) call the endpoint with the identifier of customer B’s order; 3) observe the 200 response with name, address and order items
Demonstrated impact	Reading any customer’s orders by enumerating the identifier, which amounts to a personal data incident
Recommended fix	Check server-side that the order belongs to the authenticated user (object-level access control); use non-sequential identifiers as defence in depth; automated authorisation tests
Retest status	Fixed: calling with another customer’s identifier now returns 403; evidence attached as PM-004-R1

Notice what makes this finding useful: your team can reproduce it alone, the auditor sees real exploitation, and the retest status closes the loop. To understand the class of flaw, see BOLA in APIs.

5. Remediation advice a developer can act on

"Apply security best practices" is not a recommendation. Useful remediation names the root cause, what to change (server-side validation, object-level access control, secret rotation), a technical reference and, where possible, a code or configuration example. It should also prioritize: what to fix in days, what can wait for the next cycle, and what needs a mitigation while the permanent fix is built.

6. Regulatory mapping

If the test exists to satisfy a requirement, the report should say which one. Instead of making the auditor guess, a traceability table links pentest activity to the requirement:

PCI DSS 4.0.1, requirement 11.4 (internal and external pentest, segmentation, retest). See Pentesting for PCI DSS 4.0.
ISO 27001, SOC 2 and GDPR, where they are part of your compliance agenda. See Penetration testing for ISO 27001, SOC 2 and GDPR.
Sector regulation that applies to your organization.

The report does not replace your legal or compliance team’s judgment on what a rule demands of you, but it should make that answer easy to give.

An example of a traceability table that makes the auditor’s life easier (the exact requirements depend on your standard and scope):

Pentest activity	Where it appears	Requirement it supports
External and internal testing with a named methodology	Scope and methodology section	PCI DSS 4.0.1, requirement 11.4
Segmentation testing of the cardholder environment	Segmentation section	PCI DSS 4.0.1, requirement 11.4
Evidence of exploitation and impact	Findings	Independent testing requirements for regulated institutions
Remediation and re-verification	Retest section	Requirements for documented remediation
Access control and data protection testing	Authorisation and data findings	Data protection security measures (GDPR art. 32, LGPD art. 46)

7. Retest: proof that the fix worked

The initial report shows the problem; the retest shows it is gone. The retest section should record the date, the status of each finding (fixed, partially fixed, not fixed, risk accepted) and evidence that the original attack no longer works. Many auditors treat a report without a retest as an open requirement. Before signing, ask the vendor whether retesting is included and within what timeframe.

8. Attestation letter and summary for third parties

Enterprise customers rarely want the full report: it details your vulnerabilities. What they ask for is an attestation letter (or summary) confirming who tested, when, the scope, the methodology and the overall result, without exposing technical details. Confirm the vendor delivers both documents: the full technical report, with restricted distribution, and the letter you can share.

Red flags: the report that is a scanner dump

A huge list of findings with no prioritization or context.
Generic descriptions copied from public databases, identical for any customer.
No exploitation evidence, no reproduction steps.
False positives mixed in (a "vulnerable" version that is not exploitable in that configuration).
No mention of business logic, access control or chained flaws.
No declared scope, methodology or limitations.
No retest section and no attestation letter.

Checklist for receiving the report

[ ] Executive summary with verdict and priorities.
[ ] Scope, window, approach and limitations stated.
[ ] Named methodology (OWASP, PTES, NIST SP 800-115).
[ ] CVSS with vector and business-adjusted severity.
[ ] Each finding with evidence, reproduction steps and impact.
[ ] Specific, prioritized remediation advice.
[ ] Mapping to the standard that motivated the test.
[ ] Retest planned, with a timeframe.
[ ] Attestation letter for third parties.
[ ] Sensitive data masked and document confidentiality defined.

Questions to ask the vendor before you sign

Can I see an anonymised sample report before signing?
Who writes the report and who reviews it? Is there a second-person review?
Does the report give the full CVSS vector and a severity adjusted to my business?
Is the retest included? How many rounds and within what time?
Will I get the attestation letter to show customers?
How are sensitive data found during the test handled, stored and destroyed?
Does the report map findings to the standard that motivated the test?

Want to see how this looks in practice?

We can send an anonymized sample report so you can compare it with what your current vendor delivers. Request it through the quote form and mention that you want the sample; if you already have a scope in mind, ask for a proposal at the same time.

Frequently asked questions

How many pages should a pentest report have?

There is no right number. It depends on scope and findings. Structure matters more than length: a short executive summary, findings with evidence and reproduction, and technical appendices kept separate.

Can the report be handed to customers and auditors?

The full technical report is normally restricted, because it describes weaknesses in your environment. For third parties use the attestation letter or a summary, and share the full report only under a confidentiality agreement.

Can a vulnerability scan replace a pentest report?

No. A scan lists possible known flaws; a pentest exploits them, chains them and demonstrates impact. Many standards and auditors expect the latter.

What is the difference between a pentest report and a scan report?

A scan report lists possible vulnerabilities detected by a tool, usually with false positives and no proof of exploitation. A pentest report records what a professional managed to exploit, chain and demonstrate, with evidence, impact and remediation. More in Scanner, pentest or bug bounty.

How long should I keep the report?

It depends on the standard and your company policy. Regulated institutions and compliance programmes often require evidence to be kept for several years. Confirm the period with your compliance team and keep the report and the retest together, with restricted access.

Who inside the company should receive the report?

The full report should go to a small, defined group: the CISO or security owner, the technical leads who fix issues and, where needed, compliance. Decide this before the test, since the document describes how to attack your environment.

Is the retest included in the report?

It depends on the contract. Before signing, confirm whether retesting is in the price, how many cycles, within what timeframe, and whether the report is reissued with updated status.

How do I know the severity ratings are right?

Ask for the full CVSS vector and the justification of business impact. If severity appears to come straight from a tool with no analysis, push back.