• Penetration testing report: what goes in it and how to write one
  • Who this guide is for
  • What goes in a pentest report
  • Ten published reports, side by side
  • Capture findings while you test
  • Write every finding for a colleague
  • The executive summary
  • Write down how you rated it
  • Review it as one voice, then close the loop
  • Frequently asked questions
  • Sources and dates

Penetration testing report: what goes in it and how to write one

Last updated by Daniel Martin on 2026-10-12

A penetration testing report is the written record of a pentest: what was tested and how, every finding with its evidence, rating and fix, and an executive summary a non-technical reader can act on.

It's the one part of the engagement the client keeps, so every finding has to stand on its own, down to the steps that reproduce it.

Who this guide is for

Read this if you write pentest reports, or you sign them off for a team of testers and want every report to meet your team's standard, whoever wrote it.

Skip this if you need a ready-made template. Our free pentest report templates cover PTES, OWASP, OSCP and HIPAA work. If you'd rather look at finished reports first, the ten below are real ones you can open.

What goes in a pentest report

Every guide asks for the same core, and the parts that get skipped are the ones a client needs after delivery. The last column counts the ten reports in the next section; a dash means we didn't count that part.

The four guides are PTES¹, NIST SP 800-115², the OWASP Web Security Testing Guide³ and the PCI Security Standards Council's penetration testing guidance⁴. They're from different years and none of them is a rulebook, but they agree on the split. PTES divides the report into an executive summary and a technical report, and NIST says "multiple report formats may be required" because a report has several audiences. They also leave the format to you: PTES encourages you "to use your own customized and branded format". Most of the time that's your own format, but some clients send theirs. A bank sends its own template, and a government buyer sends its own rating scale.

Whatever the format, the same parts go in. If the client's template has no field for reproduction steps, put them in its description field or an appendix, but don't drop them. If the client uses its own rating scale, give their label and keep your reasoning next to it, so the two can be compared. If there's no place for retest status, add a short status table at the front and reissue the report after the retest.

Ten published reports, side by side

Most pentest reports never leave the client. The public pentesting reports collection on GitHub gathers the ones that did, nearly 400 of them. We picked ten from ten different firms, all from 2022 or later, and read them for what the table above lists.

What they share is the part every guide agrees on: nine have an executive summary and all ten give fix advice.

Only Doyensec and Include Security give every finding a reproduction section, the part a retester needs months after delivery, with the commands or requests to run. Fix status is missing from half the reports, though a report published before any retest can't have one yet.

These numbers are probably a best case. Eight of the ten are audits of open-source or privacy tools whose owners chose to publish them, three of them for the same company, and a report written for publication gets a polish most client reports don't. The bank report written against the bank's template never shows up in a collection like this.

Capture findings while you test

When three testers each keep their own notes, reporting week turns into collating everyone's work into one document, and that's time spent before anyone writes a word for the client. Keep evidence for every finding in one place the whole team writes to, with the request, the response and the screenshot together, and note the account and steps as you go. Write each finding's steps the moment you confirm it, while the requests are still in your proxy history.

Write every finding for a colleague

An earlier version of this guide, by Dradis creator Daniel Martin, put the test as a question: if a retest is requested six months from now, could one of your colleagues reproduce your findings using only what's in the report? The part that usually goes missing is the user role you were logged in as, or the requests between the login form and the one that exposed the issue. Document only the last step and the retester starts from scratch.

OffSec asks the same of anyone sitting the OSCP+ exam: documentation "thorough enough that your attacks can be replicated step-by-step by a technically competent reader"⁵. OWASP's guide suggests shipping the artifacts that make that easy, such as curl commands, proof-of-concept forms and HAR files, so developers can check their own fixes³.

Here's what that looks like on one finding: the blind SQL injection in our own demo project's sample report, an older export rated with CVSS 3.0, with the scanner's text imported as is. Its description opens with "This script is possibly vulnerable to SQL Injection attacks". The solution reads, in full: "Your script should filter metacharacters from user input." Neither is wrong, and neither tells a developer what to change. Here's the same finding written for the two people who will read it.

For the developer, in the detailed findings:

Blind SQL injection in the warehouse quantity filter

