Pentest Report Template

Document Details

Table of Contents

1. Cover page and document control
2. Distribution and confidentiality
3. Executive summary
4. Scope, targets, and rules of engagement
5. Methodology and standards
6. Severity model
7. Findings summary table
8. Finding detail block (repeat once per finding)
9. Worked example: one finding filled in
10. Compliance control mapping (optional section)
11. Retest and status tracking
12. Appendices
13. Limitations and disclaimer

After the template: using it as a VAPT report, getting it as a PDF, a checklist to run before you send it, and what a template cannot give you.

How to Use This Template

Three readers arrive at a report template, and they use it differently.

• You are writing the report. Work top to bottom. Section 8 is the block you repeat once per finding, and Section 9 shows one of those blocks filled in so the fields stop being abstract. Do the executive summary last, once you know what the findings add up to.
• You received a report and want to judge it. Read Section 8 first, then open the report you were sent and check it field by field. A missing severity, a missing reproduction path, or a finding with no named affected endpoint is the fastest signal that the document came out of a scanner rather than out of a test.
• You need the report as audit or customer evidence. Sections 1, 4, 5, 10, and 11 are the ones an auditor or an enterprise security reviewer reads first: version and date, scope boundary, named methodology, control mapping, and proof that fixes were re-checked.

The structure is deliberately conventional. A report that invents its own shape makes the reader work, and the reader is usually deciding whether to trust you.

1. Cover Page and Document Control

Everything a reader needs to know they are holding the current document.

Why the version number matters: the retest document is a replacement, not an amendment, so it takes a major version bump to v2.0. A reader holding v2.0 should not need v1.0 to act on it.

2. Distribution and Confidentiality

• Named recipients: [Names and roles of everyone authorised to receive this document.]
• Onward sharing: [State whether the client may share the report with auditors, investors, or enterprise customers, and on what terms.]
• Handling: [How the report and its evidence are stored, for how long, and how they are destroyed.]
• Contents warning: This report contains working reproduction steps for unremediated issues. Treat it as sensitive until the findings are closed.

3. Executive Summary

One to two pages, written for a reader with no security background. Write it last.

• What was tested and when: [One sentence naming the systems and the window.]
• Overall outcome in plain words: [What a person deciding whether to launch, sign, or fund should take away.]
• Severity distribution: [Critical N, High N, Medium N, Low N, Informational N. This must equal the findings actually listed later in the document.]
• The three issues that matter most: [Name them, say what an attacker gets from each, and what it would cost the business.]
• Themes rather than a list: [If four findings all come from one missing authorisation check, say so. A theme is fixable; a list is a backlog.]
• What was not covered: [State it here, not only in the appendix. A reader who assumes full coverage will make a wrong decision.]
• Recommended next step and timeline: [What to fix first, and by when.]

Test for this section: hand it to someone who was not on the engagement and who does not work in security. If they can say what the risk is and what happens next, it is written.

4. Scope, Targets, and Rules of Engagement

This section is what an auditor compares against their own boundary, so it has to be exact.

