Cybersecurity

How to Write a VAPT Report (With Free Template)

September 3, 2026 ·by Techonquer Team
How to Write a VAPT Report (With Free Template)
How to Write a VAPT Report (With Free Template)

How to Write a VAPT Report

A VAPT report has five required parts: an executive summary written for non-technical decision makers, a scope and methodology statement, a findings table ranked by risk, detailed findings with reproduction steps and evidence, and remediation guidance. The client pays for the report, not the exploit. If a finding is not documented clearly enough to reproduce and fix, it did not happen.

Reporting is the most undertaught skill in offensive security, and it is the one that decides whether you stay a junior. People fail the OSCP exam having compromised enough machines because their documentation was insufficient, which is the most realistic part of that exam. The full template is further down this page. Report writing is a graded module in our VAPT training program for exactly this reason.

Who actually reads your report

Three people, with completely different needs, and the structure exists to serve all three.

Reader Reads Wants
Executive or CISO Executive summary only Are we in trouble, how much, what does it cost to fix
Engineering manager Findings table What do I assign, to whom, in what order
Developer or sysadmin One detailed finding How do I reproduce this and what exactly do I change

Most junior reports fail because they are written for the fourth reader who does not exist: another penetration tester who wants to admire the exploit chain. That report gets read once and filed.

The five required sections

1. Executive summary

One page. No jargon. Written last, read first, and the only part most decision makers will see.

It must answer: what was tested, what was found, how bad it is in business terms, and what needs to happen. Business terms means customer data, financial loss, regulatory exposure, service availability. Not CVSS scores.

Compare:

  • Weak: "Three critical and seven high severity vulnerabilities were identified, including SQL injection and broken access control."
  • Strong: "The customer portal allows any registered user to read other customers' invoices and personal data without authorisation. We extracted records for 12,000 accounts in under two hours using only a standard user login. This is reportable under CERT-In directions and is fixable in an estimated two developer days."

The second version gets remediation funded. The first gets forwarded.

2. Scope and methodology

What was in scope, what was explicitly excluded, the testing window, the testing perspective (black, grey or white box), and the standards followed. Name the actual methodology: OWASP WSTG, PTES, NIST SP 800-115. "Industry standard methodology" means nothing and auditors will ask.

State limitations honestly. If a subdomain was out of scope, if testing was rate-limited, if a module was unavailable during the window, write it down. Undisclosed limitations are how reports get challenged later.

3. Findings summary table

Every finding on one page, ranked by risk, with an ID, title, severity, affected asset and status. This is the page the engineering manager works from.

4. Detailed findings

One per finding, in a fixed structure. This is covered in full in the template below.

5. Remediation and retest

Prioritised fix order, not just a list. Then a retest section confirming which findings were verified as fixed and which remain open. A finding is not closed until someone confirmed the fix works.

Severity: do not just paste the CVSS score

CVSS gives you a baseline. It does not know your client's business. A stored XSS in an internal admin panel used by four people and a stored XSS in a customer-facing checkout can produce the same CVSS number and wildly different real risk.

Rate severity as a function of technical impact and business context, and state your reasoning in one line. If you disagree with the CVSS output, say so and explain. Auditors and clients respect a defended rating far more than a pasted one.

Severity Means Expected action
Critical Full compromise, mass data exposure, or trivially exploitable remotely Fix immediately, consider emergency change
High Significant data exposure or privilege escalation with realistic preconditions Fix within the current sprint
Medium Real impact but requires chaining, authentication, or specific conditions Fix within the quarter
Low Minor exposure, limited practical impact Fix during normal maintenance
Informational No direct risk, hardening opportunity or defence-in-depth gap Track, fix at discretion

Inflating severity to make a report look valuable is the fastest way to lose a client's trust permanently. The second time a "critical" turns out to be a missing header, nobody reads your criticals again.

The free template

Copy this structure directly. It works for web, network, API, mobile and cloud engagements. 

=====================================================
VULNERABILITY ASSESSMENT AND PENETRATION TESTING REPORT
=====================================================

Client:            [Client legal name]
Engagement:        [Web application / Internal network / API]
Assessment window: [DD Mon YYYY] to [DD Mon YYYY]
Report version:    [1.0]
Report date:       [DD Mon YYYY]
Classification:    CONFIDENTIAL
Prepared by:       [Tester name, credentials]
Reviewed by:       [Reviewer name]

-----------------------------------------------------
1. EXECUTIVE SUMMARY
-----------------------------------------------------

1.1 Purpose and scope in one paragraph, plain language
1.2 Overall risk rating: [Critical / High / Medium / Low]
1.3 Key findings: 3 to 5 bullets in business impact terms
1.4 Recommended immediate actions: 3 bullets, prioritised
1.5 Findings by severity:
    Critical: X
    High: X
    Medium: X
    Low: X
    Info: X

-----------------------------------------------------
2. SCOPE AND METHODOLOGY
-----------------------------------------------------

2.1 In scope
    - [URL / IP range / API base / package name]

2.2 Explicitly out of scope
    - [Assets, DoS testing, social engineering, etc.]

