How to Read Your First Pentest Report
Your first pentest report can look intimidating. Here is how to read it, what to fix first, and which parts to push back on.
You just got your first penetration test report back. It is long, it is full of red and orange labels, and somewhere in there is a critical finding that made your stomach drop. Take a breath. A report that looks alarming is usually a report that did its job.
Here is how to actually read one.
Start with the executive summary, then ignore the panic
The summary at the top tells you the shape of the results: how many findings, how they break down by severity, and the tester's overall read on your posture. Read it once for orientation. Do not let the raw finding count set your mood. Ten low-severity findings and one critical are two very different situations, and the total number hides that.
What you care about is the distribution and the story behind it.
Understand what severity really means
Severity ratings usually combine two things: how bad the impact would be, and how easy the issue is to exploit. A critical finding is typically something an attacker could use right now, with real consequences, without needing a chain of lucky conditions.
A rough way to triage:
- Critical and High. Treat these as work for this week. These are the ones an attacker would reach for first.
- Medium. Plan these into the next sprint or two. Real issues, less urgent.
- Low and Informational. Track them. Some are worth fixing, some are hardening suggestions, and a few are just observations.
One caution: severity is a judgment call, and context matters. A "medium" on an internal admin tool behind a VPN might be a "high" on a public checkout page. Adjust for your own environment.
Read the evidence, not just the title
A good finding does more than name a vulnerability. It shows you the request that triggered it, the response that came back, and the steps to reproduce it. This is the part that turns a scary label into an actionable task.
If a finding has a title and a severity but no evidence you can follow, that is your cue to ask questions. You should be able to hand the reproduction steps to an engineer and have them see the same thing.
It is fine to push back
Testers are good, and they are also human working against a clock. Sometimes a finding is a false positive. Sometimes the described impact does not apply because of a control the tester did not have visibility into. You are allowed to dispute a finding.
The right way to do it is with evidence of your own. "We think this is wrong" carries no weight. "This endpoint requires a signed token that the tester did not have, here is the middleware that enforces it" carries a lot. A finding should survive that kind of scrutiny, and if it does, you have learned something real.
Turn the report into a plan
Once you have read it, the report becomes a backlog. Group the findings, assign owners, set target dates by severity, and schedule a retest for the criticals once they are fixed. The retest matters. A fix you never verified is a fix you only hope you made.
Your first report is a baseline. The second one, after you have worked through this, is where you get to see how far you have come.