Penetration Test Report Template: Free Word Download

This is a free penetration test report template in Word (.docx), with nothing to sign up for. It has a cover and document control, executive summary, scope and testing window, methodology and severity scale, a findings layout ready for CVSS 4.0 with one fully worked example, a remediation summary, a retest record and appendices. The notes below explain every section and every field, and what a good one looks like.

Download the template (Word, 48 KB)

What is in the template

Thirteen A4 pages in Calibri, with the contents page already built, the classification on the cover and in the header of every page after it, and page numbers in the footer. Text in square brackets is a placeholder to replace. Grey italic text is guidance on what a good section looks like, and all of it uses one paragraph style, so it comes out in one go before the report is issued.

Cover, document control and distribution

The cover identifies the document and nothing else: version, date, engagement reference, who it was prepared for and by, and a classification that is repeated in the header of every page. A short confidentiality statement sits beneath them.

Document control answers the three questions an auditor asks first. Which version is this, who checked it, and who has a copy? A good one names people rather than roles: the author, the QA reviewer with the date of the review, and whoever approved release. The status moves from Draft to In QA to Final, then to Updated after retest when the retest lands.

• Version history. A delivered version is never reissued under the same number. A correction or a retest is a new version with its own row, so everybody can tell which copy an auditor is holding.
• Distribution list. Everybody who received this version, and how: client portal, encrypted email, internal record. A pentest report is a description of how to attack the client, so you should know where every copy went.
• Contacts. A named person on your side with a phone number. The finding that turns out worse than it looked needs somebody to call, not a shared mailbox.

Executive summary

Write it last, on one page, for a reader who will read nothing else. It answers four questions in this order: what was tested, the most serious thing found, what that means for the organisation, and what happens next. A critical finding is named in the first three sentences, not on page four.

The difference between a weak summary and a strong one is usually a single sentence. "Several high-risk vulnerabilities were identified that could lead to reputational damage" tells a director nothing they can act on. "A logged-in customer could read every other customer’s saved addresses by changing one number in the address bar; we reported it on the second day and it was fixed before testing ended" tells them what happened, how bad it was and that it is handled.

The template gives the summary five short parts: an overview, the overall result, a count of findings by severity, the key themes and what happens next. Group the themes by cause rather than severity, because nine findings caused by one missing server-side check are one theme and one decision. Close with the size of the work (a configuration change, a sprint, a design decision), the target dates from the severity scale, and what a retest will need to show.

Scope, exclusions and testing window

Scope is where reports are most often misread, so the template records it four ways.

• In-scope assets. Exact hostnames, URLs, address ranges and applications, each with its type, its environment and a note such as which roles were tested. "The website" is not a scope.
• Exclusions. What was not tested and why: denial of service excluded by the rules of engagement, a payment page owned by the payment provider, social engineering not requested. This is the half readers skip and auditors need, because without it a reader assumes coverage you did not have.
• Testing window and conditions. Dates, permitted hours, test type (black, grey or white box), effort in tester days, the testers, the source IP addresses, the version or build tested and the accounts provided.
• Constraints and limitations. Anything that reduced coverage, and its effect, such as an administrator account that arrived on day three. If there were none, the report says so.

Three of those fields do more work than they look. Source IP addresses let the client match your traffic in their logs, during the test and long after it. The version tested makes the report a statement about a known build rather than about a system that has shipped forty times since. And effort lets a reader weigh a clean result: two days that found nothing mean something different from ten.

Methodology and the severity scale

Keep the methodology to half a page. It shows the work was structured; it is not the place to reproduce a public standard. Name each standard you followed and its version, for example the OWASP Web Security Testing Guide v4.2 or NIST SP 800-115, and say how findings are scored. The template states CVSS v4.0 base metrics (CVSS-B), with any adjustment for the client’s context explained in the finding itself.

The severity scale uses FIRST’s qualitative bands, so any reader can check a rating against its score, and gives each level a target time to fix. Those targets belong in the statement of work, agreed before testing, so the report applies them instead of inventing them.

Where the fix is a vendor update on an internet-facing system, a shorter clock applies: the NCSC’s best-practice timescale is five days. The reasoning behind every figure is in remediation timelines checked against Cyber Essentials, PCI DSS, DORA and the NCSC, and what each level means is in penetration testing severity levels.

Findings, field by field

Findings are the body of the report, and the field layout is where templates differ most. The template has one block per weakness, with every affected asset listed against it, and a blank layout whose guidance notes say what goes in each field. This is what a good one looks like.

A finding is finished when a developer who was not on the engagement could fix it without asking you a question. For the client’s side of the same document, see what a penetration test report should contain, and for the order in which to write all of it, how to write a penetration test report.

The worked example: deprecated TLS versions

