A penetration test report usually has an executive summary, scope and method, a findings list with severity ratings, evidence for each finding, and recommendations. Read the scope first, then the highest severity findings, then check that every claim has evidence you could reproduce. Questions beat skimming.
Start with scope and rules
The scope section says what was tested, when, from where, and with what access. It is the most important part for judging the result, because a clean report on a narrow scope says little about the rest of your estate.
Check these points:
- Were all systems you care about listed?
- Was the test done with credentials, without them, or both?
- Was it production or a copy?
- Were any techniques excluded, such as social engineering or denial of service?
- What were the test dates, and which build was tested?
If the scope differs from what you agreed, ask why before reading further.
The executive summary
This is written for managers. It should give an overall impression, count findings by severity, and name the main themes. Treat it as a pointer. A summary that says "good security posture" tells you the tester's opinion, not a measurement. Look for themes, such as repeated access control mistakes, that point to a design issue.
Method
A good method section names the approach and references. Many testers follow public guides. The OWASP Web Security Testing Guide is a free resource for web application testing, and NIST SP 800-115 is a technical guide to security testing and assessment. A report that names its method lets you see what was and was not covered.
Findings
Each finding should contain:
- A title and an identifier.
- Affected location.
- A severity rating and the reasoning.
- A description of the weakness.
- Steps to reproduce.
- Evidence, such as requests, responses or screenshots.
- A recommended fix.
Ask for what is missing. A finding with no reproduction steps cannot be fixed or retested reliably.
Be careful with severity. FIRST says a CVSS Base score measures severity and not risk, and should be supplemented by threat and environmental analysis. Treat the tester's rating as a starting point and discuss the context with them.
Attack chains
Some of the most valuable material is in the narrative of how several small issues combined. A medium information leak plus a medium access control gap can be a critical path. If the report lists findings in isolation, ask the testers whether any of them chain.
What was not found
Reports rarely say what was checked and found fine. Ask for a list of areas tested with no findings. It tells you what you can honestly say to customers, and what you still need to examine.
Recommendations
Good recommendations are specific and tied to a root cause. Generic advice such as "validate all input" is a sign of low effort. Prefer "this endpoint trusts the account id from the request body, so derive it from the session".
Questions for the debrief
- Which findings worry you most, and why?
- Which findings share a root cause?
- What did you try that did not work?
- What would you test next if you had more time?
- Can you retest the fixes, and when?
Keep it safe
A report is a map of your weak points. Limit access to the people who need it, and share customer summaries rather than the full document.
Quick check
Is a report with few findings better?
Not necessarily. It may reflect a narrow scope, short time, or limited access. Read the scope and ask what was tested.
Should we dispute a rating we disagree with?
Yes, with reasons. Record both ratings, the tester's and yours, and keep the reasoning.
Sources
Last reviewed: 19 October 2026.
