# Penetration testing report template: 12 sections and a filled finding

Source: https://penetrationtestservices.com/guides/penetration-testing-report-template/
Publisher: Excession Labs (penetrationtestservices.com)
Last updated: 2026-11-09

A penetration testing report template you can copy: 12 sections, a blank finding block in Markdown, a filled example, a severity scale and a buyer checklist.

> **Short answer:** A penetration testing report template has 12 sections: project details, method, safety limits, evidence labels, executive summary, findings at a glance, reproduction environment, one section per finding, controls that held, remediation plan, limitations and an evidence index. Each finding needs a description, impact, verified results, reproduction steps and a fix. No standard sets one mandatory format.

A penetration testing report template needs 12 sections, in a fixed order, and a finding block that forces evidence. Copy the structure below. The same list works as a buyer's checklist: if a vendor's report skips a section, ask why.

No standard sets one mandatory layout. PCI SSC's guidance says its report outlines "are only suggested outlines and do not define specific reporting requirements for PCI DSS penetration tests" (section 5.2, checked 9 November 2026). The template here follows the report format that Excession Labs delivers. You can see it filled in at our [sample penetration testing report](/sample-report/).

## What must a pentest report template contain?

A report has two readers. Leaders read the first page and decide what to fund. Engineers read the finding sections and fix things. The template serves both when the summary stands alone and each finding can be reproduced without the rest of the report.

| # | Section | What it answers | Buyer check |
|---|---|---|---|
| 1 | Project details | Who, what, when, under which authorization | Written authorization is named. Dates and version are present. |
| 2 | Scope and assets | Which hosts, roles and methods were in and out | Out-of-scope items are listed, not implied. |
| 3 | Assessment method | How the tester worked | Names the method, for example the OWASP WSTG or NIST SP 800-115. |
| 4 | Safety constraints | What the tester did not do to your systems | Limits on uploads, email, password guessing and paid APIs. |
| 5 | Severity scale and evidence labels | What "High" and "Observed" mean | Each level has a written definition. |
| 6 | Executive summary | What matters and what to do first | Counts match the findings table. Priority actions are listed. |
| 7 | Findings at a glance | One table of all findings | ID, title, severity, status, evidence label. |
| 8 | Reproduction environment | Accounts, tools, versions | Test accounts are named and marked as test data. |
| 9 | One section per finding | The problem, proof and fix | See the finding block below. |
| 10 | Controls that held | What was tested and worked | Present. A report with only failures hides what to protect. |
| 11 | Remediation plan and limitations | Fix order, owners, open questions | Open questions are kept apart from confirmed impact. |
| 12 | Evidence index | Where the raw requests and responses are | Files are listed. Hashes are optional. |

Sections 1 to 8 are the front matter. Most reports that fail a buyer's review fail here: the scope is vague, the severity scale is undefined, or the summary does not match the findings.

## What is the blank finding block?

The finding block is the part you reuse most. Copy this Markdown skeleton. It has five parts, and every part has a reason: the description lets a developer find the bug, the impact states the proven effect, the verified results show the proof, the reproduction lets a retest repeat it, and the fix tells the team what to change.

```markdown
## F-00: 

Severity: 
Evidence label: 
Status: 

### Description
What the feature does. Which check is missing or wrong. Name the route,
parameter or setting.

### Impact
What an attacker gains, with the access level they need. Say what was
proven and what is inferred. Do not mix them.

### Verified results
| Step | Account | Result |
|---|---|---|
|  |  |  |

Control: 

### Reproduction
Numbered steps. Test-owned identifiers only. Read-only where possible.

### Remediation
The change, the layer it belongs in, and a regression test to add.

### Evidence
File names for requests, responses and screenshots, with timestamps.
```

Two rules keep the block honest. First, "Verified results" needs a read-back for any write: a second account reads the changed record. A bare "200 OK" or `{"success": true}` proves nothing. Second, every finding carries a control, the request that should fail and does. Controls stop a team from reporting a bug that the application already blocks.

## What does the same finding look like filled in?

> **Demonstration finding:** This is a demonstration. No real customer system was tested. Harbor Notes is a fictional app, and the host uses the reserved `.example` domain. The full version is in the [sample report](/sample-report/).
```markdown
## F-01: Cross-tenant export through predictable export IDs

Severity: Critical
Evidence label: Observed
Status: Open

### Description
A workspace owner can export all notes as a ZIP. The download route
GET /v1/exports/{export_id}/download checks for a valid token but not for
membership in the workspace that owns the export. Export IDs are
sequential (exp_000412, exp_000413).

### Impact
A signed-in member of tenant B downloaded the full export of tenant A.
No special role was needed (Observed). Exports of other tenants are
probably reachable the same way (Inferred). We did not walk the ID range.

### Verified results
| Step | Account | Result |
|---|---|---|
| Create note "EXC-TEST marker-7f3a" in ws_test_A, start export | owner-a | exp_000412 created, status ready |
| Download exp_000412 | member-b | 200, ZIP of 2,318 bytes, contains the marker note |
| Download exp_000412 with no token | anonymous | 401 |

### Remediation
Add a workspace membership check to the download route. Switch to
random export IDs. Add a cross-tenant test for every route that takes an
object ID.
```

