How to read a penetration testing report, section by section

Read the executive summary first, then the findings at a glance, then each finding in order of severity. Treat the report as a work list. Each finding should lead to a fix, a check, and a close-out.

The structure below is that of an Excession Labs report. Other providers use different section names, but the parts are similar. To see the structure with real formatting, open the demonstration report.

What are the sections of a pentest report?#

An Excession Labs report has these sections, in this order:

1. Project details: scope, assets and the severity scale.
2. Assessment method.
3. Safety constraints.
4. Evidence labels.
5. Executive summary with priority actions.
6. Findings at a glance.
7. Reproduction environment.
8. One section per finding: description, impact, verified results, reproduction, remediation.
9. Controls that held.
10. Remediation plan.
11. Limitations and open questions.
12. Evidence index.
13. Appendix of reproduction scripts.

What do the first sections tell you?#

The opening sections tell you what the report covers and how far to trust it. Read them before the findings, because they set the limits of every claim after them.

Project details: check the scope. Does the list of assets match what you asked for? Anything not listed was not tested. Check the severity scale and its definitions here too.

Assessment method: this says what the tester did: direct HTTP requests, browser tests, review of client-side code, comparison of anonymous and signed-in users. A black box report and a grey box report mean different things. See black box, grey box and white box testing.

Safety constraints: this lists what the tester did not do, how risky tests were bounded, and which test-owned accounts and records were used.

Evidence labels: "Observed" means the tester reproduced it. "Browser-observed" means it was shown in a real browser. A path labeled as inferred was not proven, so do not treat it as confirmed.

How do you read the executive summary and findings at a glance?#

The executive summary gives the overall picture and the priority actions. Use it to brief management. The findings at a glance table lists every finding with its ID, title and severity. Use it to build your ticket list.

Check that the summary agrees with the table. If the summary says "two high findings", the table should show two. A report that disagrees with itself needs a question to the tester.

What is in a finding?#

Each finding has five parts. Read all five before you open a ticket.

The verified results part is the proof. A bare "success" response is not proof: a write is proven when the changed record is read back through another session, so look for that read-back.

An annotated sample finding#

F-02: Any signed-in user can read another tenant's notes (High)

Description. The GET /api/notes/{id} endpoint checks that the caller is signed in. It does not check that the note belongs to the caller's tenant.

Impact. A user in tenant A can read any note in tenant B by guessing or enumerating numeric IDs. Notes may hold customer data.

Verified results. Observed. With Bob's session (tenant B), a request for note 4021, created by Alice (tenant A), returned HTTP 200 and Alice's content.

Controls. A request for a nonexistent ID returned 404. A request with no token returned 401. A request with Bob's token for Bob's own note returned 200. So the server checks identity but not ownership.

Reproduction. Sign in as the test user in tenant B. Send the request below with the ID of a note that belongs to tenant A.

GET /api/notes/4021 HTTP/1.1
Host: app.example.com
Authorization: Bearer <tenant B test token>

Remediation. Load the note with the tenant ID in the query. Return 404 when the note is not in the caller's tenant. Add a test that fails when a second tenant can read the note.

What is the difference between severity and priority?#

Severity is the tester's rating of how bad a flaw is in general. Priority is your decision on what to fix first.

Severity comes from a written scale. Excession Labs uses four levels: Critical, High, Medium and Low, each with a written definition. CVSS vectors are not added by default. If your program needs CVSS, say so during scoping. For reference, FIRST's CVSS v4.0 qualitative bands are Low 0.1 to 3.9, Medium 4.0 to 6.9, High 7.0 to 8.9 and Critical 9.0 to 10.0.

Priority adds your context:

• Exposure: is the endpoint public or internal?
• Data: does it touch customer data, money or credentials?
• Effort to fix: a one-line fix can go first even at Medium.
• Chains: two Medium findings may combine into a High impact. The report may say so.
• Deadlines: a customer review or audit date can raise priority.

Write your priority next to the tester's severity. Keep both.

How do you reproduce a finding?#

Run the reproduction steps in a test environment with a test account. Reproduction shows that your team understands the flaw and gives you a before-and-after check for the fix. Follow these rules:

1. Run scripts only with authorization and only with test-owned identifiers.
2. Prefer a staging copy. Reproduction scripts are read-only where possible, but check each one.
3. Save the output before the fix and after the fix.
4. If you cannot reproduce a finding, do not close it. Tell the tester and share your environment details, because the tester may have used a state you do not have.

What are "controls that held"?#

This section lists protections that the tester tried to break and could not. Keep these controls working when you change code: a fix for one finding must not remove a control that held. Turn them into regression tests.

How do you use the remediation plan?#

The remediation plan puts the fixes in order. Use it as the base of your backlog, then add owners and dates.

Our guide to after the pentest: remediation and retest gives a full workflow. When fixes are done, ask for a retest. See retesting.

What do limitations and the evidence index mean?#

The limitations section states what the tester could not check or could not confirm. An open question is neither a confirmed issue nor a clean result, so decide whether to scope it into the next test.

The evidence index lists saved requests and responses with timestamps. Key evidence can carry a SHA-256 manifest, so you can check that files were not changed. Keep these files with the report, because auditors and customers may ask for them.

What should you check before you share the report?#

Check that it does not contain secrets, live tokens or customer data, and check your contract for confidentiality terms. For customers, consider a shorter summary or an attestation letter. The PCI SSC guidance says its report outlines "are only suggested outlines and do not define specific reporting requirements for PCI DSS penetration tests". Ask your auditor what they need.

Judge us by the report

Every finding comes with the request, the response, the impact and a fix. See the demonstration report.

Open the sample reportRequest a test