Guides · ← All guides
Reading Your First Pentest Report: From Score to Action
Last updated: October 13, 2026 · 9 min read
You ran your first security assessment. Now you're staring at a report with a score, a list of findings in alarming colors, and the sinking feeling that your website is held together with hope. Take a breath. A pentest report is a foreign language, and this guide is the phrasebook: what the score means, how severity works, how to read a single finding line by line, and how to turn the whole thing into a fix list, including the conversation with whoever controls the budget.
Start with the score, then forget it
The 0–100 score is a summary, not a verdict. It's useful for exactly one thing: tracking change over time. A score that goes from 62 to 84 after a month of fixes tells a story; a single score in isolation tells you almost nothing. Two sites can both score 71 for completely different reasons: one with a single critical hole and otherwise clean config, another with forty minor nits and nothing dangerous. The number doesn't distinguish those. The findings do.
Don't chase 100, either. Some findings may be acceptable risks for your situation (an informational disclosure on a static marketing page, a missing optional header on a domain that only serves redirects), and that's fine as long as it's a conscious, documented decision rather than something you never read. The goal is a downward trend in real risk, not a perfect number.
How severity ratings work (and what CVSS has to do with it)
Findings are typically rated Critical, High, Medium, Low, or Informational. Behind those labels usually sits CVSS (the Common Vulnerability Scoring System, currently at version 3.1), which scores a vulnerability from 0.0 to 10.0 using standardized exploitability and impact metrics. The bands map roughly to Critical (9.0–10.0), High (7.0–8.9), Medium (4.0–6.9), and Low (0.1–3.9).
But the rating in your report isn't just the CVSS number. It combines two judgments: impact (what happens if this is exploited) and exploitability in your context (how easily it can be reached and abused). A critical finding is both damaging and easy: an exposed database with default credentials, reachable from the internet. A medium might be damaging but hard to reach, or easy to reach but low-impact. Read severity as a prioritization signal, and use the rough calendar: criticals this week, highs this month, mediums this quarter. Lows and informationals get fixed when you're already touching that configuration for another reason.
Anatomy of a finding: read one line by line
Reports intimidate because findings look technical. They're actually built from the same five parts every time. Let's dissect one, clearly labeled as a hypothetical example:
[HIGH] Exposed administrative interface at /phpmyadmin
Evidence: HTTP 200 at https://shop.example.com/phpmyadmin
(login page rendered, no IP restriction, no extra auth)
Impact: Direct database access if credentials are guessed or leaked;
brute-forceable from the entire internet.
Fix: Remove public access; reach via VPN/SSH tunnel. Add IP allowlist
as a second layer. Rotate database credentials.
Refs: CWE-306 (Missing Authentication for Critical Function)
Walk it piece by piece. The title tells you what's wrong in one line. The severity tells you when to fix it. The evidence is the most important part. It's the report showing its work: the exact URL, the exact response, what the scanner observed. Good evidence lets you verify the finding yourself in thirty seconds, which is exactly what you should do before changing anything. The impact translates the technical fact into business consequence. The fix is the remediation step, usually a configuration change. And references like the CWE number point to the standard catalogue entry for that weakness class, useful when your developer says "is this a real thing?" and you want an authoritative yes.
Once you can read one finding, you can read the report. They're all the same shape. The skill isn't technical. It's the discipline to read each finding's evidence before reacting to its color.
Triage each finding in three questions
For every finding, ask these in order:
1. Is it real? Automated assessments can produce false positives: a "finding" that's actually expected behavior. The classic: a missing-HSTS finding flagged on a domain whose only job is redirecting to the main site. Technically true, practically irrelevant. Verify against the evidence the report cites: check the header, the open port, the exposed path yourself — before you spend fix effort. A finding you can't reproduce is a finding you note and move on from, not one you rebuild infrastructure around.
2. Is it reachable? Context changes priority completely. A vulnerable service on an internal-only network, unreachable from the internet, is a different risk than the same service on a public IP. A debug endpoint behind your VPN is a note; the same endpoint on the open web is an incident waiting to happen. Adjust the report's severity with your architecture in mind. The scanner sees packets; you see the network diagram.
3. What's the cheapest fix? Most findings have a configuration-level fix: a header to add, a port to close, a directory to protect, a flag to flip. Start with the fixes that take minutes before the ones that take days. This isn't laziness. It's triage. Closing an exposed admin panel in ten minutes removes more real risk than a week-long project to add a header nobody exploits.
The conversation with whoever holds the budget
Here's the part first reports get wrong most often: they get read by one person. The score goes to management, the findings stay with the developer, and nothing connects the two. If you need fix time approved, don't forward the PDF and hope. Translate three findings into business language: what breaks, who it affects, and what the fix costs.
"We have a high-severity finding" means nothing to a non-technical decision-maker. "Our customer database admin page is reachable from the entire internet; if someone guesses the password they can read every order; the fix is half a day and removes the page from public access." That's a decision someone can make. Lead with the criticals and highs, give each a one-sentence impact and a fix cost in time, and ask for the calendar space explicitly. Reports that live in one inbox change nothing; reports translated into resourcing decisions change everything.
Build the remediation plan
Turn the report into a simple ordered list: critical and high findings first, each with an owner and a deadline. Group related fixes: all the missing headers go in one configuration change, all the exposed paths in one server-hardening pass, all the open ports in one firewall review. Batching matters because every change window has overhead; five header fixes in one deploy cost barely more than one.
Two habits separate teams that improve from teams that re-scan the same findings forever. First, document accepted risks: for anything you consciously won't fix, write one line: what it is, why it's acceptable, who decided, and when you'll reconsider. An accepted risk with a review date is risk management; the same finding ignored is negligence with extra steps. Second, re-scan to verify after fixing. A fix you didn't verify is a fix you assume, and assumptions are how the same finding appears in next quarter's report with an older date on it.
Then schedule the next assessment after every major deployment at minimum, quarterly otherwise. The report is a snapshot; your site is a moving target.
What the report won't tell you
An automated assessment covers the fundamentals: configuration, exposure, encryption, known weaknesses. It won't find business-logic flaws (a discount code that stacks infinitely, a price field the browser sends and the server trusts). It won't test your team against phishing or review your source code for injection flaws. It won't tell you whether your backups actually restore, or whether the admin account of your ex-contractor is still active.
Treat the assessment as the first layer (the baseline every site should clear) and bring in human testing for what matters most to your business. The report's blind spots aren't failures; they're the boundary between what machines check well and what needs a thinking adversary.
The takeaway
A pentest report isn't a judgment; it's a to-do list written by someone (or something) that looked at your site the way an attacker would. Learn the shape of a finding, verify before you fix, translate the top items into decisions, document what you accept, and verify what you fix. The sites that get breached aren't the ones with imperfect scores — they're the ones that never looked.
Frequently asked questions
What does the score on a pentest report mean?
The 0–100 score is a summary, not a verdict. Its real value is tracking change over time — a score moving from 62 to 84 after a month of fixes tells a story; a single score in isolation tells you almost nothing. Work the findings top-down by severity instead of chasing 100.
How do I handle false positives in a security report?
Verify each finding against the evidence the report cites before fixing: check the header, the open port, or the exposed path yourself. If a finding is real but not exploitable in your context, document it as accepted risk with a reason and a review date rather than ignoring it.
What is CVSS and how does it relate to severity ratings?
CVSS (Common Vulnerability Scoring System, version 3.1) scores vulnerabilities from 0.0 to 10.0 on exploitability and impact. Severity bands map roughly to Critical (9.0–10.0), High (7.0–8.9), Medium (4.0–6.9), Low (0.1–3.9). Your report's ratings combine that with your context, mainly how reachable the flaw is.