What Does a VAPT Report Look Like? Format Explained

Three Audiences Every VAPT Report Must Serve

A VAPT report is unusual in that it is consumed by three very different audiences, usually all from the same single document. The CISO and the board want a one-page risk story in business language. The auditor (ISO 27001, SOC 2, PCI DSS, RBI, DPDP) wants control-mapped evidence and a clean status per finding. The engineering team wants the exact request, the exact payload, the exact line of code or configuration, and the exact remediation step.

A weak VAPT report serves one audience well and the other two poorly. A strong report uses layered structure (executive summary, then findings catalogue, then per-finding detail) so each reader can stop at the depth they need without the document feeling padded for either group.

Standard Section Structure of a VAPT Report

Our reports follow a consistent structure across every engagement type. The structure is below, with the typical page count in parentheses for a mid-sized engagement (15 to 30 findings).

• 1. Executive Summary (2 to 4 pages): scope, methodology summary, overall posture, key risks, board-level recommendations
• 2. Engagement Details (1 to 2 pages): scope tables, in-scope and out-of-scope, testing window, named consultants, contact lines
• 3. Methodology (2 to 3 pages): framework references (OWASP Top 10, OWASP API Top 10, MITRE ATT&CK, PTES, OSSTMM, NIST SP 800-115), tools used, ethical boundaries
• 4. Risk Summary (2 pages): findings count by severity, by category, by component, by compliance impact
• 5. Compliance Mapping (2 to 4 pages): per-control mapping to ISO 27001 Annex A, SOC 2 TSC, PCI DSS, RBI, DPDP Section 8
• 6. Detailed Findings (1 to 3 pages per finding): every finding with full PoC, evidence, CVSS, remediation
• 7. Re-Test Plan and Closure (1 page): re-test scope, timeline, closure criteria, free re-test policy
• 8. Appendices: raw tooling output, scan exports, network diagrams, account inventory, asset list

Executive Summary: The First Two Pages That Get Read

Most senior readers stop here. The executive summary needs to answer four questions clearly: what was tested, how it was tested, what was found, and what to do next. We write in plain business English, no jargon, no acronyms without expansion on first use.

We include a one-line posture statement (for example: 'Web application external posture is satisfactory; internal Active Directory posture has three critical findings requiring immediate remediation; one finding qualifies for DPDP breach-notification consideration if exploited.'), a severity-counts table with deltas vs the previous engagement if applicable, the top three risks expressed as business outcomes (not technical vulnerabilities), and a single clear recommendation for the next 30 / 90 / 180 days.

What we do not include: jargon, vendor logos, marketing about the testing methodology, or padding that hides poor signal. A good executive summary should be screenshot-able for board reading on a phone.

Per-Finding Format: What Each Issue Looks Like

Every finding in the catalogue follows the same template, so the engineering team and the auditor know exactly where to look for each piece of information.

Finding Header

Title (descriptive, not generic), severity (Critical / High / Medium / Low / Informational), CVSS v3.1 vector and computed score, CWE reference, affected component(s), exploitability and impact summary in one paragraph each, suggested remediation effort (S / M / L).

Proof of Concept

Reproducible PoC with exact request and response, screenshots, video where helpful, redacted only where genuinely necessary for safety. A finding without reproducible PoC is a finding that engineering will challenge and the auditor will discount. Codesecure includes the raw HTTP exchange, command-line history, decoded protocol data, or memory dump excerpt as appropriate.

Risk and Impact

Business impact in plain language (customer data exposure, regulator notification trigger, fraud potential, service availability), technical impact (what an attacker can do post-exploit), and the realistic likelihood given the environment. We use CVSS environmental modifiers, not just base score, so the number reflects the customer's actual environment.

Remediation

Concrete steps the engineering team can act on. Not 'enable WAF' but 'enable AWS WAF managed rule group AWSManagedRulesCommonRuleSet on the listener for app-prod-alb in account 123456789012'. Where multiple remediation paths exist (quick fix versus structural), both are documented.

CVSS Scoring: Base, Temporal and Environmental

CVSS v3.1 is the universal scoring standard. Base score reflects the vulnerability itself (attack vector, attack complexity, privileges required, user interaction, scope, confidentiality, integrity, availability). Temporal modifies for exploit code maturity, remediation level and report confidence. Environmental modifies for the specific deployment context (security requirements, modified base metrics).

Reports that quote only base score are common and incomplete. A SQL injection that scores 9.8 base might be a 6.5 environmental in a tenant with no PII in scope, or a 9.8 environmental in a tenant with full customer KYC. We compute and explain both, and we publish the vector string so the reader can verify or recompute. CVSS v4.0 is emerging and we will incorporate it in 2026 engagements as customer auditors adopt it.

Compliance Mapping: ISO, SOC 2, PCI, RBI, DPDP

Indian customers typically need their pentest report to evidence several compliance frameworks at once. Our reports include a separate mapping section that lists each finding against the relevant controls:

ISO/IEC 27001:2022 Annex A (especially A.5, A.8 control families), SOC 2 Trust Services Criteria (CC6 logical access, CC7 system operations, CC8 change management), PCI DSS 4.0 where cardholder data is in scope (Requirements 6, 11), RBI Cyber Security Framework for regulated banks and NBFCs, DPDP Act 2023 Section 8 reasonable security safeguards, OWASP ASVS levels for application-tier engagements, and where relevant NIST CSF and CIS Controls v8.

Each control mapping carries the finding number so the auditor can drill from the control library back to the evidence.

Re-Test and Closure

A pentest without re-test is a half-finished engagement. Codesecure includes free re-test within 90 days of report delivery. Customers remediate, mark the findings as ready for re-test, and we re-validate only the fixed items, then issue a closure addendum to the original report.

The closure addendum is what auditors and customer-security teams typically want to see. It looks like: original finding, original severity, remediation summary by the customer team, retest result (Closed / Open / Partially Closed / Risk Accepted), and updated overall posture statement. This makes the next ISO surveillance audit or SOC 2 readiness review materially easier.