2.3 Testing perspective:
    [Black box / Grey box / White box]

    Credentials provided:
    [roles and privilege levels]

2.4 Methodology followed
    - OWASP WSTG v[x]
    - PTES
    - NIST SP 800-115

2.5 Tools used

2.6 Limitations and constraints
    - [WAF active, rate limits, module unavailable, window]

2.7 Rules of engagement and authorisation reference

-----------------------------------------------------
3. FINDINGS SUMMARY
-----------------------------------------------------

ID      | Title                         | Severity | Asset        | Status
--------|-------------------------------|----------|--------------|--------
VAPT-01 | SQL injection in login        | Critical | /api/v1/auth | Open
VAPT-02 | Broken access control on IDOR | High     | /api/invoice | Open
VAPT-03 | Missing rate limit on OTP     | Medium   | /api/otp     | Open

-----------------------------------------------------
4. DETAILED FINDINGS
-----------------------------------------------------

[Repeat this block for every finding]

FINDING VAPT-01:
[Descriptive title]

Example:
Unauthenticated SQL injection in the login endpoint
allows full database extraction

Severity:        Critical
CVSS v3.1:       9.8
Severity rationale:
[Why this rating, given business context.]

Affected asset:
[Exact URL, endpoint, parameter, host, port]

CWE:             CWE-89
Status:          Open

DESCRIPTION

[2 to 4 sentences describing the vulnerability and why
it exists in this specific application.]

BUSINESS IMPACT

[What an attacker achieves in the client's terms.
Data types exposed, record counts, regulatory consequence,
financial or availability effect.]

STEPS TO REPRODUCE

1. [Exact step, copy-pasteable]
2. [Include full request]
3. [Expected result vs actual result]

EVIDENCE

[Screenshot references, request and response pairs,
extracted data sample with sensitive values redacted.]

REMEDIATION

[Specific remediation for the client's technology stack.]

REFERENCES

[OWASP, CWE, vendor advisory, CVE if applicable]

-----------------------------------------------------
5. REMEDIATION ROADMAP
-----------------------------------------------------

Priority | Finding IDs     | Est. effort | Target
---------|-----------------|-------------|--------
Immediate| VAPT-01         | 2 dev days  | 7 days
Short    | VAPT-02, 03     | 4 dev days  | 30 days
Medium   | VAPT-04 to 07   | 1 sprint    | 90 days

-----------------------------------------------------
6. RETEST RESULTS
-----------------------------------------------------

[Completed after remediation]

ID      | Original | Retest date | Result
--------|----------|-------------|------------------
VAPT-01 | Critical | [date]      | Fixed / Verified
VAPT-02 | High     | [date]      | Partially fixed

-----------------------------------------------------
7. APPENDICES
-----------------------------------------------------

A. Full tool output
B. Complete asset inventory discovered
C. Severity rating methodology
D. Glossary for non-technical readers

=====================================================

Ten mistakes that mark a junior report

  1. Pasting raw scanner output as findings. Untriaged scanner exports with a cover page reduce credibility.
  2. Generic titles. "SQL Injection" tells a manager very little.
  3. Textbook descriptions. Explain where the vulnerability exists and what it does.
  4. Missing business impact. Technical impact without business translation does not get funded.
  5. Unreproducible steps. Developers should be able to follow the steps and reproduce the issue.
  6. Copy-pasted remediation. Give remediation that is specific to the affected technology.
  7. Severity inflation. Everything cannot realistically be high severity.
  8. Unredacted customer data in evidence. Always redact sensitive information.
  9. No limitations section. Clearly document anything that could not be tested.
  10. Writing the executive summary first. Write it last after the testing and findings are complete.

Why this skill decides your career

Exploitation ability is common and getting more common every year. The ability to take a finding and make a non-technical decision maker act on it is rare, and it is what separates a tester who stays at L1 from one who leads engagements.

In hiring, a candidate who can show a well-written redacted report can demonstrate practical security skills beyond a certification list.

Practise this

Write a full report for a lab machine. Not notes, a real report using the template above, complete with executive summary and business impact for a fictional client.

It will take longer than the exploitation did, and that ratio is accurate to the job. Hacklido is free and every challenge there is reportable practice.

The TCVE VAPT program includes graded report submissions, because reading about report writing does not produce report writers.

Frequently asked questions

What should a VAPT report contain?

An executive summary, scope and methodology, a findings summary table, detailed findings with reproduction steps and evidence, remediation guidance, and a retest section.

How long should a VAPT report be?

As long as the findings require, and no longer. A single web application assessment typically runs 25 to 60 pages including appendices. Length is not a quality signal; reproducibility is.

Should I use CVSS for severity?

Use it as a baseline and adjust for business context, stating your reasoning. A pasted CVSS score with no context is the mark of an automated report.

Can I include real customer data as evidence?

No. Redact it. Show enough to prove the finding, such as a record count and masked fields, never live personal data.

Is a retest included in a standard VAPT engagement?

It should be. A finding is not closed until the fix is verified. See VAPT vs penetration testing.

What format should the report be delivered in?

PDF for the formal deliverable, marked confidential. Many clients also want the findings in a spreadsheet or ticket-importable format so engineering can assign them directly.