Pentest Report Template: What Goes in a Penetration Testing Report

The short answer

A pentest report template is the fixed outline a tester fills in after an engagement: cover page and document control, executive summary, scope and rules of engagement, methodology, findings summary, detailed findings, remediation roadmap and appendices. Every finding inside it uses the same fields, from the title and CVSS score to the evidence, the steps to reproduce and the fix.

The outline is the easy part. A good penetration testing report gives executives the risk in plain language and engineers findings they can reproduce and fix. Free tools such as SysReptor, PwnDoc and Dradis Community Edition will build the document for you, and nearly 400 published reports from security firms are free to read on GitHub.

This page covers client and practice reports in general. The OSCP^® exam report has its own rules and an official OffSec template, and our OSCP report template guide covers both. We're Hacker Blueprint, an independent prep site with no ties to OffSec. Our instructor holds the OSCP, our academy has more than 600 students, and around 7,000 people have claimed our prep materials.

What a penetration testing report is for and who reads it

The report is what the client keeps. It's how they decide what to fix first and how they show a board, a customer or an auditor that the testing happened. A finding that isn't in the report was, for the client, never found.

NIST's guide to security testing, SP 800-115, puts it simply: "Because a report may have multiple audiences, multiple report formats may be required." In practice that means three kinds of reader:

• Executives and managers read the executive summary to learn how exposed the organization is and what fixing it will take.
• Engineers and system owners read the findings for their systems and need enough detail to reproduce and fix each one.
• Auditors read the document control, scope and methodology to check what was tested, when, by whom, and whether findings were retested.

The sections of a pentest report

Most pentest report templates use some version of these eight sections. Names vary between firms, and a short web application test might merge a few, but you'll find the same content in report after report.

Document control looks like paperwork, but a version table (draft, reviewed, final, retest) and a distribution list are what make the report usable months later. Mark it confidential, since it describes how to break into the client's network.

Scope and rules of engagement should match the signed agreement. If a host in scope was offline or a test was cut short, say so. A limitation you write down protects you, and one the client discovers later doesn't.

Methodology says how you tested. NIST SP 800-115 describes four phases of penetration testing (planning, discovery, attack and reporting), a sensible outline when the client doesn't ask for another. Give each finding a stable ID like F-01 so tickets and the retest can refer to it, and keep cleanup notes (accounts or files you created and removed) in the appendices.

How to write a finding

Findings are the body of the report, and consistency matters more than style. When every finding has the same fields in the same order, an engineer who has read one can scan the rest. These are the fields most templates use:

• Title. The weakness, where it is, and what it allows. "SMB signing not required on internal file servers" tells the reader far more than "SMB misconfiguration".
• Severity. A rating, the CVSS score with its version, and the full vector string.
• Affected assets. Every host, URL, parameter or account, in an appendix if the list runs long.
• Description. What the weakness is, in a few sentences a developer outside security would follow.
• Impact. What an attacker could do with it in this environment. This is where business context goes.
• Evidence. Screenshots, requests and responses, or tool output, each with a timestamp and the IP you tested from. Redact passwords, tokens and personal data.
• Steps to reproduce. Numbered steps an engineer can follow to confirm the issue now and the fix later.
• Remediation. The specific fix, a workaround if the fix will take time, and the root cause when there is one.
• References. Vendor advisories, CVE and CWE IDs, and documentation for the fix.

Many templates add a status field (open, fixed, risk accepted) so the same document can carry retest results. Here's the skeleton as plain Markdown:

### F-01: Weakness, where it is, what it allows

**Severity:** High, CVSS v4.0 score and full vector
**Affected assets:** hosts, URLs, parameters or accounts
**Status:** Open

**Description:** what the weakness is, in plain terms.

**Impact:** what an attacker could do with it here.

**Evidence:** screenshots and output, with timestamps and source IP.

**Steps to reproduce:**
1. Tool and target used to confirm the issue
2. The result that shows it
3. How to confirm the fix

**Remediation:** the fix, a workaround and the root cause.

**References:** vendor advisory, CVE, CWE.

A worked example finding

Here's one finding written out in full. It's a common internal network issue, and it's safe to describe because the fix is a policy setting. The hosts, dates and IP addresses are made up for this page.

F-04: SMB signing not required on internal file servers

Severity: Medium. CVSS v3.1 base score 5.3 (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N). Business risk rated High, see Impact.

Affected assets: FS01, FS02 and APP01 on the server VLAN (10.20.0.0/24).

Description: The affected servers accept SMB connections without requiring message signing. Signing lets the receiver detect a message that was changed in transit and confirm who sent it. Windows signs a session only when the client or the server requires it, so clients that don't require it get unsigned sessions with these servers.

