Penetration Testing Report Template: What a Good Report Contains

Most buyers only see one penetration test report a year, so it is hard to know whether the document in front of you is thorough or padded. This guide sets out what each section of a good report contains, shows a sanitized fictional finding at the level of detail you should expect, and explains how to read a report as the person paying for it. It applies to any tester, including our own penetration testing service.

Downloads (original NetSys templates, no registration):

• Download the penetration testing report template (Word, .docx): a report shell with every section below, placeholder text and one fictional sample finding.
• Download the findings and retest tracker (Excel, .xlsx): one row per finding with owner, due date, retest result and a summary by severity.

Both files are published by NetSys for anyone to adapt. They describe no real business and no real test.

What should a penetration testing report contain?

A penetration test report is the written result of an authorized attempt to break into agreed systems. It should let three different readers do their jobs: an owner deciding what to fund, an administrator fixing the problems, and a later reader (an auditor, insurer or customer) judging what was and was not tested. The sections below serve those readers in that order.

Why do scope and rules of engagement come first?

Rules of engagement are the written limits on what, when and how the tester may test. The report should reproduce them, because every other section is only meaningful inside them. A report that lists ten findings against a scope of three public addresses says something very different from one that lists ten findings across an internal network with supplied credentials. Check that the scope in the report matches the scope you signed, that the testing window is stated, and that exclusions (production databases, denial of service, physical access) are written down rather than assumed.

What makes an executive summary useful?

One page, written for the person who approves spending. It names what was tested and from where, says in business terms what an attacker could have reached (customer records, email, payroll, backups), lists the few findings that matter most and the effort to fix them, and states what was not tested. It should contain no tool names and no scores without a sentence explaining them. If you cannot read the summary in ten minutes and know what to do on Monday, ask for it to be rewritten.

How should methodology be described?

Methodology is the sequence of work the tester followed: reconnaissance, enumeration, vulnerability identification, exploitation, post-exploitation and reporting. A good report says what was done in each phase and, since much testing is now automated or AI-assisted, which steps a person performed or verified. Public references give you a yardstick: NIST SP 800-115 describes vulnerability scanning as identifying weaknesses and penetration testing as validating them, and the OWASP Web Security Testing Guide is the usual method for applications (both NIST SP 800-115 and the OWASP guide checked on November 7, 2026). A report that only lists tool names has described inputs, not a method.

How should severity be rated and explained?

Severity is a rating of how bad a finding is. The report must say which method it used and apply it consistently. There are two acceptable approaches:

1. CVSS with the published bands. The Common Vulnerability Scoring System gives a 0 to 10 technical score. In the CVSS v4.0 specification, FIRST maps scores to qualitative ratings: None 0.0, Low 0.1 to 3.9, Medium 4.0 to 6.9, High 7.0 to 8.9, Critical 9.0 to 10.0 (FIRST CVSS v4.0 specification, checked on November 7, 2026).
2. A labeled qualitative scale. Critical, High, Medium, Low and Informational, with each label defined in the report. This is acceptable as long as the definitions appear and are used the same way for every finding.

Either way, each finding should carry a sentence of rationale: the business context that moved the rating up or down, such as internet exposure, the data involved or a compensating control. A score with no rationale is a number, not an assessment.

What does a well-written finding look like?

The example below is fictional. It describes no client and no real system; the domain is reserved for documentation. It is included in the Word template so your tester, or your team, can see the expected depth.

Notice what the finding is not: it is not a scanner line that says a port is open. It names the condition, proves it, explains why it matters to this business and tells someone exactly what to do.

What belongs in evidence and appendices?

Evidence is the artifact that proves each finding: screenshots, request and response pairs, log excerpts, with an ID that the finding references. The appendices hold the asset inventory actually tested, the tools and versions used, the evidence index and a glossary. These sections are what let a second firm, an auditor or your own engineer confirm the finding and later confirm the fix. If a report has no evidence index, ask where the evidence is and how long the tester keeps it.

How should retesting be tracked?

