How to Read a VAPT Report: A Buyer's Guide

The first page should be written for someone who does not read scanner output. It should say how exposed you are, which problems matter most and what to do about them, in plain language. If the summary only restates the number of findings by severity, the report is not doing its first job.

Before reading any finding, confirm what was tested. The scope should list the applications, addresses or environments, the roles used, the dates and anything left out. A clean report on a narrow scope says little about everything outside it.

Findings usually carry a severity, often from CVSS 3.1. The base score runs from 0 to 10, and the usual bands are low (0.1 to 3.9), medium (4.0 to 6.9), high (7.0 to 8.9) and critical (9.0 to 10.0). Start with critical and high. A score describes a weakness in general, so a good tester also explains what it means in your system.

• A clear title and the affected asset.
• Steps to reproduce it, so your engineer can see the problem for themselves.
• Evidence, such as a request and response or a screenshot.
• The impact: what an attacker could do with it here.
• A recommended fix, specific enough to act on.

A finding without reproduction steps is hard to fix, and one without a fix leaves your team to work it out alone.

Several medium findings can combine into a critical one. A report that explains how weaknesses link, for example a leaked identifier plus a missing ownership check, shows that the tester looked beyond the list. Chains often decide what to fix first, because breaking one link can neutralize several findings.

Good reports also say what was tested and found sound. That coverage section, often a matrix against a standard such as the OWASP Top 10, tells an auditor or customer what ground was covered, and it tells you what you do not need to worry about.

A report is most useful after the fixes. Look for a way to record a retest: which findings were fixed, which remain and what changed. Ask how the retest works before you sign, because terms differ between vendors.

• Which findings could be exploited together?
• Which fix removes the most risk for the least effort?
• What was not tested, and why?
• Were any findings confirmed only by a scanner?
• How will you confirm our fixes?

To see how these parts look in practice, read our sample VAPT report, which is illustrative and contains no client data.