How to Write a Penetration Test Report, Step by Step

To write a penetration test report, set the document up before testing starts, capture each finding with its evidence while you test, score the CVSS vector before you write the prose, and write the executive summary last. Then put the whole report through technical and editorial QA, deliver it as a numbered version, and update it after the retest. The steps below take a report from first note to delivery, with a checklist to finish.

1. Set the report up before testing: scope, exclusions, testing window, source addresses, accounts and the agreed severity scale.
2. Capture evidence as you test: time, source, target, what you did and what you saw, with secrets redacted at capture.
3. Write each finding when you confirm it, not at the end of the week.
4. Merge duplicates: one weakness, with every affected asset listed against it.
5. Score the vector first, then write the description, impact and remediation to match it.
6. Build the remediation summary and appendices from the findings.
7. Write the executive summary last.
8. Run technical and editorial QA before anything leaves.
9. Deliver a numbered version, hold the debrief, and record the retest as a new version.

Before testing: set the report up

The report starts on the day the statement of work is signed, not on the last day of testing. Much of its front half is known before the first request: what is in scope and what is not, the testing window and permitted hours, the source IP addresses you will test from, the accounts the client is providing, the version or build under test, and the severity scale and target fix times agreed with the client. Fill those in first, from the statement of work and the rules of engagement, while they are in front of you. The free penetration test report template has a field for each.

Decide two things about evidence at the same time. Where it will be stored, so screenshots of a client’s data are not scattered across laptops and chat threads. And what gets redacted at capture: passwords, session tokens, keys and personal data, every time, before the image is saved.

Write while you test

The habit that saves the most time is writing each finding as you confirm it. On the day, the evidence, the context and the exact location are in your head. Four days later, written from notes, the same finding loses the detail that made it reproducible, and the last afternoon of the engagement becomes an exercise in archaeology.

For every confirmed observation, capture five things:

• When. Date and time, with the time zone.
• From where. The source IP address, and the account you were using if there was one.
• Against what. Host, port, URL, endpoint, parameter or file, exactly.
• What you did, in a sentence a reviewer can follow.
• What you saw. The request and response, screenshot or tool output, cropped to what proves the point.

Record what held, too. A control you tested that did its job, such as multi-factor authentication enforced on every administrative interface, is evidence: it shows where the test looked, and it gives the executive summary something true to say besides a list of problems. Note every pause, block or change of plan with the time as well. That is the timeline appendix, and it cannot be rebuilt accurately afterwards.

For what makes a screenshot or a request hold up when a reviewer, or a client’s developer, reads it cold, see evidence that survives peer review.

Notes into findings, in the order that saves time

Write each finding in the same order every time. The order matters because each field constrains the next.

• Title. Name the weakness and where it is: "Order history readable by any logged-in customer through the orders API", not "IDOR", and never the name of a tool’s check.
• Affected assets. Every location, one per line. If the same weakness is on eleven hosts, it is one finding with eleven lines.
• CVSS vector and severity. Before any prose, for the reason in the next section.
• Description. What is wrong, where, and why it is a weakness, in two to four sentences.
• Evidence. The captures from testing, in the order a reader needs them.
• Impact. What an attacker gets in this system and what it would take, not the generic consequence of the vulnerability class.
• Remediation. The change, where to make it, any temporary mitigation labelled as temporary, and how to confirm the fix.
• References. Two to four that help with the fix.

If your firm keeps a findings library, start common findings from the library entry, then rewrite the parts that belong to this client: the affected assets, the evidence, the impact and usually the remediation. Library text is generic by design. The client is paying for the specific part.

AI drafting fits here, within limits. A model given your evidence can produce a reasonable first draft of a description or a remediation. It should not choose the severity, and nothing it writes should reach a client unread. Pental’s AI drafting on your own key or your own hardware writes fields from evidence with prompts you can edit, and it can be switched off entirely.

Severity with its reasons

Score the CVSS vector before you write the description, then write the description to match it. A vector chosen after the prose tends to be chosen to fit the prose, and the two drift apart in review. Score what you observed, not the worst thing that could follow: if you read one table, the impact metrics describe one table, and the chain to full compromise belongs in the narrative unless you actually walked it.

Then add a line of rationale for any metric a reader could dispute. For an on-path finding that is usually attack requirements and user interaction; for an access control finding, privileges required. If the client’s context changes the rating, say what changed it and keep the base score beside it. For example:

Order history readable by any logged-in customer through the orders API
  CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N    7.1 (High)
  
  Rating rationale: needs a customer account (PR:L), and anyone can register
  one. No other user is involved (UI:N). Every customer's order history,
  including names and delivery addresses, is readable (VC:H). Nothing can
  be changed (VI:N). No adjustment for context.

What each level means, how CVSS 4.0 maps onto it and when a likelihood and impact matrix fits better are in penetration testing severity levels.

The executive summary, last

The summary is written last because it depends on everything else: you cannot name the most serious finding until severity is settled, or describe themes until duplicates are merged. It is one page, for a reader who will read nothing else, and it answers four questions in order: what was tested, the most serious thing found, what it means for the organisation, and what happens next.

Assembly is faster than composition. A skeleton like this one produces a first draft in minutes, and the time then goes on the sentences that matter:

[Firm] tested [system] for [client] between [date] and [date], from
  [position], against the [environment] environment.
  
  The most serious finding is [one plain sentence: who could do what].
  We reported it on [date] and it [was fixed during testing / is not yet fixed].
  
  Overall, [one sentence on the security position].
  
  The changes that matter most are [theme 1] and [theme 2]. [Size of the
  work: a configuration change, a sprint, a design decision.] We recommend
  retesting the critical and high findings by [date].

Then replace every generic sentence with a specific one. "Could lead to reputational damage" is filler. "Any customer could read every other customer’s delivery address" is a risk statement. There is more on structure in writing an executive summary that gets read.

Remediation summary and appendices

Build the remediation summary from the findings, grouped by the change that fixes them rather than by finding. One configuration change often closes four findings, and an engineering lead turns a table organised by change straight into tickets. Give each action an owner and a target date from the agreed timescales, written as a date rather than a number of days.

The appendices are records, not padding: the test accounts (never their passwords) with their status after testing, the timeline of the engagement including pauses and when urgent findings were reported, and a clean-up record of everything created or changed on the client’s systems. Long tool output belongs here too, if it belongs anywhere, rather than inline in a finding.

QA before anything leaves

Every report gets two reviews by somebody other than the author, and they look for different things.

QA is easier on the record that produces the document than on a PDF passed around by email. In Pental, reports go through a QA queue where a reviewer comments, suggests changes or applies them, then sends the report back to the tester or approves it. How the QA review works walks through it.

Delivery, the debrief and the retest

Deliver the report as a numbered version, 1.0, to the people on the distribution list, through a channel with access control rather than as an email attachment. Then hold a debrief call: walk through the critical and high findings and the themes, and answer the developers’ questions while the engagement is fresh.

Two things from the debrief belong on the findings themselves rather than in somebody’s sent items. Disputes: if the client disagrees with a finding or a rating, record what they said and your answer, and change the report only if they are right. Risk acceptance: who accepted the risk, why, and when it will be reviewed, with the severity unchanged.

When the retest happens, record each finding’s result against definitions agreed in advance (Fixed, Partially fixed, Open, Accepted, Not retested) and issue version 1.1 with the retest record completed. Never overwrite 1.0, because the client’s auditor may already hold it.

Checklist

• Scope, exclusions, testing window, source addresses and the version tested are filled in.
• Every finding has one ID, used in the findings summary, the finding, the remediation summary and the retest record.
• Every title names the weakness and where it is.
• Duplicates are merged: one weakness, with every affected asset listed.
• Every finding has the full CVSS vector, a score calculated from it, and a severity that matches the band or explains why not.
• Disputable metrics have a line of rationale.
• Evidence is dated, shows the source address, is cropped to the point and has secrets redacted.
• Impact describes this system, not the vulnerability class.
• Remediation names the change and where to make it, labels temporary mitigations, and says how to confirm the fix.
• References are two to four per finding, and every link works.
• The executive summary answers what was tested, the worst finding, what it means and what happens next, on one page.
• Critical findings were reported by phone during testing, and the timeline says when and to whom.
• The remediation summary groups actions by change, with owners and target dates.
• Test accounts are listed without passwords, with their status after testing.
• The clean-up record lists everything created or changed on the client’s systems.
• Technical QA: a reviewer has reproduced each finding from the write-up.
• Editorial QA: no other client’s name, hostnames or wording; no placeholders or guidance notes.
• Tracked changes are accepted, comments resolved and document properties checked.
• The version number, status and distribution list are up to date.
• The report goes to the people on the distribution list through an access-controlled channel.