A retest is a repeat of the relevant steps after you report a fix, producing new evidence. The report, or a retest edition of it, should record for each finding the date the fix was reported, the retest date, the result and the evidence ID. Our Excel tracker holds the working copy: enter each finding, assign an owner and due date, and update it as fixes land. A finding is closed when the retest says Fixed, or when a named approver records that the business accepted the risk, with a review date. Count totals on the Summary sheet are a tracking aid; they do not measure risk.

How do you read a penetration test report as a buyer?

1. Match the scope to what you signed. If assets you authorized are missing, ask why. If assets you did not authorize appear, ask harder.
2. Find the severity method. If it is absent, the ratings are opinions.
3. Read two findings in full. Each should have evidence, reproduction steps and a specific fix. If they read like scanner output, the test was mostly a scan. Our comparison of penetration testing and vulnerability scanning explains the difference.
4. Read the limitations. A clean section does not mean a system is secure; it means nothing was confirmed under that method, access and time.
5. Check the retest terms. Window, coverage and evidence. Retest terms affect what you pay, as our guide to penetration testing cost explains.
6. Ask who verified AI-assisted findings. Automated and AI tools can report flaws that are not there. The report should say that a person confirmed each finding. Our overview of penetration testing tools covers what each type of tool does.

What a template does not do

A template is a container. It is not evidence that a penetration test took place, and a filled-in copy proves nothing on its own. Evidence is the testing firm's signed report together with the artifacts behind each finding and the authorization that preceded the work. Do not present a template, or a self-completed report, to an auditor, insurer or customer as a test result. If you need the step beyond a penetration test, our red team vs penetration testing comparison explains what a red team engagement adds.

How NetSys reports a penetration test

Our free Tier 1 external test and quoted Tier 2 source code test both end with a report in this structure: the agreed scope, a plain-English executive summary, a stated severity method, findings with evidence and the specific fix, and a retest after you patch for Tier 2. Testing is AI-driven and an engineer verifies every finding before it is reported. Request the free external test on our penetration testing page.

Frequently asked questions

What is a penetration testing report?

It is the document a tester delivers after an authorized attempt to break into agreed systems. It records what was in scope, how the test was done, each confirmed weakness with evidence and a fix, how severe each one is and why, and what was not tested. It is the product you are paying for; the testing itself is how the product is made.

Is there a standard penetration test report format?

No single mandated format exists, but good reports share the same sections: scope and rules of engagement, executive summary, methodology, severity method, findings with evidence, remediation, retest tracking and appendices. Public references such as NIST SP 800-115 and the OWASP testing guide describe method, and compliance programs such as PCI DSS set requirements for what testing must cover, which the report should show it met.

Should the report use CVSS scores?

It is a reasonable choice, and the published CVSS v4.0 bands make ratings comparable between firms. A defined qualitative scale is also acceptable. What is not acceptable is a severity label with no method and no rationale. Whichever scale is used, the finding should explain the business context that moved the rating.

Can we write our own penetration test report from this template?

You can use the template to record the results of testing your own team performs, and the tracker to manage fixes from any report. What you cannot do is treat a self-completed template as independent evidence. Auditors, insurers and customers who ask for a penetration test expect a report from the party that did the testing, with the evidence behind it.

How long should a penetration test report be?

As long as the findings need and no longer. A one-page executive summary, a few pages of scope and method, one to two pages per finding, and appendices. A 200-page report that is mostly scanner output is a sign that the testing was mostly a scan.

What should we do with the report after the retest?

Keep the final edition, the retest evidence and the authorization together, because an auditor, insurer or customer may ask for them later. Carry any accepted risks into your risk register with an owner and a review date, and schedule the next test for the agreed interval or after the next major change.

Scope a test with a report you can act on

Bring your public domains, the applications you run or build and any compliance driver to a short scoping call, or request the free external test on the penetration testing page. You will know in advance exactly what the report will contain.

Sources and further reading

• NIST SP 800-115, Technical Guide to Information Security Testing and Assessment: vulnerability scanning and penetration testing as distinct activities, and reporting guidance. Checked on November 7, 2026.
• FIRST, CVSS v4.0 Specification Document: the qualitative severity rating scale (None, Low, Medium, High, Critical). Checked on November 7, 2026.
• OWASP Web Security Testing Guide: the method most application testers work from. Checked on November 7, 2026.