Where: the filter[qty_max] parameter of /ui/warehouse/index.php on host 1.1.1.1 (the demo project's placeholder address), an application on the internal network.

Access needed: none.

Rating: Critical, CVSS 3.0 base score 9.8 (AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H). The base score doesn't account for the application being reachable only from the internal network. We kept it Critical, because a working SQL injection into a business database is serious from inside the network too, and we say where it can be reached so the client can weigh that.

What we saw: a time-delay payload in that parameter controls how long the page takes to answer. Asking the database to sleep for 3, 6 and 9 seconds produced responses in 3.3, 6.5 and 9.3 seconds. Without the delay, responses came back in under 1.6 seconds. The database is running SQL we supplied.

To reproduce: send a GET request to http://1.1.1.1/ui/warehouse/index.php with filter[qty_max] set to this value, URL-encoded:

(select(0)from(select(sleep(6)))v)/*'+(select(0)from(select(sleep(6)))v)+'"+(select(0)from(select(sleep(6)))v)+"*/

Then send it again with each sleep(6) changed to sleep(0), and compare the response times.

Fix: pass filter[qty_max] to the database as a bound parameter instead of building it into the query string, then check the page's other filter[] parameters the same way.

To check the fix: repeat the sleep(6) request. The response time should no longer follow the delay.

For the reader of the executive summary:

Someone on the internal network could run their own database queries through the warehouse application. The fix is a code change on one page, and the finding includes a test the developers can rerun to confirm it.

The developer version stands on its own, so a colleague can retest it. The summary line says what's at stake without the word "SQL". Neither says "possibly".

Two caveats on this example. The demo data doesn't say whether the scanner was logged in when it sent these requests, or as whom. A retester needs that first, so confirm it before a real report goes out. And the value above is the scanner's full probe, which covers quoted and unquoted input in one request⁸. The sample PDF's formatting dropped its * and + characters and curled its quotes, so check any evidence you paste.

The executive summary

Write it last, once every finding and rating is final. It's the section most likely to be read by everyone who touches the report, and often the only one. In an r/cybersecurity thread on how detailed a report should be, one practitioner described their firm sending two versions of each report: the full one, and a summary-only version for customers who ask to review it⁶. So it has to make sense with nothing around it.

What goes in it:

• Why the test happened and what was in scope, including what was out of scope and anything that got in the way, such as an environment that was offline for half a day. This is also your protection if someone later questions the coverage.
• The overall posture, in business terms. PTES suggests separating systemic issues ("Lacking Effective Patch Management Process") from symptomatic ones ("Found MS08-067 missing on xyz box")¹. One systemic issue explains a dozen findings, and that's the line leadership can act on.
• The few findings that matter, described by what an attacker could do with them, not by vulnerability class.
• What to do next, in order.

If the environment held up and you found only low-impact issues, say so. Padding the summary with "ICMP timestamps enabled" to look busy costs you more trust than a short summary does. Seven of the nine published reports with a summary kept it to one or two pages.

Write down how you rated it

A rating is an argument, and the client will test it. PCI's guidance says "the report should clearly document how the severity/risk ranking is derived"⁴, and OWASP's suggests defining your levels in an appendix. Seven of the ten reports above did one or the other. Three gave labels and nothing else.

Only one of the ten used CVSS (version 3.1), and none used CVSS v4. If you use CVSS, say which score you're giving. CVSS v4.0, published by FIRST in November 2023, says the Base score describes the vulnerability itself and calls a Base-only score CVSS-B⁷. Threat metrics adjust it and Environmental metrics refine it for a specific environment. A 9.8 on an application only the internal network can reach may not be this client's most urgent problem, and your rating should say how you weighed that, as the example above does. Our CVSS v4 guide for pentest teams goes through the metrics.

Expect ratings to move. In the same thread, another practitioner said their firm ends up changing something between draft and final "about a third of the time"⁶. That's normal when the client knows things you don't. Put the reasoning in the finding, so the client can point at the fact they disagree with.

Review it as one voice, then close the loop

On a team, the reviewer runs the colleague test. Every finding should go out as your team's best write-up of it: the wording, risk rating and fix advice your team has worked out over years of engagements, whoever did the testing. Before the report is sent, they check:

• Consistent ratings. Two testers shouldn't rate the same missing header Medium in one section and Low in another, unless the context differs and the finding says why.
• One wording per kind of finding. The second write-up of the same issue reads like the first, not like whatever the scanner said.
• Evidence on the right finding, and steps that work when someone other than the author follows them.
• No template leftovers: instructions, placeholder text, last client's name.
• Redaction: passwords, session tokens and personal data masked in screenshots and requests.
• Delivery: OWASP's guide advises you "to secure the report and encrypt it to ensure that only the receiving party is able to use it"³.

Then plan the retest before you send the report. NIST SP 800-115 notes that retesting "will validate that the mitigation actions have been completed"², and PCI's guidance gives an example of a short retest report: an executive summary, the dates of the original test and the retest, the original findings and the results of the retest⁴. Give every finding a status (fixed, not fixed, risk accepted), so the client can close the engagement out.

A reporting tool like Dradis Pro can take most of the consistency checks off the reviewer. Your team's best write-up of each finding lives in the Issue Library, reviewed on its own, outside any one report, and the Rules Engine puts it in place of the scanner's description as findings come in. A finding that starts from the library is already known good, so the reviewer checks what this engagement added, like the evidence and the reproduction steps.

Findings and evidence go through Draft, Ready for review and Published, and the export includes only what's published. In a report built by hand, adding one finding mid-engagement means renumbering everything after it and adding rows to the summary tables, and that time rarely gets billed. Here, a weekly or interim report is one more export of whatever has been reviewed so far. On every paid plan, we build your report template from a sample report and keep it up to date, so nobody on your team spends tester days on template work.

Frequently asked questions

Sources and dates

1. PTES Technical Guidelines: Reporting and PTES main page, Penetration Testing Execution Standard, last edited August 2014. Read October 2026.
2. NIST SP 800-115, Technical Guide to Information Security Testing and Assessment, September 2008, sections 8.2 (reporting) and 8.3 (remediation).
3. OWASP Web Security Testing Guide: Reporting Structure, latest version, read October 2026.
4. PCI SSC Information Supplement: Penetration Testing Guidance, version 1.0, March 2015, sections 5, 5.1.1 and 5.2.2.
5. OffSec OSCP+ Exam Guide, Documentation Requirements, updated April 2026.
6. How detailed should a pentest report be?, r/cybersecurity, November 2024. Practitioner comments, one firm's experience each.
7. CVSS v4.0 Specification Document, FIRST, first published November 1, 2023 (document version 1.2, June 2024).
8. The probe's full form, with its comment markers and + signs, as published in Exploit-DB entry 32330 (OpenSupports 2.0 blind SQL injection), read October 2026.
9. The ten reports: links in the table above, from the public pentesting reports collection. We counted from each report's full text in October 2026. A report counts for steps when every finding rated above Low has steps, requests or a proof of concept another tester could follow; a rating counts as explained when the report gives a method, a matrix, CVSS or defined levels.