Process
How to read a penetration test report
Published Updated 5 min read
The short answer
Read a penetration test report from the top down: the executive summary tells you the overall risk, and each finding should show evidence, steps to reproduce, business impact, a specific fix and its retest status. Do not prioritize on the severity label alone; rank findings by what an attacker could actually reach in your environment and how easy it is to exploit. A finding without evidence or a clear fix is a question for the vendor, not a task for your engineers.
What is in a penetration test report?
Formats vary, but a useful report has the same parts. Use this as a checklist when a report arrives:
| Part | What it should tell you | Warning sign |
|---|---|---|
| Executive summary | Overall risk in plain language, the most serious issues, and what to do first | A list of counts by severity with no narrative |
| Scope and method | What was tested, when, with which access level, and what was excluded | No dates, no account roles, no out-of-scope list |
| Findings | One entry per issue with severity, affected assets and description | Dozens of near-identical scanner entries |
| Evidence | Requests, responses, screenshots or data samples (redacted) proving the issue | "Potentially vulnerable" with no proof |
| Reproduction steps | Enough detail for your engineers to see the issue themselves | Steps that only work with the vendor's tools |
| Impact | What an attacker gains, in terms of your data and users | Generic text copied from a vulnerability database |
| Remediation | A specific fix for your stack, plus short-term mitigations | "Apply vendor patches" or "validate input" only |
| Retest status | Open, fixed and verified, or accepted risk, with dates | No retest section at all |
What should the executive summary tell you?
The summary is for leadership and should stand on its own. After reading it you should know whether anything is urgent, which attack paths matter most, and what the tester thinks your systemic weaknesses are. A good summary might say that a regular user could reach other customers' invoices through the API, and that the root cause is missing authorization checks across several endpoints.
If the summary only repeats counts ("3 high, 7 medium, 12 low"), read the high findings yourself before drawing conclusions. Counts say little: one chained path to customer data outweighs twenty low-impact header warnings.
What do severity ratings and CVSS scores mean?
Most reports rate findings as critical, high, medium, low or informational, often backed by a Common Vulnerability Scoring System (CVSS) score from 0 to 10. CVSS is maintained by the Forum of Incident Response and Security Teams (FIRST), and version 4.0 is the current edition. It is a consistent way to describe a vulnerability's technical characteristics, and it is widely understood.
Its limits matter. The CVSS v4.0 specification says the Base score reflects a vulnerability's severity based on its intrinsic characteristics, and treats risk assessment as a broader process that the score only feeds into. A Base score does not know that the affected server holds your payment data, or that it sits behind a VPN only five people use. CVSS v4.0 adds Threat and Environmental metrics for that context, and asks that scores be labelled (for example CVSS-B for Base only, CVSS-BTE when Threat and Environmental metrics are included) so readers know what they are looking at.
How should you prioritize the findings?
Treat the report's severity as a starting point, then adjust with your own knowledge. A practical order:
- Proven paths to sensitive data or control: authentication bypass, cross-tenant data access, exposed secrets, admin takeover. Fix these first, even if the score is moderate.
- Issues that are easy to reach: anything on the internet without authentication, or reachable by any signed-up user.
- Known exploited weaknesses: if a finding maps to a vulnerability in the Cybersecurity and Infrastructure Security Agency (CISA) Known Exploited Vulnerabilities catalog, attackers are already using it. The Exploit Prediction Scoring System (EPSS) from FIRST estimates likelihood of exploitation for published CVEs.
- Root causes behind several findings: one missing authorization layer may explain five findings. Fixing the cause closes them together.
- Hardening and informational items: schedule them, but do not let them crowd out the above.
For each finding, decide one of three outcomes: fix, mitigate (reduce exposure while a full fix is built), or formally accept the risk with a named owner and a review date. "We will get to it" is not one of the options.
How do you know a finding is real?
Evidence. A real finding shows what the tester did and what came back: the request, the response, and a redacted sample of data they should not have seen. Reproduction steps should let one of your engineers confirm it in minutes without special tooling.
Findings marked "potential" or "possible" without proof are often false positives carried over from automated scanning. They are not worthless, but they belong in a separate list for your team to check, not in the critical column. This is one of the main differences between a scanner and a penetration test.
What questions should you ask the vendor?
- Which findings were exploited by hand, and which come from automated tools?
- Were severities adjusted for our environment, and on what basis?
- Which findings share a root cause, and what is the single fix for that cause?
- Did you chain any findings together? What was the most damaging path you found?
- What did you not get to test, and why (time, access, stability)?
- Is a retest included, what does it cover, and how will closure be documented?
- Is there a version of the report we can share with customers or auditors?
The answer to "what did you not test" is as important as the findings. A clean report on half the scope is not a clean report.
What does retest status mean in a report?
A final report should say, for each finding, whether a fix was verified by re-running the original attack. "Fixed" according to a ticket and "fixed" according to a retest are different things, and auditors increasingly ask for the second. Our guide to retesting and fix verification covers why fixes fail and what proper closure looks like.
How Brexa approaches this
Brexa reports only what a human operator has reproduced: if an attack path cannot be proven, it is not reported. Each finding goes to the owner of the fix with exact steps, and closes only after the original attack is re-run and fails. Findings, evidence, remediation tracking and reports live in the client portal.
Frequently asked questions
Who should read a penetration test report?
Leadership should read the executive summary, and the engineers who own each affected system should read their findings in full. The security or IT lead usually coordinates prioritization and the retest.
Should we share our penetration test report with customers?
Customers and auditors often ask for evidence of testing. Many vendors provide a summary letter or a redacted report for this, so you are not sharing exploit details or open findings publicly.
What does an informational finding mean?
It is an observation that is not exploitable on its own, such as a missing security header or verbose version banner. It may still be worth fixing as hardening, or because it helps an attacker in combination with something else.
What if we disagree with a finding's severity?
Raise it with the vendor and explain your context, such as compensating controls or limited exposure. A good tester will either adjust the rating with a note or explain why the risk is higher than it looks.
Sources
Written and reviewed by the Brexa team. Educational information, not legal or compliance advice. See our editorial policy.
Keep reading
Find out what an attacker could do with your systems.
Book a short scoping call. Nothing is tested until scope and rules of engagement are signed, and every finding comes with proof.