A VAPT report records what was tested, which weaknesses were validated, how they could affect the organisation and what needs to change. A useful report supports both management decisions and engineering work: leadership needs a clear risk summary, while developers need enough detail to reproduce and fix each finding.
Illustrative example only. This is a fictional teaching sample, not a redacted client report, a record of an Aadit engagement or a security certificate. The application, observations and retest below are invented to demonstrate reporting structure. No actual client data or testing results are included.
For the assessment itself, see our VAPT services. For terminology, start with vulnerability assessment and penetration testing explained.
What a complete report should cover
The report begins with scope and authorisation, not a vulnerability count. It should name the systems and environments included, the test window, the access supplied and the agreed rules of engagement. A reader must be able to distinguish an authenticated application test from a perimeter scan or an internal network assessment.
Record exclusions explicitly. If a payment integration, production environment or privileged role was excluded, say so. If access failed or a test could not be completed safely, include the limitation. Otherwise, a buyer may read an absence of findings as evidence that an untested area was secure.
The remaining sections should include:
- An executive summary explaining the important risks, business consequences and remediation priorities.
- A methodology describing automated checks, manual validation and the types of testing performed.
- A findings register with unique identifiers, affected assets and a consistent rating method.
- Detailed findings containing observations, sanitised evidence and recommended corrective actions.
- A remediation tracker with accountable owners and agreed target dates.
- A separate retest record showing which fixes were verified and which remain unresolved.
Fictional report overview
The sample below describes an authenticated test of a fictional customer portal in a non-production environment. It uses synthetic accounts and records. It does not represent a tested product or promise a particular result from an engagement.
| Report field | Illustrative entry |
|---|---|
| Assessment reference | DEMO-VAPT-001 |
| System in scope | Fictional customer portal and its application API |
| Environment | Isolated test environment with synthetic records |
| Access | Two ordinary user accounts in separate fictional customer organisations |
| Activities | Automated discovery, manual authorisation checks and validation within agreed boundaries |
| Exclusions | Production systems, denial-of-service testing and third-party payment services |
| Important limitation | Administrative workflows were not tested because privileged access was not supplied |
| Output | Executive summary, findings, remediation guidance and a separate retest record |
In a real report, the test and report dates, version, authorisation reference and handling classification would also be recorded. Keep sensitive identifiers out of public copies and share the full report only with authorised recipients.
Sample executive summary
In this fictional scenario, a server-side authorisation weakness allowed one synthetic user to view a record belonging to another synthetic customer organisation. The example demonstrates a confidentiality risk at the tenant boundary. No production data was accessed, and no conclusion is made about systems outside the stated scope.
The immediate recommendation is to enforce tenant ownership checks on the server before returning a record. The wider remediation should review related endpoints, add negative authorisation tests and verify that the same design error does not recur elsewhere. A successful retest of this finding would not establish coverage of every endpoint.
An executive summary should separate observed evidence from possible consequences. “A test account could read another tenant's synthetic record” describes an observation. “All customer data has been stolen” would be an unsupported claim.
Sample detailed finding
DEMO-01: Missing tenant-level authorisation
Affected asset: The fictional portal's record-viewing API.
Observation: In the isolated example, a request made using customer A's authenticated account returned a synthetic record assigned to customer B. Authentication succeeded, but the application did not enforce ownership of the requested record.
Evidence: A real report would attach a sanitised request and response, identify the two test roles and show the expected versus observed result. Remove tokens, cookies, personal data and unnecessary secrets from shared copies. This educational page does not contain live requests or an exploit against a real service.
Risk reasoning: Cross-tenant access can expose confidential information. Prioritisation depends on reachable records, access prerequisites, data sensitivity and existing controls. No numerical CVSS score is assigned here because there is no real technical assessment to support one. A real score should include its version, vector and assumptions, alongside business context.
Remediation: Enforce ownership and permission checks in the server-side data access path. Do not rely on a hidden user-interface control or an identifier that is difficult to guess. Add automated tests that attempt access across tenant boundaries, and review equivalent endpoints for the same weakness.
Acceptance criterion: Customer A must not receive customer B's record, including through alternative supported request paths. The application should handle the rejected access consistently without exposing sensitive details.
Sample remediation and retest register
The following rows describe a fictional sequence, not work performed for a customer.
| Record | Status | Meaning |
|---|---|---|
| Initial finding | Open | The issue was reproduced in the illustrative test scenario |
| Engineering update | Fix submitted | A code change was reported; verification was still pending |
| Retest result | Verified closed for the tested path | The original cross-tenant access was no longer reproducible under the same example conditions |
| Residual limitation | Additional endpoints not assessed | Closure of one finding does not imply that untested paths are secure |
In an actual engagement, the retest record should include dates, environment, report version and supporting evidence. If the tester cannot access the changed system, use “not retested” rather than “closed”. If only part of the issue was corrected, describe the remaining behaviour.
How to assess a report before accepting it
Check whether the scope matches your purchase order and the systems your customer or auditor expects to see. Ask which authenticated roles were covered, which manual checks were performed and how false positives were validated. Findings should be actionable without requiring developers to guess what the tester meant.
Review the rating method, not just the number of critical issues. A report with no critical findings may still describe important business risks. Conversely, a scanner's severe rating may need contextual explanation before it determines remediation priority.
Agree report handling and retest terms before commissioning work. Full technical reports may contain sensitive architecture and exploit evidence, so restrict access and use a sanitised summary where appropriate. For audit planning, connect the report to your ISO 27001 programme or SOC 2 readiness work; a test does not by itself confer certification.
Frequently asked questions
What should a VAPT report contain?
A VAPT report should define the authorised scope, testing dates, methods and limitations, then present validated findings with affected assets, risk reasoning, evidence and remediation guidance. It should include an executive summary and distinguish the original findings from subsequent retest results. A scanner export alone does not show the full testing process.
Is this a real client VAPT report?
No. This page contains an illustrative, fictional example created to explain report structure. It is not a redacted client report, proof of an engagement or a certificate. No client data or actual testing results are shown.
How is a vulnerability scan different from a VAPT report?
A vulnerability scan lists potential weaknesses found by automated checks. A VAPT report should explain which issues were validated, what manual testing covered, the observed impact and the limits of the assessment. Automated results can contribute to the report, but they do not replace contextual analysis or evidence of penetration testing.
What does a retest show?
A retest checks whether a previously reported issue can still be reproduced after remediation. The report should record what was retested, when, under which conditions and with what result. A closed finding is not a guarantee that the entire application is secure, and an untested fix should not be labelled verified.
Sources and next steps
NIST SP 800-115 describes technical security assessment planning, execution and reporting. FIRST's CVSS documentation explains vulnerability scoring; scoring should not be presented as a substitute for business risk assessment.
Contact Aadit to discuss your assessment scope, reporting requirements and retest arrangements. This page is available to read without submitting personal details; no client-report download is claimed.