How to Read a Penetration Test Report (and What to Fix First)
You paid for a penetration test, and now you have a 40-page PDF full of severity ratings and HTTP requests. This guide explains how to read it, decide what matters, and turn it into fixes.
The usual sections
Most reports follow the same structure:
- Executive summary. Overall risk, key themes and the most serious issues. Written for leadership and customers.
- Scope and methodology. What was tested, when, with what access, and against which standards.
- Findings summary. A table of issues by severity.
- Detailed findings. One section per issue with description, impact, evidence, reproduction steps and remediation.
- Appendices. Tools used, tested URLs, and sometimes raw output.
Read the scope first. If something important was not tested, that is a gap, no matter how clean the results look.
Understanding severity
Severity usually combines impact (what an attacker could do) and likelihood (how easy it is). Many reports use CVSS scores, others use a simpler scale.
| Severity | What it usually means | Example |
|---|---|---|
| Critical | Direct compromise of data or systems, easy to exploit | SQL injection on a login form, RCE |
| High | Serious impact or easy access to sensitive data | IDOR exposing other customers' invoices |
| Medium | Real risk but needs conditions or limited impact | Stored XSS visible only to admins |
| Low | Minor or hard to exploit | Missing security headers |
| Info | Observations, best practice | Software version disclosure |
Severity is a starting point. Your context matters: a "medium" issue in your payment flow may deserve more urgency than a "high" on an internal tool.
Read the evidence, not just the title
Good findings include proof: the request, the response, and what it demonstrates. Ask of each finding:
- Is it verified? Did the tester actually exploit it, or is it a scanner guess?
- What is the real impact? Which data or actions are exposed, and to whom?
- Is it a pattern? One IDOR often means the same missing check exists across many endpoints.
Unverified findings waste engineering time. Prefer reports where every issue was confirmed.
Prioritising fixes
- Critical and high issues in production, starting with anything exposing customer data or allowing account takeover.
- Patterns: fix the root cause, such as a shared authorisation middleware, rather than patching one endpoint.
- Quick wins: headers, configuration and dependency updates that take minutes.
- Medium and low issues, scheduled into normal sprints.
Close the loop with a retest
After fixing, retest. A retest proves the fix works, catches incomplete fixes, and produces the evidence auditors and customers want. Keep the original report, the tickets and the retest result together.
Turning reports into fewer future findings
Look for themes. If half the findings are access control, invest in a consistent authorisation layer and tests for it. If several are injection, review how queries are built. A report is most valuable when it changes how you build.
SecurityInfinity reports rank findings by severity, include evidence for every issue and give the exact fix, and you can rerun the test to verify. Get a pentest report.
Frequently asked questions
What is a false positive in a pentest report?
A reported vulnerability that does not actually exist or cannot be exploited. Verified testing minimises false positives by confirming each finding.
Should every finding be fixed?
Critical and high findings should be fixed promptly. Lower findings can be scheduled or formally accepted as risk with a documented reason.
Who should read the report?
Engineering leads for remediation, leadership for the executive summary, and compliance or sales teams for customer and audit requests.