A walkthrough of a VAPT report: executive summary, scope, methodology, CVSS severity ratings, evidence, remediation guidance and retest status, plus what auditors and customers look for.
Who a VAPT report is for
A VAPT report has three audiences. Leadership needs a short summary of overall risk and what must be fixed first. Engineers need precise, reproducible details so they can fix issues quickly. Auditors, customers and regulators need evidence that testing was scoped properly, performed with a recognised method and that serious issues were remediated. A good report serves all three without forcing any of them to read the parts meant for others.
Core sections of a VAPT report
Executive summary: overall risk posture, counts by severity and the most important business impacts in plain language. Scope: exactly which applications, URLs, APIs, IPs and roles were tested, the test dates and anything excluded. Methodology: the approach followed, for example OWASP testing guidance for web and APIs, OWASP MASVS for mobile, or PTES and NIST SP 800-115 style phases for infrastructure. Findings: each issue documented in detail. Remediation summary and retest status: which findings are fixed, verified or accepted as risk. Appendices: tools, raw evidence and tested asset lists.
Anatomy of a single finding
Each finding should include a clear title, affected asset or endpoint, severity rating, description of the weakness, step-by-step reproduction, evidence such as requests, responses or screenshots, business impact explained for your context, and specific remediation guidance with references. For example, a finding about one user reading another tenant's invoices should name the endpoint, show the modified request and explain that object-level authorisation checks are missing on the server.
Severity ratings and CVSS
Most reports rate severity as Critical, High, Medium, Low or Informational, often using the Common Vulnerability Scoring System (CVSS) as a baseline. CVSS measures technical characteristics such as attack vector, complexity, privileges required and impact on confidentiality, integrity and availability. Good testers then adjust for context: a medium CVSS issue on a payment flow can matter more than a high CVSS issue on an isolated test server. Ask that any adjustment be explained in the finding.
What auditors and customers look for
For SOC 2, ISO 27001 and PCI DSS evidence, auditors usually check that the test is recent, the scope covers in-scope systems, the tester was independent, findings were tracked and high-risk issues were remediated and retested. Enterprise customers often ask for a summary letter or the executive section rather than the full technical report. Confirm with your auditor or regulator whether they require a specific report format or a particular category of auditor before you start.
Signs of a weak report
Watch for raw scanner output pasted with little analysis, findings without reproduction steps, generic remediation such as update your software, no clear scope or dates, many informational items padding the count and no business logic or authorisation findings on a complex application. These suggest little manual testing happened. Ask a prospective vendor for a sanitised sample report before you sign.