If you've never read a penetration test report before, the severity ratings can be misleading. They look like dataset labels — Critical, High, Medium, Low, Informational — but they encode a judgment call that depends heavily on context.
Here's how to read them like someone who's written them.
What severity is, technically
Most testers use some variation of CVSS — a scoring system that combines two factors:
- Impact: How bad is it if the attack succeeds? Loss of data? Account takeover? Service disruption?
- Exploitability: How easy is it to actually do? Authenticated? Requires user interaction? Network-adjacent only?
A bug that lets an unauthenticated remote attacker read every user's data with a single GET request is the textbook Critical. A bug that lets a logged-in user view another user's profile preferences after performing five specific steps is more like Medium.
Why severity is often debated
The same bug can sit anywhere in the range depending on context. We routinely have conversations like this:
- "You marked this High, but it requires authentication."
- "Yes, but anyone can register an account on your site for free."
That's not a flaw in the methodology — it's the methodology working. Context shifts severity, and the context is yours, not ours. The best testers explain their reasoning in the report; the best clients push back when they disagree.
The hidden category
One thing executives miss in their first few reports: Informational findings are not "things we didn't quite find a bug in." They're notes about defense-in-depth, configuration drift, and patterns that aren't currently exploitable but make exploitation easier in the future.
A common example: "Application version disclosed in HTTP headers." On its own, severity zero. The day a vulnerability is published in that exact version, severity becomes whatever the CVE says. Informational findings often turn into real findings later.
What to actually do with each severity
Here's a practical workflow:
Critical
Stop what you're doing. Confirm the bug. Patch immediately. Treat as a potential breach — assume someone else has also found it. Consider whether logs need to be reviewed for prior exploitation. Communicate up the chain.
High
Patch this sprint. Test the fix. Verify with the testing team. If you can't patch within 30 days, document a compensating control (additional logging, monitoring, WAF rule).
Medium
Patch this quarter. Tracked in the regular backlog with a deadline. If a Medium has been open more than 90 days, either re-evaluate severity (might be lower than you thought, or higher), or escalate ownership.
Low / Informational
Bundle into a "hardening" sprint. Don't ignore — they accumulate. A clean Informational section in a report is rare and signals discipline.
The question to ask
The most useful question after reading a report isn't "are we okay?" It's "based on what you saw, what would worry you most if you were us?" A good tester has an opinion. Their answer is often more valuable than the entire report.