Pentest report — what makes it professional

The engagement is not finished when the last exploit works. It is finished when a director can repeat your conclusion in a board meeting, a developer can fix the issue without calling you back, and an auditor can retrace every piece of evidence. The report is the deliverable. Everything else is raw material.

A list of flaws is not a report

A Nessus export, a sqlmap dump, or a folder of screenshots is not something you hand over. Without per-finding remediation, without replayable evidence, without a ranking you can defend, you have an inventory. The client paid for a decision.

What you will be able to do after this lesson

• Name the six parts of a report and what each one stops people from misunderstanding.
• Write for three audiences without mixing their languages.
• Fill the finding template the same way from one flaw to the next.
• Call a P1 to P4 priority from business impact, not from the CVSS score alone.
• Spot the wording that scares, that lies, or that cannot be reproduced.

---

1. The report is the product

Across ten modules you have collected: a target sheet, ports, CVE tickets, a SQL injection, a stolen token, a BloodHound path. None of those objects is readable by the person who signs the remediation check.

The report always performs the same three conversions:

Raw material	What the report turns it into	What that stops
Tool output	Dated, copy-pasteable evidence	“We did not understand what you ran.”
CVSS score	A P1–P4 business priority	“Everything is critical, so nothing is.”
A working exploit	A testable fix	“Thanks, we will look at that next sprint.”

A pentester who “does not like writing” delivers unfinished work. The client is not buying your Kali. They are buying a sentence they can defend in front of their board: here is the risk, here is the deadline, here is the cost of doing nothing.

---

2. Three audiences, three readings

The same PDF circulates. It is not read the same way.

Leadership reads two pages. It wants the conclusion up front, the number of P1s, the three risks that threaten revenue or compliance, and what must be decided this week. It does not want UNION SELECT, or CWE, or the name of sqlmap.

The technical team opens the findings. It wants the exact request, the observed response, the file to change, the test that proves the issue is closed. It ignores the summary if the write-ups are vague.

Audit (internal, end client, insurer, ISO 27001) checks that you stayed inside the RoE, that the method has a name, that every piece of evidence is dated, that the references exist. It reads the appendices nobody else opens.

Write the summary last

The executive summary is written after the findings have been ranked. Otherwise you tell the story in the order of discovery — interesting for you, unreadable for a director. Conclusion first, narrative after.

The writing rule: a piece of information appears only at the level that can use it. The MD5 hash of admin@juice-sh.op goes in the finding and in an appendix. In the summary you write: the store’s administration account can be recovered from the Internet, with no authentication.

---

3. The reference structure — six parts, not seven

You keep exactly this order. Readability comes from repetition, from one engagement to the next, from one provider to the next.

3.1. Executive summary — one to two pages

It stands on its own. A reader who stops at page 2 must be able to decide.

Required content:

1. Context in three lines — who commissioned the work, which target, which dates.
2. Conclusion up front — insufficient posture, acceptable with reservations, or under control. A single adjective, justified by the P1s.
3. Counts — how many P1, P2, P3, P4.
4. Three business risks — jargon-free sentences, each tied to a numbered finding.
5. This week’s decisions — rotate secrets, close an endpoint, take a forgotten admin offline.

What never appears there: a tool list, a CVSS table, a screenshot, a threat (“a Russian attacker could…”). You document what you did, not a movie plot.

3.2. Scope and methodology

This is the contract reread after the fact. It protects the client (you did not touch this) and you (nobody can claim you forgot that).

Heading	What goes in it
In-scope	Domains, IPs, applications, accounts provided.
Out of scope	Third-party SaaS, subsidiaries, DoS, phishing if not authorized.
RoE	Windows, limited extraction, ban on modifying data.
Method	OWASP Testing Guide, PTES, or the client’s internal guide — one name.
Tools	A short list, with the role of each. Not a full Kali toolkit dump.
Limits	What you did not have the time or the right to test.

A written limit is better than a “forgotten” flaw the client will discover six months later. “Authenticated APIs were not tested: no account was provided” is a professional sentence.

3.3. Overview

Two objects, not a novel.

Heatmap — findings crossed by theme and by priority. The eye lands on the dark cells.

Theme	P1	P2	P3	P4
Application	2	1	1	0
Identity	0	1	1	0
Network	0	0	1	1
Cloud	0	0	0	1

Posture indicator — one sentence, not a marketing score. “Insufficient posture: two P1s are exploitable from the Internet with no account.”

One attack paragraph ties the findings together: from public research to the administrator session, then to the orders. This is where the path seen in module 10 (lateral movement) or module 7 (OWASP) becomes a business story. Not in the summary.

