How to Read a VAPT Report: A Guide for Non-Technical Founders

You commissioned a penetration test because a customer, an auditor, or your own board asked for one. Forty pages later, you have a PDF full of terms like "CVSS 7.5" and "IDOR" and a color-coded severity table — and the actual decision you need to make (what do we fix first, and how bad is it really) isn't obvious from the jargon. Here's how to read one without a security background.

Start with the executive summary, but don't stop there

A good report opens with two or three sentences of plain English explaining the real risk to your specific business — not a generic paragraph about "the evolving threat landscape." If the executive summary could be copy-pasted into any other company's report unchanged, that's a sign the rest of the report may be similarly generic. Read it for orientation, then go to the findings — the summary is a preview, not the substance.

Severity is a combination of two things, not one

Critical, High, Medium, Low, and Info aren't arbitrary labels — they usually map to a CVSS (Common Vulnerability Scoring System) score, which itself combines two ideas: how easy the issue is to exploit, and how bad it is if someone does. A Critical finding is typically both easy to trigger and severely damaging (full account takeover, unauthenticated remote code execution). A Medium might be severe but hard to reach, or easy to trigger but limited in impact. When you're prioritising, read the detail, not just the color — a report with ten Mediums that are all "verbose error messages" is a very different risk profile than one Medium that's "authentication bypass under a specific edge case."

The CVSS vector string is worth a glance

If your report includes a string like AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H, that's the actual math behind the severity number, and it's more informative than the number alone. AV:N means it's exploitable over the network (no physical access needed); PR:N means no privileges are required to attempt it — those two alone tell you whether this is "anyone on the internet" or "an already-authenticated insider." If your report gives you a bare number with no vector, ask for it; any competent testing tool can produce one.

"Steps to reproduce" is the single most important section

This is where you separate a real finding from an assertion. A trustworthy report shows you exactly what request was sent, to what endpoint, with what payload, and what response came back — enough that your own developer could follow the same steps and see the same result. If a finding has no reproduction steps, no request/response evidence, and no location, treat it with real skepticism — that's the profile of an unverified automated-scanner result that never got human review before it reached you.

Remediation advice should be specific to your stack

"Implement proper input validation" is not remediation guidance — it's a restatement of the problem. Good remediation tells your developer roughly what to change: which library to upgrade, which header to add and what value, which parameter to sanitise and how. If every finding in the report has the same three-sentence generic fix regardless of what the underlying issue was, that's a sign the report was templated rather than written for your application.

Check whether findings were confirmed, not just theorised

Look for a confidence or status field — "Confirmed," "Likely," "Needs review." A tester who actually exploited the issue and captured evidence should say so plainly. A finding genuinely worth flagging but not fully proven should be labeled as such, not dressed up as certain. If every single finding in a forty-item report is marked "Confirmed" with identical confidence, that's statistically unusual — real engagements produce a mix.

The remediation roadmap is your actual to-do list

A report that just lists findings in the order they were discovered makes you do the prioritisation work yourself. Look for a roadmap or action-plan section that's explicitly sorted by severity, ideally with a suggested owner and a target timeframe (Critical in 48 hours, High in a week, and so on). That section — not the raw findings list — is what you hand to your engineering team on Monday morning.