What Is Actually Inside a VAPT Report

A vulnerability assessment and penetration test ends in a document. For most people that document arrives before they have ever seen another one, which makes it very hard to tell a thorough piece of work from an expensive export of a scanner.

This walks through the sections a full report contains, what each is for, and the specific thing worth checking in each. It is written to be read with a report open beside it.

1. Executive summary

One or two pages, written for people who will not read the rest. It states the scope in a sentence, the number of findings by severity, and what the overall risk position is.

What to check: whether it tells you anything a table of counts would not. "Four critical, eleven high" is arithmetic. A useful executive summary says which of those findings would matter most if it were exploited tomorrow, and what an attacker could actually reach. If the summary would read identically for a different company with the same severity counts, it was written from a template.

2. Methodology

Two things belong here: the scope, and the standards the work was performed against.

Scope

The list of what was tested — applications, hosts, APIs, environments — and the testing perspective used, such as unauthenticated, authenticated, or authenticated as several different roles.

What to check: whether the exclusions are written down. A scope that lists only what was tested is half a scope. The valuable version records what was deliberately left out and why — a third-party payment page, a production database, a system frozen for a release — because that is the part you will be asked about later, and reconstructing it from memory a year on is not possible.

Standards and frameworks

Which methodology the testing followed and which classification schemes the findings use. Commonly OWASP for application work, CWE for the underlying weakness class, and CVSS for scoring.

What to check: that they are named specifically. "Industry best practice" is not a standard. A version number is a good sign: OWASP ASVS has levels, CVSS has v3.1 and v4.0, and PCI DSS v4.0 is materially different from v3.2.1.

3. Detailed findings

The body of the report, and where its quality is decided. Each finding is a self-contained unit. A complete one carries:

• An identifier — F-001, F-002 — so it can be referenced in email, in a ticket, and in the retest without ambiguity.
• A title that describes the flaw, not the tool that found it.
• A severity, and a CVSS vector — not just "9.8" but the string behind it, such as AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H. The vector is what makes the number arguable, and being able to argue with a score is the point of publishing it.
• A weakness class, usually a CWE number, which is how the finding connects to everything else ever written about that class of bug.
• Where it is — the endpoint, parameter or component.
• Reproduction steps and evidence.
• Remediation guidance specific enough to act on.

What to check: the reproduction steps. This is the single most reliable test of whether a finding was verified by a person. A scanner reports a pattern it matched; a tester reproduces the outcome and shows you the request that did it. If a critical finding cannot be reproduced from what the report gives you, nobody can confirm it is fixed either.

The second check is whether severity is contextualised. The same flaw does not carry the same risk in a system holding payment data as in an internal scheduling tool, and a report that never adjusts for that is scoring the technique rather than your exposure.

4. Remediation roadmap

The findings re-cut as work: what to do, in what order, and by when. A useful roadmap has four columns — priority, action, owner and timeline.

What to check: the owner column. A list of fixes with no owners is a list of fixes that will not happen. This is also the section where a report either understands your constraints or does not: recommending an immediate upgrade across an estate that has one change window a quarter produces a document nobody can act on.

5. Compliance mapping appendix

Each finding mapped across to the frameworks you answer to — OWASP ASVS, PCI DSS, ISO 27001, and the CERT-In requirements where they apply.

What to check: whether it exists at all. Many reports stop at the roadmap. The mapping is what turns a technical document into evidence you can hand to an auditor without doing the translation yourself, and reconstructing it afterwards means re-reading every finding against every framework.

The section that is missing more often than any other

Retest. A report describes a moment; the question that matters is whether the findings are closed now. A finding marked fixed and never retested is an open finding with optimism attached.

Before commissioning any test, establish three things: whether retesting is included or billed separately, how long the retest window stays open, and whether the retest produces its own dated document. That last one is what an auditor asks for, and the answer "we fixed it" is not it.

Reading one for yourself

Every observation above is easier to make against a real document than a description of one. Security Brigade publishes complete sample reports — web application, network, red team and secure code review — with the finding detail, the CVSS vectors, the remediation roadmap and the compliance mapping intact.