VAPT Report: Format, Sample and Template

8

core sections in a standard VAPT report

0.0 to 10.0

CVSS severity scale, from None to Critical

5 days

for CERT-In empanelled auditors to share audit data with CERT-In

A VAPT report is the only part of an engagement most people ever read. The board reads two pages of it, developers read the findings, and an auditor checks the scope, dates and signatures. This guide shows what each of those readers needs and the order a good report puts it in.

Why most VAPT reports go unread

Plenty of reports fail the people who paid for them. The common version is a scanner export with a logo on the front: four hundred rows, most marked Critical or High, none of them validated, and no hint of which three matter this week. Developers stop reading after page ten. The board never gets past the cover.

The other failure is quieter. The testing was good, but the report leaves out the asset list, the test dates or the reviewer's signature, and the auditor sends it back. Both are format problems, which means a sound template fixes most of them.

• Scanner output pasted in as findings: hundreds of rows with no validation and no proof of exploitation
• No business context: a 9.8 on a test server outranks a 6.5 on the payments API
• Steps nobody can reproduce: the developer cannot trigger the issue, so it stays open
• Missing audit basics: no asset list, test window, version history or sign-off
• No retest evidence: months later, nobody can show which findings actually closed

What is a VAPT report?

A VAPT report is the formal output of a vulnerability assessment and penetration testing engagement. It documents the scope that was agreed, the methods used, every validated finding with its severity and evidence, and the fixes the tester recommends. For background on the engagement itself, start with what VAPT is and come back here for the deliverable.

A report is not a certificate. Some providers also issue a one-page certificate or attestation letter that summarises the result for third parties, and that document points back to the report rather than replacing it. VAPT certification covers what a credible certificate must contain.

VAPT report format: the sections, in order

Published standards agree on the overall shape. The OWASP Web Security Testing Guide suggests an introduction (version control, team, scope, limitations, timeline and disclaimer), an executive summary, a findings summary, detailed findings and appendices. PTES splits the same material into an executive summary for leadership and a technical report for engineers. Merged, that gives eight sections.

Standard VAPT report structure

Writing the executive summary

Write it last, keep it to one or two pages and use business language: the goal of the test, the overall risk rating, counts by severity and the three issues that matter most. PTES makes a useful distinction between systemic and symptomatic issues: one server missing a patch is a symptom, while the lack of an effective patch management process is the systemic problem a board can actually fund.

Scope and limitations

List every asset tested (URLs, IP ranges, application builds, mobile app versions, cloud accounts), plus the test window, the environment, the accounts or roles used, and anything excluded. The limitations paragraph matters as much as the scope. If a host was offline or the window was cut short, say so, because readers will otherwise assume full coverage.

Sample VAPT report finding

Detailed findings are the core of the report and the place most templates are weakest. Below is an illustrative finding in the format we recommend. It is made up, not taken from a client engagement, but every field is one a developer or auditor will look for.

Sample finding write-up (illustrative)

How findings are rated: CVSS, EPSS and CWE

CVSS gives each finding a severity score from 0.0 to 10.0. The current version, CVSS v4.0, was published by FIRST in November 2023 and groups its metrics into Base, Threat, Environmental and Supplemental. Many reports still use v3.1. Either is acceptable as long as the report states the version and includes the full vector string, so anyone can recalculate the score.

EPSS answers a different question: how likely a published CVE is to be exploited in the wild in the next 30 days. It only exists for findings that map to a CVE, which is why the sample marks it as not applicable. CWE names the type of weakness, which helps developers hunt for the same bug class elsewhere in the code.

Scores are a starting point, not the final priority. The sample is a 6.5 on paper, but it exposes customer data on a production system, so it belongs near the top of the fix list. The CVSS severity bands are:

• Critical: 9.0 to 10.0
• High: 7.0 to 8.9
• Medium: 4.0 to 6.9
• Low: 0.1 to 3.9
• None: 0.0

What CERT-In expects in a VAPT audit report

If the engagement is a CERT-In empanelled audit, the report has to meet the Comprehensive Cyber Security Audit Policy Guidelines that CERT-In issued on 25 July 2025. They apply to empanelled auditing organisations and the auditee entities they test, and they are specific about what the report must hold.