Impact: An attacker on the internal network who captures another account's authentication could relay it to these servers and act as that account without learning its password. Microsoft lists relay and spoofing as the attacks signing helps protect against. FS01 holds the finance and HR shares, so the business risk is rated above the base score.

Evidence: On October 14, 2026 at 10:12 UTC, from the tester's laptop at 10.20.5.23, Nmap's smb2-security-mode script reported "Message signing enabled but not required" for all three hosts (Figure 4.1, raw output in Appendix B).

Steps to reproduce:

1. From any host on the internal network, check each server's SMB security mode with an SMB scanner, such as Nmap's smb2-security-mode script.
2. Confirm the result reports that message signing is enabled but not required.
3. After the fix, repeat step 1. The result should report that signing is required.

Remediation: Enable the Group Policy setting "Microsoft network server: Digitally sign communications (always)" on the affected servers, and "Microsoft network client: Digitally sign communications (always)" on domain workstations. Microsoft notes that environments with non-Microsoft file servers may need different settings, so test any storage appliances first. From Windows 11, version 24H2, you can also audit SMB peers that don't support signing before you enforce it.

References: Microsoft Learn, "Overview of Server Message Block signing in Windows".

The score carries its version and vector, so anyone can check it in FIRST's calculator, and the business risk gets its own one-line reason. The remediation names the exact setting and the side effect to test for, and step 3 tells the engineer how to prove the fix worked.

How to rate severity: CVSS v3.1 vs v4.0

Most reports rate findings with the Common Vulnerability Scoring System (CVSS), which FIRST maintains. FIRST says "CVSS is currently at version 4.0", first published in November 2023, and keeps v3.1 in its archive. Agree on the version with the client and name it in the methodology. Both versions share the same bands:

The scoring underneath changed. FIRST's v4.0 user guide lists the main differences from v3.1:

• Scope is gone. Impact on the vulnerable system and on subsequent systems is rated separately (VC, VI and VA, then SC, SI and SA).
• A new base metric, Attack Requirements (AT), captures conditions in the vulnerable system that an attack depends on.
• User Interaction has three values: None, Passive and Active.
• Temporal became Threat, and a new Supplemental group adds context without changing the score.
• Scores are labelled by the groups used: CVSS-B for base only, CVSS-BT, CVSS-BE or CVSS-BTE when Threat or Environmental metrics are added.

The same finding gets a different number in each version. The SMB signing example scores 5.3 in v3.1. With the matching v4.0 metrics (CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:L/VA:N/SC:N/SI:N/SA:N), FIRST's v4.0 calculator gives 6.9. Both are Medium, yet the numbers differ, which is why every score in a report should carry its version and vector.

CVSS base score vs business risk

FIRST is clear about what a base score can't tell you. The v3.1 user guide says "CVSS is designed to measure the severity of a vulnerability and should not be used alone to assess risk." The v4.0 specification says consumers "should enrich the Base metrics with Threat and Environmental metric values specific to their use of the vulnerable system."

Risk is a separate measure. NIST's glossary, quoting SP 800-30, calls it "typically a function of" the adverse impact if an event occurs and "the likelihood of occurrence". For a finding, that means two questions about this client:

• Likelihood. Is it internet-facing or internal only, how much access does an attack need, and is exploit code public?
• Impact. What sits behind it: test data, or customer records, payment systems and domain admin rights?

A Medium base score on a server holding the client's most sensitive data can be a High business risk, and a High score on an isolated test box can be a Low one. Report the CVSS base score, your risk rating and one sentence on why they differ, and describe your rating method in the methodology.

Pentest report templates, samples and generators

You don't have to build the document from scratch. These four reporting platforms can all be self-hosted for free (checked on GitHub on November 3, 2026).

SysReptor sums itself up as "Design your report in HTML. Write it in Markdown. Render to PDF." The Community edition is source-available and free for internal business and personal use, though every user who can log in is a superuser who sees every project. It also runs a free cloud service for certification exam reports.

Ghostwriter, sponsored by SpecterOps, adds assessment management: a findings library, infrastructure tracking, Word reports from Jinja2 templates, and activity logging from Mythic and Cobalt Strike. It suits red teams and consultancies.

PwnDoc builds a customizable Word report, scores in CVSS v3 and v4, and supports team editing with retest and review workflows. Its optional AI writing help can use hosted providers, so check your contract before sending client findings to one.

Dradis Community Edition imports output from Burp Suite, Nessus, Nmap, Qualys, ZAP and other tools. It handles one project at a time with unbranded templates, and the paid Pro edition adds multiple projects, template control and a client portal. Kali packages it in its reporting tools metapackage.

