Writing a Pentest Report People Act On

The report is the product. Clients don’t see your clever technique. They see a document that determines whether anything gets fixed. A brilliant test with a weak report is a failed engagement.

Know your two audiences

Reader	Wants	Reads
Executives	Risk, business impact, what to fund	The executive summary, maybe the findings table
Engineers	Exactly what is broken and how to fix it	Every finding, in detail

Write separate sections for each. Never make an executive read a stack trace, or make an engineer guess at reproduction steps.

Structure

1. Executive summary. One page, plain language. Overall risk, the two or three issues that matter most, and the strategic theme. For example: “Authorization is enforced in the UI but not the API.”
2. Scope and methodology. What was tested, when, from where, and what was excluded. This protects you and the client.
3. Findings summary table. Every finding with a severity and a status.
4. Detailed findings. One section per issue.
5. Appendices. Tool output, a full host list, and credits.

Anatomy of a finding

### H-02: Any user can read other organizations' invoices (IDOR)

**Severity:** High (CVSS 4.0: 7.1)
**Affected:** api.example.com, GET /v2/orgs/{id}/invoices

**Description**
The endpoint returns invoices for the organization ID in the path without
checking that the authenticated user belongs to that organization.

**Impact**
Any registered user, including free accounts, can read billing names,
addresses, and totals for every customer, which is roughly 40,000 organizations.

**Evidence**
Request and response pair, with session tokens redacted.

**Reproduction**
1. ...

**Remediation**
Enforce organization membership in the shared authorization middleware
rather than per endpoint, and add a regression test that requests another
organization's resources and expects HTTP 403.

**References**
OWASP API Security Top 10: API1 Broken Object Level Authorization

Rate severity honestly

Use a standard such as CVSS 4.0, then adjust for context and explain the adjustment. A SQL injection on an internal app with no sensitive data isn’t the same risk as one on the login page of a payments API, even if the base scores match.

Inflated severities destroy trust. If everything is critical, nothing is.

Remediation advice that actually helps

• Fix the class, not the instance. “Add parameterized queries in the data access layer” prevents the next ten bugs. “Escape this one parameter” fixes one.
• Be specific to their stack. If you know they run Rails or Django, name the framework feature that solves the problem.
• Give a verification step. Tell them how to confirm the fix works, so the retest is a formality.

Chain findings into a story

Experienced testers stand out by showing how low-severity issues combine. For example, an information leak plus a weak password policy plus missing MFA adds up to account takeover. Present attack chains as their own section, with a simple diagram. That’s often the part executives remember.

Quality checklist before you send

• Every finding can be reproduced from the report alone.
• All secrets, tokens, and personal data are redacted.
• Severity ratings are consistent across findings.
• Client names and hostnames are correct everywhere. Reusing a template from another client is a classic, career-damaging mistake.
• A colleague has peer reviewed it.