• Sample Pentest Report: A Full Example and Who Writes Each Part
  • Read this if
  • Who does the work in each section
  • The conclusions are written for each client
  • Summary of findings, ratings and charts
  • One finding, field by field
  • The same findings, sliced for the people who fix them
  • Methodology and tools show what you tested
  • What a reviewer changes before a client sees it
  • Turn the sample into your report
  • FAQ

Sample Pentest Report: A Full Example and Who Writes Each Part

Last updated by Rachael Carder on 2026-10-15

Here is a full sample pentest report you can download as a PDF, with no form to fill in.

It is 24 pages exported from the Dradis demo project: five hosts, six findings rated by CVSS, charts, per-host tables and a testing checklist. Below, we go through it part by part and show who does the work in each.

Download the sample report (PDF, 24 pages)

The company, the tester and the engagement are fictional. The project is an infrastructure assessment, and most findings are scanner results on old software. And it is the raw export from an earlier version of our Welcome Kit, so where the conclusions should be, you'll find the template's instructions. Read it as the skeleton of a report. The last section lists what a reviewer would change before it went to a client.

Read this if

• You are writing your first client report and want to see a complete one before you start.
• You lead delivery at a consultancy and want one structure that every tester follows.

Skip this if you need a template for PTES, OWASP, HIPAA or OSCP work. Our free pentest report templates cover those.

Who does the work in each section

Every section of the sample falls into one or more of three kinds of work. Page numbers are the ones printed in the PDF's footer.

Section	Pages	Who does the work
Cover and contents	cover, 1	Built at export: title, client, version, author and date come from the project.
Introduction and scope	2	Built at export: the scope is a list of every host in the project.
Conclusions and recommendations	2	Written for this client.
Summary of findings	3 to 5	Built at export: counts, the findings table and two charts. Reused: the rating scale.
Detailed findings	6 to 19	Reused: description, solution and references. Written for this client: the evidence for each host.
Host vulnerability tables	20 to 21	Built at export: one table per host.
Methodology tasks completed	22	Reused: the checklist. Written for this client: the result of each task.
Appendix: tools used	23	Reused: the tool list.

The first kind of work is mechanical: counting findings, drawing charts and repeating a table for every host.

The other two are where reports differ:

• Paste a write-up from an old report and you spend report day hunting for what came with it: the last client's name, a host that isn't in scope, a version number that no longer matches.

• With reviewed write-ups in a library, you spend it on the evidence and the conclusions.

The conclusions are written for each client

Page 2 opens the report. The introduction names the client and the testing team, and the scope lists the five hosts, all filled from the project.

The conclusions and recommendations come next. A demo project has no client to write for, so the sample leaves this section unwritten. In a delivered report it is the part the client's managers read, and no template can write it. Two standards say what belongs in it:

• The Penetration Testing Execution Standard splits a report into an executive summary and a technical report. Its executive summary covers background, overall posture, risk ranking, general findings, a recommendation summary and a strategic roadmap.
• The UK's NCSC guidance on penetration testing asks for the issues found, the risk each one exposes, a way to resolve each, and advice on improving the client's own vulnerability assessment process.

Summary of findings, ratings and charts

Pages 3 to 5 give the whole picture before any detail. The opening sentence counts the findings: one Critical, three Medium and two Low, four of them internal and two external. Counters in the template fill in each number.

Next comes the rating table, which maps CVSS base scores to ratings: 9.0 to 10.0 is Critical, 7.0 to 8.9 High, 4.0 to 6.9 Medium and 0.1 to 3.9 Low. These are the bands in FIRST's CVSS v3.1 specification, and CVSS v4.0 keeps them. The same specification says "the use of these qualitative severity ratings is optional", and some schemes set their own rule. The NCSC's CHECK scheme requires every issue to be rated High, Medium, Low or Informational, and allows CVSS "in addition to (but not in place of)" those ratings. That is why the table belongs in the report: it tells the reader which rule produced each rating.

The findings table lists all six, ordered by rating and then by location, with the hosts each one affects. Two charts follow, findings by rating and findings by location. Both are drawn from the project's findings when the report is exported, so nobody rebuilds them in Excel when a rating changes between drafts.