Compare the filled block with the blank one. Each field in the blank block has a concrete value, and the marker note `EXC-TEST marker-7f3a` is the read-back proof: tenant A wrote it, tenant B never received it, and it appeared in tenant B's download.

## How do you write the executive summary?

Write five sentences and add one table. The summary is what a CFO, a customer or an auditor reads, so it must stand alone.

1. State what was tested and in which window.
2. Give the count of findings by severity.
3. Describe the worst finding in plain words, with who can do what.
4. List the priority actions in order.
5. State what the test did not cover.

The table is the severity count. Take the counts from the findings table and say the date they were counted, so a later edit cannot make them drift. If a finding changed severity during the test, say so in the summary. In our sample, one finding started as High and ended as Low after a control showed the first reading was wrong.

Avoid a summary that opens with an overall score or a color. A rating without a definition invites the question "compared to what?".

## How do you define the severity scale and evidence labels once?

Define both near the top of the report, then use them everywhere. A reader who meets "High" in finding 3 must find its meaning in section 5.

A four-level scale (Critical, High, Medium, Low) with a written definition per level works without a scoring tool. A definition names the effect and the access needed. "An attacker can read or change data across tenants with no special access" is a Critical definition. "Small information value, no direct access to data" is a Low one.

CVSS is a different choice. FIRST describes CVSS as a way to capture the technical characteristics of a vulnerability and produce a numeric score. If your program needs vectors, agree that in the scope. Do not add a vector to every finding by habit, because a number can look more exact than the evidence behind it.

Evidence labels answer a separate question: how sure is the tester? Three labels cover most work.

| Label | Meaning |
|---|---|
| Observed | Reproduced with direct requests and confirmed by read-back or a control |
| Browser-observed | Shown in a real browser session, for example stored XSS that runs |
| Inferred | Believed from code review or signs, not proven. Kept out of confirmed impact. |

## How do you judge a report against the template?

Check these ten items before you accept a report or sign off a vendor. Each one is yes or no.

- The scope lists in-scope and out-of-scope assets and the authorization.
- The method is named and matches the work that the findings show.
- Safety limits are stated for uploads, email, password guessing and paid APIs.
- Severity levels are defined once.
- Every finding has an evidence label.
- Every write finding has a read-back.
- Every finding has a control or a statement of why none applies.
- A "controls that held" section exists.
- Open questions sit in their own section.
- Requests and responses are saved with timestamps, and the evidence index lists them.

A report that fails three or more of these items is hard to retest. For retests, keep the finding IDs and add a result per ID. PCI SSC's guidance outlines a retest report with the date of the original test, the date of the retest, the original findings and the results of the retest.

If you hold a report already, use [how to read a penetration testing report](/guides/how-to-read-a-penetration-testing-report/) to read it. For compliance evidence, see [PCI DSS penetration testing requirements](/guides/pci-dss-penetration-testing-requirements/) and the [pentest attestation letter](/guides/pentest-attestation-letter/) guide. Our [methodology](/methodology/) page describes how we test. A report does not make an organization compliant, and no standard we checked fixes one layout.

## Questions

### Does PCI DSS or any other standard set a pentest report format?

No. PCI SSC's Penetration Testing Guidance v1.1 says its report outlines are only suggested outlines and do not define specific reporting requirements for PCI DSS penetration tests. NIST SP 800-115 describes what to document but does not fix a layout. Your assessor may ask for more.

### How long should the executive summary be?

One page at most. Five sentences and one table are enough: what was tested, how many findings by severity, the worst finding in plain words, the priority actions, and what the test did not cover. Put detail in the finding sections.

### Should the report use CVSS?

Only if your program needs it. FIRST publishes CVSS as a scoring method, and many buyers ask for vectors. A written four-level scale with a definition for each level also works. Agree the method during scoping, not after the test.

### Can I reuse one template for a retest?

Yes, with a smaller shape. PCI SSC's guidance outlines a retest report with the date of the original test, the date of the retest, the original findings and the results of the retest. Keep the finding IDs the same so readers can match them.

## Sources

- [PCI SSC Information Supplement: Penetration Testing Guidance v1.1 (September 2017), section 5.2](https://listings.pcisecuritystandards.org/documents/Penetration-Testing-Guidance-v1_1.pdf)
- [NIST SP 800-115: Technical Guide to Information Security Testing and Assessment](https://csrc.nist.gov/pubs/sp/800/115/final)
- [FIRST: Common Vulnerability Scoring System (CVSS)](https://www.first.org/cvss/)
- [OWASP Web Security Testing Guide: Reporting](https://owasp.org/www-project-web-security-testing-guide/stable/5-Reporting/README)