What belongs in it
| Section | What it must show | Who reads it |
|---|---|---|
| Executive summary | Risk posture in plain language, no jargon | Leadership, the budget holder |
| Scope and methodology | Exactly what was tested, what was not, and how | Auditors — this is the first thing they check |
| Findings | Severity, description, evidence, reproduction steps | Engineers |
| Evidence per finding | Proof of exploitation, not just detection | Everyone — this separates real from scan |
| Remediation guidance | Specific to your stack, not generic advice | Engineers |
| Priority order | What to fix first and why | Engineering leadership |
| Retest results | Verification that findings were closed | Auditors, enterprise customers |
Scope and methodology is where auditors start. A report that does not state precisely what was in scope cannot demonstrate that the thing your auditor cares about was actually tested — and a clean report on the wrong scope answers nobody's question.
Telling a real report from tool output
Reformatted scanner output is common and recognisable. What gives it away:
Findings that read identically to public CVE descriptions. Generic text with your hostname substituted in.
No exploitation evidence. Detection is "this version has a known issue". Exploitation is "here is the request, here is the response, here is the data it returned".
No business logic findings at all. A real manual test of an application with multiple user roles almost always surfaces something about authorisation. A report with only technical findings and nothing about how the application actually works was probably not driven by a human.
Severity that does not account for your context. Tools rate in the abstract. A tester rates against what the finding actually reaches in your environment.
No methodology section, or one that names no standard. An OWASP-aligned engagement says so.
Suspiciously fast delivery. A report two days after kickoff on a multi-role application did not involve a week of manual testing.
The retest letter
The most important artifact in the whole engagement, and the one most often missing.
The report describes the state at the time of testing. You remediate everything. You send the report to your auditor or your enterprise customer — and it still lists every finding as open, because that is what it recorded on the day.
What closes them is a retest letter: a short document from the testing provider confirming each finding was re-examined and verified as remediated, with a date.
Without it you have documentary evidence that you had vulnerabilities and nothing showing you fixed them — which is a worse position than not having tested, because now it is written down.
Confirm retest is in scope before the engagement starts. Negotiating it once findings exist is the worst possible leverage position, and a provider who priced without it priced a different job.
What auditors and customers actually check
Date. Reports older than twelve months are routinely rejected in enterprise security reviews and by most compliance frameworks.
Scope. Does it cover the product or environment being asked about? This is the most common rejection reason after age.
Methodology. Manual or automated, and against what standard.
Findings status. Open or closed — the retest letter question.
Who tested. For a compliance-grade report, the tester's credentials and independence matter to whoever reviews it.
See VAPT for ISO 27001 and SOC 2 for what each framework expects specifically.
Sharing the report
Full penetration testing reports contain a working map of how to attack you. Treat distribution accordingly.
Most organizations share a summary letter with customers — scope, methodology, dates, a statement that findings were remediated and retested — and reserve the full technical report for their own engineers and, under NDA, for auditors who require it.
Ask your provider for both formats. A provider who only produces the full technical report has left you choosing between oversharing and having nothing to send.
FAQs
What should a VAPT report contain?
An executive summary in plain language, a precise scope and methodology statement, findings with severity and reproduction steps, evidence of exploitation rather than just detection, remediation guidance specific to your stack, a priority order, and retest results verifying findings were closed.
How do I tell a real pentest report from a scanner output?
Look for exploitation evidence rather than detection alone, findings about business logic and authorisation rather than only technical CVEs, severity ratings that account for your environment, a named methodology such as OWASP, and a delivery timeline consistent with genuine manual testing.
What is a retest letter and why does it matter?
A short document from the testing provider confirming each finding was re-examined and verified as remediated, with a date. It matters because the original report records the state at testing time and shows every finding open — without a retest letter you have written evidence that you had vulnerabilities and nothing showing you fixed them.
How old can a penetration testing report be?
Most enterprise security reviews and compliance frameworks reject reports older than twelve months. Annual testing is the practical baseline, with additional testing after any significant change to the application, infrastructure or authentication model.
Should I share the full pentest report with customers?
Generally no. A full report is a working map of how to attack you. Most organizations share a summary letter covering scope, methodology, dates and remediation status, and reserve the full technical report for internal engineers and, under NDA, auditors who specifically require it.
Where to go next
See penetration testing services, what auditors expect, or what testing costs.