• Format agreed up front: the auditee and the auditor agree the report format before the audit starts
• Full scope on record: every asset in scope is named, along with duration, methodology, tools, manual process, sampling decisions, exemptions and limitations
• Versions and artefacts: draft and final versions carry their issue dates, and hash values, versions and timestamps of the audited assets appear in the report
• CVSS, EPSS, CWE and CVE: findings are rated with CVSS for severity, supplemented with EPSS for likelihood of exploitation, and mapped to CWE and CVE numbers
• No surprises at the end: critical and high findings are notified to the auditee as they are found
• Closure built in: the report sets closure timelines by severity, the final report follows a follow-up audit, and a staging-only audit must state that production was not tested
• Three sign-offs: the auditors who did the work, an independent mid-management reviewer, and the head of the auditing organisation

Using these rules outside CERT-In audits

Not every VAPT is a CERT-In audit, but the list is a good quality bar for any report. Ask providers for a redacted sample report and check it against these points. Our guide to choosing a penetration testing company covers the rest of that evaluation. The guidelines also require empanelled auditors to share audit information with CERT-In within five days of completing an audit, so expect that clause in the engagement letter.

VAPT report template you can copy

Use this outline as the skeleton of your next report. Each line is a heading followed by what belongs under it. Keep the numbering, because findings, evidence and retest results all cross-reference it.

• 1. Document control: client, report title, version, draft and final issue dates, classification, distribution list
• 2. Executive summary: engagement goal, overall risk rating, counts by severity, top three risks in business terms, key recommendations, one to two pages
• 3. Scope: each asset with its URL, IP range or build number, the test window, environment, accounts or roles used, and exclusions
• 4. Methodology: standards followed, test type (black, grey or white box), tools, what was manual and what was automated, limitations
• 5. Findings summary table: ID, title, severity, CVSS score, affected asset, status
• 6. Detailed findings: one block per finding using the fields in the sample above
• 7. Remediation and retest: fix-by date per severity, owner, retest date and result for each finding
• 8. Appendices: rating scale definitions, tool output, evidence index, tester and reviewer sign-off

Common VAPT report mistakes

Check every draft against this list before it goes out.

• A score without a vector: a bare 7.5 cannot be checked or recalculated
• Unvalidated scanner findings: one obvious false positive and developers stop trusting the rest
• Real data in the evidence: unmasked passwords, tokens or customer records turn the report itself into a leak
• Generic remediation: 'apply vendor patches' is not a fix; name the version, setting or code change
• No limitations section: silence implies full coverage that never happened
• Sent as a plain email attachment: share reports encrypted or password-protected, to named contacts only

Retests and closure reports

The first report opens the work; it does not close it. Once fixes are deployed, the tester re-checks each reported finding and issues a retest or delta report showing what closed, what is still open and what was accepted as a risk. CERT-In's guidelines call the end state a closure report: confirmation that every observation has been addressed or closed.

Without that second document, the original report goes stale on the day it is delivered. With it, an auditor can trace each finding from discovery to verified fix. Remediation and retesting shows how that loop runs in practice.

Infronest keeps automated, manual and imported findings in one engagement and exports them as a single HTML or PDF report, with retests tracked through to a delta report. It is a platform for running and reporting VAPT, not a certified manual penetration test.

Conclusion

The hard part of reporting is rarely the writing. It is keeping findings, evidence and retest status together across weeks of testing. In Infronest's Security and VAPT module, findings from automated scans, the HTTP Lab and imported Burp XML, SARIF or JSON results sit in one tenant-isolated engagement, and the report is generated from that record.

Scoped security assessments start at ₹36,750 per application per year, or ₹42,000 one-time. Where an audit calls for certified manual validation and a signed attestation, that is a separate consulting engagement rather than something the software produces on its own.

Walk through a sample engagement report and scope your own assessment with our team.

Sources

The report structure and rating guidance above draw on these published standards and guidelines.

• CERT-In: Comprehensive Cyber Security Audit Policy Guidelines, v1.0, 25 July 2025
• OWASP Web Security Testing Guide: Reporting Structure
• Penetration Testing Execution Standard (PTES): Reporting
• FIRST: CVSS v4.0 Specification Document
• FIRST: Exploit Prediction Scoring System (EPSS)
• MITRE CWE-639: Authorization Bypass Through User-Controlled Key
• NIST SP 800-115: Technical Guide to Information Security Testing and Assessment

💡 Written by the Infronest Security Research Team. The report structure follows the OWASP Web Security Testing Guide reporting chapter, the PTES reporting standard and CERT-In's Comprehensive Cyber Security Audit Policy Guidelines (July 2025). The sample finding is illustrative and does not come from a client engagement.