• In scope: [Every hostname, base URL, API endpoint set, mobile package name, cloud account, or IP range tested. Name them individually.]
• Environment: [Production / staging / dedicated test instance, and whether the data was real or synthetic.]
• Roles and access provided: [Anonymous, standard user, admin, tenant A and tenant B. Each role catches a different class of finding, so list which roles were actually exercised.]
• Explicitly out of scope: [Third party services, denial of service and load testing, social engineering, physical access, and anything the client excluded. Say why.]
• Rules of engagement: [Permitted testing hours, source addresses the traffic came from, rate limits observed, escalation contact, and what happens if testing disrupts a service.]
• Authorisation: [Who signed the written authorisation, and when. Authorisation here means the client's own written permission in the engagement contract.]
• Constraints encountered: [WAF in path, credentials issued late, an environment reset mid test. These change what the coverage claim means, so record them.]

If you are writing the plan side of this rather than the report side, the agreed version of these fields belongs in a penetration test plan. A worked plan is published at the penetration test plan example.

5. Methodology and Standards

Name the standard and the version. A framework logo on a cover is not a methodology statement.

• Primary methodology: [OWASP Web Security Testing Guide v4.2 / OWASP Application Security Verification Standard 5.0.0 / OWASP API Security Top 10 2023 / OWASP Mobile Application Security Testing Guide / PTES / NIST SP 800-115.]
• Classification standards used: [OWASP Top 10:2025 for category, CWE for weakness class, CVSS v3.1 and v4.0 for severity.]
• Phases performed: [Reconnaissance, mapping, authentication and session testing, authorisation and tenancy testing, input validation, business logic, configuration, and post exploitation where authorised.]
• Manual versus automated split: [State which findings came from automated tooling and which from manual testing. A reader is entitled to know.]
• Tooling: [Name the tools. Keep the detail in Appendix A.]
• Coverage claim: [What the methodology covered against the scope, in a sentence a reader can check. Avoid claiming coverage the testing window did not allow.]

Our own phase by phase methodology, including where each standard is applied, is published at the Cybersecify methodology page.

6. Severity Model

State the scale before you use it, so no reader has to guess what High means in your document.

• Which version you scored under: [CVSS v3.1, CVSS v4.0, or both. Say so. A score without its version is not reproducible.]
• Publish the vector, not just the number: [The vector string is what lets the client disagree with your score on the merits rather than on faith.]
• Contextual adjustment: [If you raised or lowered a base score for this client's environment, say which findings and why.]

Two notes worth knowing. The severity label on a row has to be the band of the score it was derived from; a row labelled Critical against a 7.2 is the single most common internal contradiction in these documents. And a finding can legitimately change band between CVSS v3.1 and v4.0, so do not promise that it never will.

7. Findings Summary Table

One row per finding, so a reader can triage the whole engagement on one page.

• Sort by severity, not by discovery order. The reader is triaging, not following your day.
• Keep the IDs stable across versions. F-02 in v1.0 must still be F-02 in the retest report, or the remediation conversation loses its thread.
• Make the counts agree. The distribution quoted in the executive summary and the rows in this table are the same set of findings counted twice, and they are the two numbers most likely to disagree after a late edit.

8. Finding Detail Block (repeat once per finding)

This is the part of the report that gets read by the people who have to fix things, and it is the part that distinguishes a test from a scan. Repeat the whole block for every finding.

The two fields most often missing, and the two that matter most: a reproduction path specific to this application, and a business impact statement in this client's terms. A finding without both is an observation, and the client cannot prioritise it.

9. Worked Example: One Finding Filled In

The same block from Section 8, completed, so the fields stop being abstract. The target is fictional and matches the one used in our published sample report.

Notice what the remediation field does: it names the layer, it generalises to the class rather than the instance, and it says explicitly which part is the fix and which part is hardening. That distinction is the difference between a report a team can act on and a report a team argues with.

10. Compliance Control Mapping (optional section)

Include this when the report is going to an auditor, an enterprise customer, or an investor. Skip it when it is not, rather than padding the document.

Mapping happens at two levels: the engagement evidences the controls that require testing to happen at all, and each individual finding maps to the control it affects.

One control to leave alone. ISO/IEC 27001:2022 A.8.25 secure development life cycle is evidenced by process, not by a test report. Claiming a penetration test report evidences it is an overclaim, and an auditor will read it as one.

State who issues what. A testing vendor supplies the testing evidence. An ISO 27001 certificate is issued by a separate accredited certification body, and a SOC 2 report is issued by a licensed CPA firm. Cybersecify is neither, and a report that blurs the two creates an audit question rather than answering one. The filled-in version of both mapping tables, covering all 13 findings, is in Section 6 of our sample penetration test report.

11. Retest and Status Tracking

A report that only records what was broken cannot evidence that anything was fixed. The retest section is what turns the document into audit evidence.

• Reissue as v2.0, not v1.1. The retest report supersedes the original rather than amending it, and the version number should say so.
• Keep the closed findings in the document. Deleting them leaves the reader unable to see that anything was fixed, which is the one thing the retest exists to prove.
• Closed means verified. A status of Closed on the client's assurance rather than on a re-run reproduction is the field an auditor is most likely to challenge.
• Record accepted risk properly. Who accepted it, in what role, and on what date.

For reference on how the two documents relate, the version 1.0 and version 2.0 distinction is explained in more depth in the penetration test report walkthrough.

12. Appendices

• Appendix A, tooling: [Tools and versions used, and what each was used for.]
• Appendix B, full scope inventory: [The complete target list, where Section 4 gave the summary.]
• Appendix C, out of scope and untested: [What was excluded and what the window did not reach. This is the honest half of a coverage claim.]
• Appendix D, evidence index: [Where the raw captures live, how long they are retained, and how they are destroyed.]
• Appendix E, glossary: [CVSS, CWE, IDOR, and anything else a non specialist recipient will meet in the document.]
• Appendix F, contact and escalation: [Who to reach during remediation, and how.]

13. Limitations and Disclaimer

Every honest report states its own limits. Adapt the language to your own terms; the substance below is ordinary industry practice.

• Point in time: [The findings describe the environment as it was during the testing window. Code, configuration, and dependencies change after it.]
• Best effort: [Testing is bounded by the scope, the window, and the access provided. No assessment can establish that an application has no remaining issues.]
• Environment specific: [Findings apply to the environment tested. A staging result is not automatically a production result.]
• Evolving threats: [Recommendations reflect known techniques as at the report date.]
• Ongoing assurance: [Periodic reassessment is what keeps the picture current.]

Cybersecify's own engagement disclaimer, including jurisdiction and the liability position, is published in full on the pentest vendor comparison checklist so a buyer can read our terms before talking to us.

Using This as a VAPT Report Template

VAPT stands for vulnerability assessment and penetration testing. In India and much of Asia it is simply what this document is called, and a buyer asking for a VAPT report sample and a buyer asking for a pentest report sample are asking for the same thing. Nothing in the 13 sections above changes.

Two conventions are worth knowing if you are producing one for an Indian or Asian buyer.

• Some VAPT reports separate the two halves. Vulnerability assessment output, which is largely tool derived and broad, is presented separately from penetration testing findings, which are manually verified and exploited. If you do that, keep one findings summary table covering both and mark the source of each finding, so the reader is not left reconciling two lists. Section 5 of this template is where you state the split.
• Volume is not quality, and the split is where that shows. An unfiltered scanner export dropped in as the vulnerability assessment half is the most common way a VAPT report gets long without getting more useful. Validate before you publish, and say what you validated.

If what you actually wanted was a finished VAPT report to read rather than a structure to fill in, the sample report is a real redacted engagement published in full, and how to read a VAPT report walks a buyer through what to look at first.

Getting This Template as a PDF

Two routes, neither of which asks for an email address.

1. Save or Print as PDF. The button at the top of this page opens your browser's print dialogue with the site navigation, footer, and buttons stripped out, so the PDF contains the document and nothing else. Choose Save as PDF as the destination.
2. Copy Full Template. The copy button puts the whole document on your clipboard, formatting included, ready to paste into your own word processor where you can fill the bracketed fields in place.

If you are looking for a finished penetration test report as a PDF rather than a blank template, that is a different document and it exists: our sample penetration test report is readable in full on the page with no form, and a PDF copy is emailed on request from the form on that page.

Twelve Checks Before the Report Leaves Your Hands

Run these on the finished document. Most of what goes wrong in a report is internal contradiction introduced by a late edit, not a missing section.

1. The version number and date on the cover match the revision history.
2. The severity distribution in the executive summary equals the findings actually listed.
3. Every severity label matches the band of the score it was derived from.
4. Every CVSS score states its version and carries its full vector.
5. Every finding has a named affected component, not a product name.
6. Every finding has numbered reproduction steps a stranger could follow.
7. Every finding has a business impact written in the client's terms.
8. Every finding ID referenced anywhere in the document exists in the findings table.
9. Every remediation names a specific change at a specific layer.
10. Every date in the document is consistent with the report date on the cover.
11. Anything marked closed says how it was verified and on what date.
12. Every sensitive value in the evidence is redacted and marked as redacted.

What a Template Cannot Give You

Worth saying plainly, because the gap between a well structured report and a good one is where buyers get misled.

• Structure is not evidence. A complete set of section headings with generic content underneath reads as thorough and proves nothing. The proof is the reproduction path and the request and response capture.
• A template cannot supply independence. An auditor and an enterprise reviewer both care who tested and whether they were independent of the team that built the system.
• A template cannot make findings real. Scanner output poured into a good structure is still scanner output. The tell is generic titles, boilerplate remediation, no named tester, and a finding count larger than a human would report.
• A template cannot close the loop. Without a retest, the document records what was broken and never records that it was fixed.

If you are on the receiving end of a report and want the buyer side questions rather than the writer side structure, the pentest vendor comparison checklist is the companion document to this one.

Next Step

Three paths from here.

1. Fill the template in. Copy it or Save as PDF using the buttons at the top of the page. It is free to adapt and redistribute.
2. Read the filled-in version, a real redacted engagement report with 13 findings, evidence, control mapping, and a retest section, published in full with no email gate.
3. Book a 30-minute call if you want the report as a deliverable rather than a document to write. Our pentest plans are published: Startup Pentest at INR 74,999 covers 1 scope over 5 business days, Growth Pentest at INR 1,79,999 covers 2 scopes over 10 business days, and both include one free retest reissued as a v2.0 report.