3.4. Detailed findings

One finding per vulnerability and per surface. Two SQL injections on two endpoints = two write-ups. The same injection seen by sqlmap and by Burp = one write-up, two pieces of evidence.

The template is in section 4. You do not invent it. You fill it in.

3.5. Prioritized recommendations

The findings say what to fix here. This chapter says in what order we clean up the system.

You group by theme, not by finding number:

• identity (passwords, MFA, service accounts);
• application (injections, access control, session);
• network (exposure, segmentation);
• cloud (roles, secrets, storage).

A structural fix — every SQL query goes through parameterized queries — is worth more than six copy-pasted patches. The 3-, 6-, and 12-month plan is written here; the lab lays it out on the page.

3.6. Appendices

Logs, full requests, dated screenshots, tool exports. The body of the report points to the appendix. It does not copy it.

Naming convention, from the first file:

C01-2026-04-18-recherche-union-select.png
C01-2026-04-18-req-search.txt
ANNEXE-A-nmap-10.10.10.0-24.txt

A screenshot with no date and no finding identifier proves nothing on the day the client says “that was no longer there”.

---

4. The finding template — seven fields, always

Every finding follows exactly the same structure. A technical reader must be able to jump from write-up 2 to write-up 6 without hunting for the evidence.

## C-01 — SQL injection on /api/recherche

- Severity: P1 — one-sentence business justification
- Context: what the target does, in one sentence
- Evidence: request, response, dated screenshot
- Business impact: what an attacker actually obtains
- Remediation: precise action, closure test, effort
- References: CWE, OWASP, client document

4.1. Short title — action + surface

The title is read in a table of contents and in a Jira ticket. It starts with the verb of the defect, not with the tool.

Unreadable	Readable
SQLi sqlmap critical !!!	SQL injection on /api/recherche
Auth problem	Missing access control on GET /api/commandes/{id}
CVE-2017-0144	Remote code execution via SMBv1 on SRV-FICHIERS

No exclamation mark. No “critical” in the title: priority is a separate field.

4.2. Severity — P1 to P4, not the number alone

The course uses four delivery priorities. CVSS informs; it does not decide.

Priority	Indicative deadline	Criterion that counts
P1	24 hours to 7 days	Demonstrated compromise, or sensitive data exposed without authentication.
P2	30 to 90 days	Realistic exploitation, clear impact, heavier prerequisites (account, internal network).
P3	3 to 6 months	Hardening, debt, incomplete attack chain.
P4	Backlog	Informational, exposed version with no exploit, good practice.

You still calculate CVSS 3.1. You write it in the finding, with the vector. You add why you diverge if the business priority differs.

Example already seen in module 7: an unauthenticated SQL injection that yields the administrator hash often scores 7.5 (high confidentiality, no integrity if you only read). That is High, not Critical. It is still a P1: the account that runs the store fell, from the Internet, in one request.

The reverse exists. A CVSS 9.8 on an isolated service, with no data, filtered by a hop you did not cross, can drop to P2 if the RoE stopped you before impact. You write that down. You do not inflate.

4.3. Context — one sentence about the function

“/api/recherche feeds the store’s public catalog, with no session.”

That sentence avoids the following dialogue: the developer thinks you tested the internal admin, the CIO thinks it is the marketing site. Context anchors the surface in the business.

4.4. Evidence — replayable, not decorative

A screenshot illustrates. It is not enough. The minimum evidence is the request that, copied, reproduces the result.

Three accepted forms, in this order of preference:

1. a copy-pasteable curl;
2. a raw HTTP request (Burp);
3. a keyboard walkthrough if the attack is purely graphical.

The observed response sits next to it: HTTP status, useful excerpt, not 200 KB of JSON. If the RoE limits extraction — --stop=3 in module 7 — you recall that in the evidence. It shows you chose not to empty the database.

4.5. Business impact — what changes for the company

Impact is not “loss of confidentiality”. It is a sentence a lawyer or a CIO can quote.

Technical	Impact that stands up
Dump of Users	Reading of customer emails and the administration secret; takeover of the back office.
Stored XSS on a review	Session theft of an administrator who moderates reviews.
DMARC at p=none	A third party sends messages that appear to come from the domain.
Open SMB share	Reading of HR folders from an intern’s workstation.

You stay on what you obtained, not on what an attacker “could do next”. The following chain goes in the overview, not in every write-up.

Law 25, GDPR, PCI-DSS: you name them only if the data touched is subject to them. An administrator hash from a demo store is not a “PCI breach”. Real customer emails are, and the report says so.

