Pentest Report Template and Example: How to Write a Report That Passes Review

You can root every box, chain the privilege escalation and land every flag, and still fail because the report is thin, out of order or impossible to verify. In OSCP, CPTS, PNPT, CRTP, OSWE and most other practical exams the report is not admin work after the test. It is part of the test, and graders cannot award credit for a step they cannot see.

This page gives you the structure reviewers expect, one finding written out in full, the evidence rules that decide marks, a reusable skeleton you can paste into your notes, and the differences between exam and client reporting. At the end we explain what our ready-to-submit reports and review services actually contain.

• Why the report decides the result
• The structure reviewers expect
• One finding, written out in full
• Evidence rules that decide marks
• Exam reporting vs client reporting
• A reusable skeleton
• Common failures that cost candidates
• Ready-to-submit reports and report reviews
• Frequently asked questions

Why the report decides the result

Two audiences read a penetration test report, and a good template serves both without mixing them. A grader or a client’s security lead wants to know what was in scope, what was found, how serious it is and what to fix first. An engineer wants the exact affected asset, the reproduction steps and the evidence. When a report forces either reader through content meant for the other, it feels loose, and loose reports get marked down.

The second reason the report matters is proof. A shell screenshot without context is noise. A privilege escalation with no visible transition from the low-privilege user to the high-privilege one is, to a grader, an escalation that did not happen. The template’s job is to force you to capture the right proof while the chain is still fresh, not to look polished.

The structure reviewers expect

Every strong pentest report, exam or client, follows the same skeleton. The section order below is the one graders and reviewers are used to, and there is no advantage in being creative with it.

Section	What it must answer	Common failure
Engagement overview	Who, what, when, and the objective in one paragraph	Missing dates, tester name or assessment type
Scope and limitations	What was authorised, what was excluded, what could not be tested	Vague statements with no boundaries
Methodology	The phases you actually performed, briefly	A textbook chapter, or claiming steps you did not do
Executive summary	The business risk, the count by severity, the first thing to fix	Repeating tool names and scores
Findings	One structured entry per weakness, with proof	Screenshots without context, missing reproduction steps
Attack narrative	How separate weaknesses compounded into the outcome	Treating every issue as isolated
Remediation	What the owner should change, specifically	“Patch systems” with nothing actionable
Appendices	Proof files, full command output, hashes, tool versions	Proof buried in the body, or missing entirely

For a host-by-host exam such as OSCP, the findings section is organised per target: enumeration, foothold, privilege escalation, proof. For a web exam such as OSWE or a client web assessment, it is organised per finding, because the same weakness tends to recur across endpoints. For a red team style exam such as OSEP, CRTP or CRTE, the attack narrative carries the most weight, because the path is the point. Pick the organisation that matches how you will be graded and keep everything else identical.

One finding, written out in full

Every finding should read like a compact technical case, in the same internal order every time: title, severity, affected asset, description, impact, reproduction, evidence, remediation. Consistency is not cosmetic. It lets a reviewer compare findings quickly and lets a client assign each one to the right team. Here is one finding at the level of detail that passes review.

Title. Stored cross-site scripting in support ticket comments allows session hijacking of administrative users. Not “Critical XSS found”. The title names the weakness and the consequence.

Severity: High. Justified in one sentence: an authenticated low-privilege user can execute JavaScript in an administrator’s browser. If the payload only fired in the attacker’s own view, this would be Low, and saying so is what makes the rest of your severities believable.

Affected asset. https://app.example.local/tickets/{id}, the comment body field, all authenticated roles.

Description. The application stores user-supplied HTML from the ticket comment field without sanitisation and renders it without output encoding when any other user views the ticket.

Impact. Demonstrated: a script submitted as a standard user executed when the ticket was opened by an administrator, and the administrator’s session cookie was exfiltrated to a tester-controlled listener. Not demonstrated: any action taken with that session. Report what you did, then state the realistic next step.

Reproduction. Authenticate as a standard user. Open any ticket. Submit a comment containing the payload (given as text, not a screenshot). Authenticate as an administrator and open the same ticket. Observe the request to the listener. Include the exact endpoint, method and the one header or role that matters.

Evidence. Three items: the request submitting the payload, the administrator’s view executing it, and the listener receiving the cookie, each captioned with what the reviewer is looking at. More screenshots than that is clutter, fewer is an unproven claim.

Remediation. Context-aware output encoding on render, server-side sanitisation of rich-text fields to an allow-list, and the HttpOnly flag on the session cookie as a compensating control. Note that Content Security Policy reduces impact but does not fix the root cause.

That is the difference between a finding that passes and one that reads like raw lab notes.

Evidence rules that decide marks

• Every screenshot supports one claim: the target address, the authenticated user, the command output, the privilege level, or the proof file. Caption it. A terminal image full of unreadable output is weak evidence even when the exploit worked.
• Commands, requests, hashes and proof values go in as text, not only as images. Text is searchable, reproducible and cannot be misread.
• Show the transition. For a privilege escalation, the reviewer needs to see the low-privilege context, the action, and the high-privilege context. Skipping the middle step is the single most common way to lose a machine’s points.
• Label evidence by host and finding as you capture it. Reconstructing which screenshot belonged to which target at the end of a 24-hour exam is how gaps appear.
• Redact what should not travel: passwords, session tokens, personal data. Put anything that must be included in a protected appendix.
• Distinguish confirmed from observed. A scanner result justifies investigation; it is not a finding until you validated it. Say when rules of engagement stopped you from exploiting something.