For the OSCP exam, OffSec publishes its own report template in Word and LibreOffice formats, and our guide to the OSCP exam report walks through it.

Pentest report examples and samples

The quickest way to learn the format is to read finished reports. The public-pentesting-reports repository on GitHub holds nearly 400 PDFs sorted by firm, from Cure53 and NCC Group to Trail of Bits and Doyensec. New reports were still being added in June 2026.

Many are software audits, such as the curl reviews by Trail of Bits and Cure53. For network tests, read TCM Security's demo report for an internal penetration test, which rates findings by likelihood and impact, and OffSec's 2013 sample report, which tells the attack as a narrative first. The repository has no licence file, so read the reports for structure and tone and write your own text. SysReptor's docs also have a demo reports page with finished PDFs.

Pentest report automation

Automation handles the repetitive parts: importing scanner output, reusing finding text from a library and rendering the PDF. It can't judge what matters in this environment. Confirm every imported scanner result by hand, because one false positive makes the client doubt the rest, and rewrite library text for this client's assets and impact.

How bug bounty reports differ

A bug bounty report covers one finding and goes to a program's triage team through a platform. It skips the executive summary and scope, since the program sets the scope, and the reader may know less about the bug class than you do.

HackerOne's quality report guidance asks for:

• A specific title. Its example sets "XSS in web app" against "Stored XSS in user profile field allows script execution on profile view".
• Numbered steps to reproduce with the URLs, affected parameters and user roles involved.
• Impact. "Explain the potential consequences of the vulnerability."
• Supporting material such as screenshots, recordings or code snippets, with videos uploaded as attachments.
• A fix, optionally. "While not required, including suggestions for fixing the issue can be helpful."

