Writing the penetration test report

Objective 1.4 in this course covers penetration test reports — CompTIA describes it as creating reports with executive summaries, findings and remediation recommendations. Domain 5 (lessons 40 and 41) covers the attack narrative and remediation advice specifically; this lesson is the document they sit inside.

Why this matters

The report is the product. Lesson 1 made that claim; this lesson is where it becomes practical.

It is also the highest-leverage skill in the domain, because it is the one most candidates neglect. Plenty of people can get a shell. Far fewer can explain to a finance director why it matters, in a page, without either patronising them or hiding behind jargon. The exam tests this with scenario questions about audience and severity, and the job tests it every single engagement.

The lesson

The executive summary a non-technical reader will actually act on

The executive summary is read by people who will never read the rest. Assume one page, assume no jargon, assume the reader is deciding whether to spend money.

It should answer four questions:

1. What did we ask you to do? One or two sentences restating the scope, so the reader knows what this does and does not cover.
2. What did you find, in business terms? Not "17 highs and 34 mediums" — what an attacker could achieve. "A user with no prior access could reach the customer database within a day" is a sentence an executive can act on.
3. How bad is it, relative to what? Compare to their own risk appetite or to their sector, not to an abstract scale.
4. What are the two or three things to do first?

Two failure modes to avoid. The summary that is just counts tells the reader nothing about consequence. The summary that buries the finding — polite, hedged, technically accurate and read as "we're fine" — is worse, because it converts your work into false assurance.

A finding: evidence, impact, reproduction, remediation

Every finding needs the same four parts, in an order the reader can follow:

• Evidence — what you observed, with the artefact that proves it: the request and response, the command and its output, the screenshot. Redacted, but real.
• Impact — what this lets an attacker do to this client. Not the generic CVE description. "Allows arbitrary file read" is a class; "allows any unauthenticated user to read the application's configuration file, which contains the database credentials shown below" is a finding.
• Reproduction — enough for their engineer to see it themselves, because a fix nobody can verify is a fix nobody will trust.
• Remediation — what to do about it, at the level of the cause. Lesson 41 goes into this.

The discipline that makes findings defensible: never report something you have not reproduced. Lesson 18 covers validation; this is where the cost of skipping it lands, in a meeting where an engineer demonstrates that your finding is not real and every other finding becomes suspect.

Severity that survives being challenged

Severity gets argued about, so it needs to be derived rather than felt.

Most reports use CVSS as a base, and CVSS is a starting point, not the answer. The base score describes the vulnerability in the abstract; it knows nothing about this client's exposure, compensating controls, or what the affected system does. A critical-scoring flaw on an isolated test box may be a low risk here; a medium on the host holding the customer database may not be.

So state severity as the base score, plus your adjustment, plus the reason. Writing the reason down is what makes it survive a challenge: "raised to high because this host is internet-facing and holds live cardholder data" is a position you can defend, where an unexplained number is just an opinion.

Be consistent across the report. Two similar findings with different severities and no stated reason will be the first thing a sceptical reader notices.

Screenshots and command output that prove what you claim

Evidence is what turns an assertion into a finding. It has to actually prove the claim:

• Show the whole thing. A screenshot cropped to the interesting line invites the question of what was outside the crop. Include the command, the target, and enough context to see it is the system you say it is.
• Timestamp it, so it ties to your activity log and the client can correlate with their own telemetry.
• Redact values, not structure. Mask the password; show that a password was returned, and where from.
• Prefer text to images for command output — it is searchable, copyable and much smaller. Screenshots for interfaces, text for terminals.
• Never include a working exploit as evidence. Prove the condition; do not ship a weapon with the report.

The attachments, and what must never be in them

Reports routinely carry appendices: full scan output, host inventories, discovered credentials, extracted data.

The rule from lesson 4 applies with force here, because the appendix is where people stop paying attention. The report is a document that will be emailed, printed, stored on a shared drive and possibly sent to the client's customers. Anything in it is now in all of those places.

So: no unredacted credentials, no personal data beyond the minimum that proves a finding, no full database extracts, no private keys, no session tokens. If the client needs the raw data, deliver it separately, encrypted, on an agreed schedule, and say in the report that you have done so.

And the finished report itself is sensitive: it is a map of how to compromise the client, written by an expert. Encrypt it, agree who receives it, and agree how long you keep your copy.

What to take into the exam

• Executive summary: scope, consequence in business terms, relative severity, top actions. No counts as a substitute for meaning.
• Findings are evidence, impact, reproduction, remediation — every time.
• CVSS base plus a stated adjustment; the stated reason is what defends it.
• Evidence proves the claim and redacts the value.
• The report is itself sensitive material, and appendices are where data leaks.