4.6. Remediation — one action, one test, one effort

Without a recommendation, the write-up is a denunciation. Remediation has three qualities:

• Precise — parameterized queries on the q parameter, not “secure the application”.
• Testable — the finding’s curl must return an empty list or a 400, no longer a Users row.
• Bounded — effort in person-days, skill (dev, ops, IAM), dependency (production window).

A WAF that blocks UNION SELECT is a compensating control. It is not the fix. You can recommend it while waiting for the patch; you do not sell it as closing the P1.

4.7. References

Type	Example	What it is for
CWE	CWE-89	The developer finds the fix pattern.
OWASP	A03:2021 Injection	The CISO aligns the finding with their program.
CVE	only if there is one	The vendor patch has an identifier.
Client document	“Password policy v3”	You show the gap against their rule.

A homemade injection often has no CVE. Inventing CVE-2024-XXXX is a fault. CWE + OWASP are enough.

---

5. Prioritize: CVSS informs, the business decides

Module 5 already said it: the base score ignores your client. The report is where that sentence becomes a decision.

What you calculate

• CVSS 3.1 vector (AV, AC, PR, UI, S, C, I, A);
• base score;
• optionally the environmental score if the client said confidentiality of this app matters more than its availability.

What you decide

• presence on the Internet or only internally;
• authentication required or not;
• nature of the data (admin account, PII, cloud secrets);
• ease: one curl line or a three-prerequisite chain;
• existence of a public exploit (EPSS, KEV catalog) — useful for a CVE, useless for a handmade SQLi.

Four classic gaps, to write in black and white in the finding:

Situation	Typical CVSS	Delivered priority	Why
Public SQLi, account dump	7.5	P1	Admin + emails, no account.
Theoretical RCE, isolated service	9.8	P2	No demonstrated access to the data.
Reflected XSS on an internal tool	6.1	P3	Prerequisites: account and a victim who clicks.
Server: nginx/1.18.0 banner	5.3	P4	No exploit shown.

Do not scare people to sell

“A criminal group will empty your cash register tonight” is not an impact. It is advertising. You write what the evidence shows. The client decides the budget. If you inflate, the next report — yours or a colleague’s — will no longer be believed.

---

6. What separates an amateur report from one that gets paid

Four criteria, taken from the week’s index. They serve as a mental checklist before you send the PDF.

One remediation per finding. Each write-up closes with an action and a test. Cross-cutting actions live in the recommendations chapter, in addition, not instead.

Reproducible evidence. A third party — a developer, an auditor, you in six months — replays the curl and sees the same class of result. Real secrets are masked (adm***@…, truncated hash in the body, complete in an appendix under NDA).

A defensible ranking. The CIO can present the P1 to leadership without you in the room. If you cannot justify the CVSS gap in one sentence, the priority is wrong.

No implicit threat. We document. We do not sell anxiety. We do not compare the client to “what we usually see at the low bidders”: you are not their competitor.

Three professional habits sit on top of that:

• Stable numbering — C-01 does not change once the draft is frozen. The client’s tickets point to it.
• One voice — not “we found” in one write-up and “the offensive team estimates” in the next.
• Facts in the present of observation, advice in the imperative — the query returns three accounts; parameterize the query.

---

7. The confusions that cost a week of rewriting

• Telling the engagement in chronological order. The client does not need to relive your Tuesday evening. They need to see the worst first.
• Merging two surfaces into one write-up. Unfixable: the ticket will go to the wrong Git repository.
• Pasting a tool export as a finding. sqlmap is wrong. Module 7 recalled that. The write-up cites the tool as secondary evidence, the curl as primary evidence.
• Putting jargon in the summary. You lose leadership at sentence two; they will not read the rest.
• Forgetting the RoE in the PDF. Without a reminder of the windows and the prohibitions, an external reader believes you tested everything.
• Promoting a software version to P2. A version, with no demonstrated exploit, is a P4 or a line in the overview.
• Writing “critical” eleven times. The word empties out. P1, P2, P3, P4 are enough.
• Delivering personal data in the clear in a PDF sent by email. The report must not become the incident. Mask, encrypt the repository, respect the extraction clause.

---

What to remember

A professional report has six parts always in the same order, and findings always in the same template. It speaks to leadership, to technicians, and to audit without mixing their sentences. Priority is defended by business impact; CVSS remains a vector in the write-up, not a verdict. Every finding carries replayable evidence and one testable remediation. Without that, you have a list. The next lesson takes the raw notes of a SQL injection from module 7 and turns them, field by field, into a deliverable write-up.