You also pick the asset, weakness type and severity (HackerOne's CVSS calculator can help), and check the issue hasn't been reported and is in scope. You can't edit the details after submitting.

Bugcrowd's form asks for a summary title (bug type, where, impact), the target, a technical severity from its Vulnerability Rating Taxonomy (VRT), and a description with headings for Overview, Walkthrough and PoC, Vulnerability Evidence, and Demonstrated Impact. It prefers a proof-of-concept video, and its advice is to write for a reader who may know less than you.

A bug bounty report template that fits both: title, asset, weakness, severity (CVSS vector or VRT category), summary, steps to reproduce, impact, evidence and a suggested fix. It's the finding format from earlier without the client-report wrapping.

Habits that make pentest reports easier to write and read

These habits do more for a report than any template.

Write while you test. Log your terminal, keep tool output in files, and note the time and source IP of anything that might become a finding. If the client asks whether an alert was you, your timestamps answer it. Our guide to OSCP note-taking covers engagement notes, and the setup works the same outside the exam.

Write the executive summary last. It's read first, by the most senior readers, so write it once you know the whole story. Keep it to about a page: what you tested, how far an attacker got, the findings that matter most, and what to do first, with no CVE numbers or tool names.

Make remediation actionable. "Apply patches" isn't a fix anyone can schedule. Name the setting, version or code change, and who owns it. NIST SP 800-115 adds a second layer: "There may be both technical recommendations (e.g., applying a particular patch) and nontechnical recommendations that address the organization's processes (e.g., updating the patch management process)."

Keep severity consistent. Set the CVSS version and your risk rules before the test, write them into the methodology, and apply them to every finding the same way. If the same issue gets two ratings, the impact field should say why.

Get a peer review. A second tester should follow your steps to reproduce, challenge your ratings, check every secret is redacted, and catch text left over from another client's report.

FAQ

What is a pentest report template?

A pentest report template is the reusable outline for a penetration testing report: the standard sections and a fixed set of fields for every finding. Using the same one every time keeps reports consistent and quicker to write.

What should a penetration testing report include?

Document control, an executive summary, scope and rules of engagement, methodology, a findings summary, detailed findings, a remediation roadmap and appendices. Each finding needs a title, severity with a CVSS score and vector, affected assets, description, impact, evidence, steps to reproduce, remediation and references.

Should a pentest report use CVSS v3.1 or v4.0?

FIRST's current version is CVSS v4.0, but use whichever version the client asks for and name it in the methodology. Always show the version and full vector next to each score, because the same finding can score differently in each.

Is there a free pentest report generator?

SysReptor Community, Ghostwriter, PwnDoc and Dradis Community Edition can all be self-hosted for free. Ghostwriter is BSD-3-Clause, PwnDoc is MIT, Dradis CE is GPL-2.0, and SysReptor Community uses its own source-available licence.

Where can I find pentest report examples?

The public-pentesting-reports repository on GitHub collects nearly 400 published reports from consulting firms and academic groups, and SysReptor's docs include demo reports. Read them for structure and tone, then write your own text.

How is a bug bounty report different from a pentest report?

A bug bounty report covers one vulnerability and goes to a program's triage team through a platform like HackerOne or Bugcrowd, so it skips the executive summary, scope and methodology. It still needs a clear title, steps to reproduce, impact and evidence.

Is the OSCP exam report the same as a pentest report?

It follows the same idea, and OffSec adds rules of its own, such as a proof screenshot for every flag. Our OSCP report template guide covers those rules and OffSec's official template.

Write a practice pentest report on a lab

The fastest way to get good at reports is to write complete ones before anyone pays for them. Pick a lab whose platform allows write-ups, test it with the evidence habits above, write the whole report, and ask someone to review it the way a client would.

Our free AD chains start from an assumed breach, so each one gives you a starting account, a path across several machines and findings to write up. Our OSCP Practice Labs playlist shows the chains worked part by part, so you can check your attack path once your report is written. If you're preparing for the OSCP, our course for OSCP prep has a reporting section, and the OSCP roadmap shows where the report fits. Hack The Box's CPTS also grades a client-style report, and our OSCP vs CPTS comparison covers both exams' reports.

Jess, one of our students, wrote: "I've been here for a while now, and it's been well worth the money for me. They actually help you when you ask for it, and all their courses have been amazing so far." (More reviews)

Start the course with a free trial, or write your first practice report on one of our free Active Directory chains.

Stuck on a severity rating or a remediation line? Ask in the Hacker Blueprint Discord.

Sources

• FIRST: CVSS v4.0 Specification Document (metric groups, Attack Requirements, User Interaction values, Supplemental metrics don't change the score, CVSS-B/BT/BE/BTE naming, qualitative bands, enriching the base score with Threat and Environmental metrics, the CVSS:4.0 vector; checked Nov 3, 2026)
• FIRST: CVSS v4.0 User Guide (changes from v3.1: Scope removed, Attack Requirements added, Temporal renamed Threat, new User Interaction values; base scores measure severity; checked Nov 3, 2026)
• FIRST: CVSS v3.1 Specification Document (metric groups, base metrics, qualitative bands; checked Nov 3, 2026)
• FIRST: CVSS v3.1 User Guide (section 2.1, CVSS measures severity and should not be used alone to assess risk; checked Nov 3, 2026)
• FIRST: CVSS (current version 4.0, v3.1 in the archive) with the v3.1 calculator and v4.0 calculator (the example scores of 5.3 and 6.9; checked Nov 3, 2026)
• NIST CSRC Glossary: risk (the NIST SP 800-30 Rev. 1 definition, impact and likelihood; checked Nov 3, 2026)
• NIST SP 800-115, Technical Guide to Information Security Testing and Assessment (September 2008; the four penetration testing phases, reports with multiple audiences and formats, technical and nontechnical recommendations; checked Nov 3, 2026)
• Microsoft Learn: Overview of Server Message Block signing in Windows (what signing does, relay and spoofing, when a session is signed, the two Group Policy settings, non-Microsoft file servers, signing auditing from Windows 11, version 24H2; checked Nov 3, 2026)
• Nmap: smb2-security-mode (what the script checks and its "Message signing enabled but not required" output; checked Nov 3, 2026)
• SysReptor on GitHub, Upgrade to Professional and Demo reports (licence, latest release, editions, superuser access in Community, demo reports; checked Nov 3, 2026)
• Ghostwriter on GitHub (BSD-3-Clause, SpecterOps, findings library, infrastructure tracking, Jinja2 Word templates, other formats, Mythic and Cobalt Strike logging, latest release; checked Nov 3, 2026)
• PwnDoc on GitHub (MIT, Word output, CVSS v3 and v4, collaboration, retest and review, AI providers including Ollama, latest release; checked Nov 3, 2026)
• Dradis CE on GitHub, Dradis Community Edition and Kali Tools: dradis (GPL-2.0, importers, one project at a time, export formats, Pro features, Kali metapackages; checked Nov 3, 2026)
• public-pentesting-reports on GitHub (maintainer, folders by firm, 396 PDFs, last addition June 2026, no licence file, the TCM Security and OffSec 2013 sample reports; checked Nov 3, 2026)
• HackerOne: Quality Reports (title, steps to reproduce, impact, supporting material, optional fix, duplicate and scope check; checked Nov 3, 2026)
• HackerOne: Submitting Reports (asset, weakness, severity and CVSS calculator, attached videos, no edits after submitting; checked Nov 3, 2026)
• Bugcrowd: Reporting a Bug (summary title, target, VRT technical severity, description headings, attachment limits, POC video, writing advice; checked Nov 3, 2026)