Exam reporting vs client reporting

The discipline is the same; the weighting changes.

For a grader, reproducibility and chronology carry the weight. The reviewer must be able to follow your methodology from enumeration to proof without guessing, and every point you claim must be visible in the document. Executive language does not rescue a thin technical section.

For a client, prioritisation carries the weight. Stakeholders want business impact, affected workflows and what to fix first; engineers want the technical appendix. A critical finding without specific remediation is unfinished work, and a severity that does not match the demonstrated impact costs you trust on every other finding in the document.

Where exams differ from each other. OSCP grades a per-host report inside a fixed submission window after the 24-hour exam. CPTS and PNPT give you days, and grade the report as a professional deliverable: CPTS as an engagement report with an attack narrative, PNPT with a live debrief where you present it. CRTP and CRTE mark how clearly you explain each Active Directory step, not just whether you got there. OSWE expects the source-level reasoning behind each exploit. CRTO and BSCP have no report at all. Know which of these you are writing for before you open the template.

A reusable skeleton

Paste this into your notes at the start of every lab session and fill it in as you work. It is deliberately plain; the structure is the value, not the formatting.

1. Engagement overview
   Client/lab, dates, tester, assessment type, objective

2. Scope and limitations
   In-scope hosts/URLs/roles, exclusions, untested areas and why

3. Methodology
   Recon → enumeration → validation → exploitation → privilege escalation → post-exploitation

4. Executive summary
   Overall posture, count by severity, the most consequential path, first action

5. Findings (repeat per finding)
   Title (weakness + consequence)
   Severity + one-sentence justification
   Affected asset(s)
   Description (why the weakness exists)
   Impact (what was demonstrated; the realistic next step)
   Reproduction (exact commands/requests as text)
   Evidence (captioned screenshots, proof values)
   Remediation (specific to the cause; compensating controls noted)

6. Attack narrative
   How findings chained: initial access → escalation → lateral movement → impact

7. Remediation summary
   Prioritised, grouped by owner

8. Appendices
   Proof files and hashes, full command output, tool versions

Keep it in Markdown while you test: it is fast, version-friendly and converts cleanly to PDF or DOCX for submission. Fighting a word processor during the exam window is a common way to lose hours.

Common failures that cost candidates

1. Writing the report after the assessment from scattered notes. Capture evidence in real time, labelled by host and finding.
2. Confusing enumeration output with proof of exploitation. A scan result is a lead, not a finding.
3. Overstating impact. A missing rate limit is not critical. Self-XSS is not High because it contains the letters XSS.
4. Generic remediation. “Implement security best practices” tells the owner nothing. Match the fix to the cause.
5. Inconsistency. Hostnames that differ between sections, timestamps that do not line up, severities that contradict the described impact. Small inconsistencies make reviewers doubt the whole chain of evidence.
6. Splitting one root cause into six findings to inflate the count, or burying six distinct issues under one heading. Group by root cause and remediation owner.

Ready-to-submit reports and report reviews

For most certifications we sell we include a finished report in the format that vendor expects: the required sections already laid out, the worked methodology, the exact commands for each stage and screenshots at the level of detail graders look for. You write your own evidence into it instead of starting from a blank page the night before submission. They are listed on each certification page, for example CPTS, OSCP, PNPT, CRTP and OSWE, and the full catalogue is on the certifications index.

If you have already written your report and want it checked before you submit, two services cover that.

For candidates who want someone alongside them during the exam itself, remote exam support covers the window and the report after it. All of it is delivered by people who have sat these exams; the proofs page shows real orders and reviews.

Frequently asked questions

Should I copy a sample report word for word?

No. Copy the structure and the level of evidence, never the wording. Graders read hundreds of reports and recognise pasted text, and a copied finding that does not match your own evidence is worse than a plain one that does.

How many screenshots should a finding include?

As many as it takes to prove the claim and no more. For most findings that is two or three: the action, the result, and the proof value or privilege level. Every screenshot gets a caption.

Should findings include severity scores?

Include a severity and a one-sentence justification. CVSS can help standardise the discussion, but it should not replace judgement: an authenticated issue on an internet-facing payroll system may deserve faster treatment than an unauthenticated one on an isolated lab segment.

Is an attack narrative required if I already have individual findings?

For red team style exams and for CPTS, yes, and it is where most of the credit sits. For a host-by-host OSCP report, the per-target chronology is the narrative. For a client, the narrative is usually the most valuable page in the document because it explains exposure in real terms.

What belongs in a remediation section?

The fix for the cause, not the symptom. If Kerberoasting succeeded because a service account had a weak password, “reset the password” is a fraction of the answer: recommend a managed service account, remove unnecessary privileges, review service principal names and monitor for suspicious ticket requests.

Should I use one template for every certification?

One skeleton, adapted per exam. Keep the section order and the finding structure identical everywhere; change the organisation of the findings section (per host, per finding, or narrative-first) to match what that exam grades.