What a useful penetration test report actually contains

The report is the product. Testing is the work, but the report is the only part of an engagement most stakeholders will ever read, and it is what gets forwarded to the customer, the investor, or the auditor who asked whether you had been tested.

A lot of reports fail as documents. They are exported scanner output with a logo on the front, sorted by severity, written for someone who already knows the application. Here is what makes one useful instead.

1. Scope and authorization, stated plainly

What was tested, from which accounts and roles, over what dates, from which source addresses, and what was explicitly out of scope. This protects both sides, and it tells a future reader exactly how much assurance the document actually provides.

If the engagement was a focused review of one feature, the report should say so on the first page. A report that lets a reader assume more coverage than was performed is a problem, even when every finding in it is correct.

2. A summary a non-engineer can act on

Two or three paragraphs, no jargon: what was tested, what the overall picture looks like, what the most important thing to fix is, and what the risk is in business terms. A founder should be able to read this section and know whether to delay a launch.

3. Findings with evidence, not assertions

Each finding needs:

• What it is: one sentence, in plain language
• Where: the exact endpoint, parameter, role and conditions
• Evidence: the request and response, or the steps and screenshots, that prove it
• Impact: what an attacker gains, described concretely for this application
• Severity: with the reasoning visible, not just a colour
• Remediation: specific enough to turn into a ticket

The remediation section is where most reports get lazy. "Implement proper access control" is not remediation. "Enforce the tenant check in GET /api/v1/invoices/:id server-side; the current check runs only in the client" is.

4. Severity that reflects reality

Severity should account for how the application is actually used. An unauthenticated data exposure in a production system holding customer records is not the same as the equivalent issue behind an admin-only feature flag in staging. Rate the risk, not the CVE category.

5. Findings that are not vulnerabilities

Good engagements produce observations that are not exploitable but still worth knowing: missing hardening, weak defaults, logging gaps, architectural choices that will become problems as the team grows. Keep them, but keep them clearly separated from confirmed findings so nobody has to argue about the count.

6. Retest results

A finding is closed when someone re-runs the attack and it fails. The report should show the fix verification: what was retested, when, and the outcome. This is the section a client actually forwards to their customer, and it is the part most reports skip.

What we do

Every full engagement at Nextralix includes confirmed scope and written rules of engagement, manual testing with evidence collection, a report structured as above, a debrief call to walk through it, and one standard retest of reported findings. The debrief matters: a report you can ask questions about is worth considerably more than a PDF that lands in an inbox.