How to read a penetration test report

If you have just received your first penetration test report, it can read like a wall of jargon engineered to make you feel unqualified to open it. It is not. Under the acronyms, a good report is making a simple argument: here is what is wrong, here is how we know, here is how bad it is, and here is how to fix it. This is how to find that argument and act on it, and how to tell a serious finding from noise dressed up to look serious.

Start with severity, not the finding count

The first instinct is to read the total. Resist it. A report with forty findings is not worse than a report with four; it is usually just more thorough. What matters is severity, which combines how much damage a weakness allows with how easily it can be exploited. A single critical that hands an attacker every customer's data outranks forty low-severity informational notes, every time. Read top-down: criticals and highs are now, mediums are planned, lows and informational are logged and tracked. Let severity drive the queue, not the size of the list.

What the scores actually mean

Most reports lean on a few standardized labels. Knowing what each one is for keeps you from over- or under-reacting to it.

• CVSS is the Common Vulnerability Scoring System from FIRST, a 0 to 10 score for how severe a vulnerability is in the abstract. The current version 4.0 refined how exploitability and impact are weighed. Treat it as a useful comparison, not gospel: a 7.5 in a system nobody can reach may matter less than a 5.0 on your front door.
• CWE, the Common Weakness Enumeration from MITRE, names the class of flaw, for example CWE-639 for an authorization bypass via user-controlled key (an IDOR). It tells you what kind of mistake this is, which is what makes patterns across findings visible.
• CVE is a specific, publicly cataloged vulnerability in a known piece of software. CWE is the category; CVE is a named instance in the wild.

If you want the underlying logic of how testers weigh likelihood against impact, the OWASP Risk Rating Methodology is the clearest plain-language model, and most severity calls trace back to its shape whether the report says so or not.

Look for proof, not just a label

Here is the single most important habit, and it separates a real test from an expensive scan. For every meaningful finding, look for the evidence: a concrete proof-of-exploit that shows what an attacker could actually do, plus steps precise enough that your engineers can reproduce it. A finding that says "this parameter may be vulnerable to injection" is a hypothesis. A finding that shows the exact request that pulled another tenant's record out of your database is a fact. You fix facts. You argue about hypotheses, and arguing wastes the time you are supposed to be spending on remediation.

A finding without a proof is a guess in a nice font. If most of the report is unproven 'potential' issues, you bought a scan and someone called it a pentest.

The anatomy of a finding worth your time

A well-written finding has a predictable skeleton. When one is missing a bone, that absence is information.

1. 01A title and a severity, so it can be triaged at a glance.
2. 02The weakness class (CWE) and a CVSS score, so it can be compared and tracked.
3. 03Evidence: the request, the response, the screenshot, the payload that worked.
4. 04Reproduction steps clear enough for an engineer to follow without the tester present.
5. 05Impact stated in business terms: what an attacker gains, not just which function returned the wrong thing.
6. 06Remediation that is specific to your code and stack, not a copy-pasted advisory.

Then plan the retest

A finding is not closed when you push the fix. It is closed when someone verifies the fix actually works and that you did not quietly introduce a new gap next to the old one. A serious engagement includes a retest: you remediate, the testing re-runs against the same paths, and the report is updated to show the issue is genuinely resolved. This is also precisely the evidence an auditor wants to see, because it proves the control works, not just that you intended it to.

Red flags that you got a scan, not a test

A few tells separate a real engagement from automated output with a logo on it: findings with no proof-of-exploit, severities that are clearly just the raw tool score with no human judgment applied, remediation advice that could have been written without ever seeing your application, and no retest offered. A report you can hand to your board, your engineers, and your auditor and have all three understand it is the whole point. If you cannot, the problem may be the report, not you.

Uvy reports are written for all three of those audiences from one validated run: every exploitable finding carries a working proof-of-exploit, every severity reflects real exploitability in your context, every fix is specific to your code, and a retest to confirm closure is part of the engagement. See how it works.