The Report Is the Product
You got domain admin in two hours, then spent three days writing. The three days are what the client paid for.
What you will learn
- -Explain why the written report, not the exploitation, is the paid deliverable
- -Collect evidence during the test instead of reconstructing it afterward
- -Budget engagement time so the report gets the hours it needs
You popped admin before lunch on day one. , DCSync, the whole path fell over in about two hours. It felt incredible. Then you spent the next three days writing it up, and that felt like a chore. Here is the part that stings: the never watched you DA. They were not in your terminal. The only thing they ever see is the PDF you hand over at the end, and that PDF is the entire product they bought.
The engagement is not the hack. The engagement is a document that tells an organization where they are exposed and what to do about it. Everything you did in the is raw material. The report is the manufactured good.
Think about who actually opens the file. The sysadmin who has to fix the finding, and has never met you. The CISO who signs off on the remediation budget. An auditor who files it in a folder. A developer six months from now who inherits the ticket. Not one of them saw your screen. If the writing does not carry the finding to them cleanly, the finding may as well not exist.
This is why a modest set of findings written clearly beats a spectacular compromise written badly. A client who gets a report they can act on renews. A client who gets a wall of unstructured tool output, no matter how deep you went, quietly finds another firm next year. The report is your reputation in printed form.
Collect evidence as you go, never after
The single habit that separates people who dread report day from people who coast through it: capture proof while you work, not when you sit down to write.
$asciinema rec dc-compromise.cast$scrot -s ~/engagement/evidence/dcsync-$(date +%s).png$tee -a ~/engagement/notes.mdReconstructing a finding three days later means rerunning the to re-screenshot it, and half the time the environment has drifted or the client already patched it. Now you are writing from memory, which is where invented request numbers and vague reproduction steps come from. Capture the request, the response, the screenshot, and the exact at the moment it lands.
Budget the writing like real work
Plan for report writing to eat 30 to 40 percent of the engagement. A five-day test is not five days of hacking, it is roughly three days of testing and two days of writing and review. Teams that zero days for writing ship rushed reports and burn the last night before delivery. Put the writing days in the statement of work so nobody, including you, pretends they do not exist.
A pentest report is a map of exactly how to break into a you were authorized to test. Treat it like the loaded document it is. Deliver it encrypted, not as a plain email attachment. Store it under the retention and destruction terms in your contract, and never keep client evidence on your box past the engagement. The that let you find these holes does not extend to leaving a how-to guide lying around.
A client scopes a 5-day web app assessment and expects a full report at the end. You know reporting takes roughly a third of the effort. Roughly how many days should you actually spend hands-on testing, and why does under-budgeting writing hurt the client more than you?
Reserve close to two days for writing, evidence , and review, leaving about three for testing. Under-budgeting writing means the client gets findings they cannot reproduce or act on, so the value they paid for, an actionable report, is exactly what gets cut when time runs out.