Structuring a Report

Hand two reports from two different firms to an experienced client and they will flip to the same pages in the same order without thinking. Executive summary first, scope and rules next, then findings sorted worst to best, appendices at the back. That predictability is a feature. When the structure is standard, a reader who has never seen your work knows exactly where to look, and you never have to explain your layout.

A report is not one document for one audience. It is several documents stapled together, each written for a different person, and the section order reflects who reads how far.

The skeleton that does not change

The title page and metadata sound like filler until an incident happens and someone needs to know which version of which test found the thing. Put a version number and a date on every report, and stamp a classification like "Confidential" on every page footer.

The scope section is where you write down exactly what you were allowed to touch: the IP ranges, the domains, the accounts, the test window, and any carve-outs like "no denial of service against production." This is not bureaucracy. It is the paper trail proving the whole engagement was authorized, and it protects both you and the client if anyone later asks why you were in their systems.

Methodology tells the reader you were systematic, not lucky. Name the framework you worked from: the PTES stages, the OWASP Testing Guide, or the OWASP Web Security Testing Guide for web apps. A reader who sees a recognized methodology trusts that a clean result means you looked, not that you missed.

Findings go worst first, always

Sort findings by severity, never by the order you found them. The Critical that lets an attacker read every customer record goes on top. The informational note about a missing security header goes near the bottom. A remediation team works top down and stops when they run out of sprint, so the ordering decides what actually gets fixed.

Appendices exist so the body stays readable. Nobody reading the Critical finding wants 400 lines of nmap output in the middle of it. Push the raw scans, the full HTTP transcripts, and the exact tool versions to the back, and reference them from the finding. The body tells the story, the appendix proves it.