One finding, field by field

The Critical finding, a blind SQL injection on pages 7 to 9, shows every field in a finding.

Rating and CVSS. Critical, scored 9.8, with the vector CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H: reachable over the network, with no privileges and no user interaction, and a high impact on confidentiality, integrity and availability.

Description, solution and references. In the sample these are the scanner's own text, and the references point to the scanner vendor's web pages. That is what an unedited import looks like. In a delivered report, your team's write-up replaces it: written once, reviewed, and reused on every engagement that finds the same issue. In Dradis that is the Issue Library, and the Rules Engine can swap the scanner's text for your library entry as results are imported, so the client reads your team's wording in your house style.

Evidence. This is the proof for each host. The sample gives the affected page, a screenshot with a caption, and the scanner's timing test. It set the filter[qty_max] parameter to payloads that ask the database to wait: a three-second wait came back in 3.27 seconds, six seconds in 6.52 and nine seconds in 9.34, while requests with no wait came back in under 1.6 seconds. The response time follows the delay the payload asks for, and that proves a blind injection, where the page itself shows nothing.

Compare it with the S-HTTP finding on page 12, where both hosts' evidence reads "n/a". A scanner flagged the service and nobody confirmed it. NIST SP 800-115 draws the line there: scanners "check only for the possible existence of a vulnerability", while a penetration test "exploits the vulnerability to confirm its existence". In a pentest report, a tester confirms every finding, and the evidence shows how.

Some reports also need parts this sample has no room for, such as an attack narrative that shows how findings chain together. In Dradis, narratives like that are content blocks your team writes in the project, next to the conclusions.

The same findings, sliced for the people who fix them

The detailed findings come in two groups, internal (page 6) and external (page 15). Each group opens with its own chart and summary table, so a network team can skip to the part that is theirs.

Pages 20 and 21 slice the findings again, by host: each host in scope gets a table of its findings with rating and CVSS score. The owner of a server finds it by name and sees their list without reading the rest. None of this needs writing. The template repeats a table for every host in the project.

Methodology and tools show what you tested

The findings don't show the tests that came back clean. The methodology section on page 22 does. That record of coverage is what gives the client assurance. In the sample, the section lists three groups of tests from the OWASP Testing Guide: weak cryptography, error handling and identity management, each with its OWASP ID and a results column for the tester's notes. Only tasks marked done in the project's checklist appear, so a test that is still pending stays out of the report.

The IDs, such as OTG-CRYPST-001, come from the OWASP Testing Guide v4. The current Web Security Testing Guide, version 4.2, numbers the same weak TLS test WSTG-CRYP-01.

The appendix on page 23 lists the tools used: Burp Suite, Nessus, Nmap, Nikto, Metasploit, Qualys, OWASP ZAP, NeXpose and Dradis.

What a reviewer changes before a client sees it

Because the sample is an unreviewed export, it shows the problems a review pass exists to catch:

• Placeholders left in. The Conclusions and Recommendations section has the template's instructions for filling it in, and every result in the methodology table reads "Tester comments".
• Empty evidence. The S-HTTP and TLS renegotiation findings show "n/a" for both hosts.
• Evidence on the wrong finding. Under the Apache cookie finding (CVE-2012-0053), the evidence is the output of an NTP query.
• Scanner wording. The SQL injection description still says the script is "possibly vulnerable", next to evidence that confirms it.

These are content problems, and they are the reason reports go through review. In Dradis, each finding and content block has a QA state: draft, ready for review or published. Reviewers comment inline on the finding itself, and the export can leave out anything not yet published.

Turn the sample into your report

Your report won't look like this one. When your clients dictate the format, every team's template is different, and so is every service line's. So we don't ask you to adopt ours. Send us a sample report. We'll build your Dradis template from it and keep it up to date, at no extra cost on every paid plan. Dradis exports to Word, Excel, CSV, HTML or PDF.

FAQ

Can I get the Word template behind this report?

With Dradis Pro, yes. It sets up the current version, the Welcome Pack, with a sample project for new users. It rates findings by CVSS v4 base score and uses the OWASP Top 10 2021 checklist, so its export differs from this PDF in those two places.