How penetration test exam reports are graded

Why the report decides it

A practical exam produces two things: a compromised host, and evidence that you compromised it. The grader never sees the host. They see the evidence. So the exam is really asking whether you can demonstrate a compromise to someone who was not there — which is also the actual job, because a client who cannot act on your findings has not been helped.

This reframing is worth internalising early. It changes what you do during the practical, not just after it.

The one standard behind every vendor's rules

Different vendors want different documents — OffSec wants reproducibility, Hack The Box wants a client deliverable, Altered Security wants a legible attack chain. All three reduce to the same test:

Could a competent stranger reproduce this, using only what is on the page?

Everything else — screenshot conventions, severity ratings, executive summaries — is a vendor's particular way of enforcing that.

Evidence that counts

• Commands as run, not as remembered. Paste from the terminal. A command retyped from memory is a command with a typo in it, and a step that does not run is a step that scores nothing.
• Output alongside the command. The command shows intent; the output shows result. A report full of commands with no output proves you typed things.
• Proof files with the host identified. Where a vendor asks for a proof or flag file, the screenshot must tie the file to the machine — contents and IP address in the same frame, taken on the compromised host. A hash on its own could have come from anywhere.
• Modified exploits included in full. If you changed public code, the changed code goes in the report. "Adjusted the offset" is not reproducible.

Write during the exam, not after it

The single highest-value habit: keep a working document open from the first scan, and paste every command, output and screenshot into it as you go, under a heading per host. It costs you a few minutes across the exam and it removes the failure mode that ends the most attempts — realising during the writing window that you are missing a screenshot for a machine you can no longer reach.

Tired-you, at hour twenty, reconstructing hour four from memory, is not a reliable narrator. Do not rely on them.

The failure modes, in order of how often they cost people the exam

1. A proof screenshot missing the host's IP address
2. A gap in the chain — root shown, escalation path not documented
3. Steps that do not reproduce, usually a transcription error
4. Evidence for a host that was never captured and cannot be recaptured
5. Submitted after the window closed
6. Tooling that the exam rules prohibited

Every one of these is avoidable, and none of them is about technical skill.

Structure to start from

Use the vendor's template where one exists. Where none does, this holds up:

1. Executive summary — what was tested, what you found, what it means. Non-technical.
2. Scope and methodology — targets, dates, standard followed, what was excluded.
3. Attack path narrative — how the findings chained into a compromise.
4. Findings — one per issue: title, severity with reasoning, affected hosts, reproduction, impact, remediation.
5. Appendices — full command logs, raw output, supporting evidence.

By vendor

Each vendor's specific requirements, and what they mark hardest:

• Altered Security
• EC-Council
• Hack The Box
• INE
• OffSec
• PortSwigger
• TCM Security
• Zero-Point Security