The template includes one finding written out in full. It is deliberately ordinary: in our experience TLS 1.0 and 1.1 still turn up regularly on external tests, and the finding is easy to score badly, which makes it a good model. Its header fields read:

F07  Deprecated TLS protocol versions accepted (TLS 1.0 and TLS 1.1)
  
  Severity          Low
  CVSS 4.0 vector   CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:P/VC:L/VI:N/VA:N/SC:N/SI:N/SA:N
  CVSS 4.0 score    2.3 (Low), base score (CVSS-B)
  CVSS 3.1 vector   CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:U/C:L/I:N/A:N
  CVSS 3.1 score    3.1 (Low)
  Affected assets   shop.example.com (203.0.113.10), 443/tcp
                    api.example.com (203.0.113.11), 443/tcp
  Retest status     Open. Not yet retested.

The scoring is the part most often done badly, so here is the reasoning, metric by metric.

• Reachable over the network, without an account. AV:N and PR:N.
• The attacker has to be on the path between user and service. In CVSS 4.0 that is an attack requirement, AT:P, and FIRST’s CVSS 4.0 specification gives vulnerabilities that need an on-path attacker as its example. In 3.1 the same condition went into attack complexity, which is why the 3.1 vector has AC:H and the 4.0 vector has AC:L.
• A user has to be using the service while the attacker is in position. That is passive user interaction, UI:P. The specification lists using an application that generates traffic over an untrusted or compromised network as an example of exactly that.
• Small amounts of data at most, and nothing else. VC:L, with no integrity or availability impact and no other system affected.

That vector scores 2.3, Low. The optional 3.1 vector is the one FIRST uses for its own POODLE example in the 3.1 examples document, and it scores 3.1, also Low.

The rest of the example follows the field guide. The evidence is dated, names the source address and trims the tool output to the lines that prove the point. The impact explains why the likelihood is low and still gives the reason the client will care: the IETF deprecated both versions in RFC 8996, and the NCSC’s TLS guidance says to disable them, so accepting them is a common reason to fail security questionnaires and audits. The remediation sets TLS 1.2 as the minimum at every point that terminates TLS, limits TLS 1.2 to the NCSC’s recommended cipher profiles, and says to check the logs for old clients before switching, because the outage a fix causes is the part a client remembers.

Findings summary, remediation summary and retest record

Three tables turn the findings into work somebody can do.

• Findings summary. Every finding on one table, in severity order and then by score, with its ID, severity, score, affected assets and status. It is the page the client’s engineering lead keeps open.
• Remediation summary. Actions grouped by the change that fixes them rather than by finding, each with an owner and a target date. One configuration change often closes four findings, and a table organised by change is the one that gets turned into tickets.
• Retest record. The result for each finding after the retest, against definitions agreed before it starts: Fixed (the weakness is gone and a reasonable variation of the original test fails), Partially fixed, Open, Accepted (with who accepted it, why, and when it will be reviewed) and Not retested. The original severity stays, including for accepted findings.

The retest record opens with a sentence the client will forward to an auditor or a customer: on this date, this firm retested these findings, and this many are fixed. Write it deliberately, because it is often the only part of the retest anybody outside the team reads.

Appendices: test accounts, timeline and clean-up

• Test accounts. Each account, its role, who provided it, what it was used for and its status after testing. Never passwords or keys. Confirm the client disabled or reset each account and record the date.
• Timeline. The kick-off call, when testing started and finished, every pause and its reason, and when urgent findings were reported and to whom. If anybody later asks why a critical finding waited a week, this is the answer.
• Clean-up record. Everything created or changed on the client’s systems during testing, such as uploaded test files and records, and whether each was removed, by whom and when.

Making it your own

• Change fonts and colours in the styles (Normal, Heading 1, Heading 2, Guidance note) rather than paragraph by paragraph, so the whole document follows.
• Add your logo to the cover and, if you want it, to the header.
• Save it as a Word template (.dotx), so every report starts from a clean copy rather than from the last client’s report.
• Add the sections your clients value, such as the controls that were tested and held. A short list of what worked is evidence too, and it shows where the test looked.
• Keep the field labels stable once you settle them. Stable labels make reports comparable from year to year, and they are what you map if you later fill the template from a platform.

Using it with a reporting platform

A Word template is a good start and a slow process. The hours go on copying findings out of old reports, retyping scores, and keeping the findings summary, the remediation summary and the retest record in step by hand.

In Pental, the firm uploads its own Word template, this one included, and the Document Builder maps the fields into it, with AI help to build the mapping. Reports are generated as Word and PDF. Findings are scored in CVSS 3.1 or 4.0 with the score calculated from the vector, can be reused from a findings Library, and carry their own retest status, and the report has a retest summary. A report can also be downloaded, edited in Word and uploaded again, and the changes are read back into the platform. The setup is in making your Word template the one Pental fills, and the rest of the product is on the Pental platform page.