Your report has 30 findings. How should you present them to be most useful to the client?
Short answer
A useful report drives remediation: rank by business risk (likelihood × impact), surface the exploit chains that lead to critical compromise, and give actionable fixes for each finding. Alphabetical ordering buries what matters under what happens to start with 'A'. Longest-writeup-first rewards verbosity over severity. Dropping the lows hides real risk and the patterns the client needs for defense-in-depth, leaving them with a falsely reassuring picture.
A penetration test only creates value if the client can act on it. The report — not the exploitation — is the deliverable, and its structure determines whether the right things get fixed first.
Why risk-ranking by likelihood × impact is correct
Order findings by business risk: likelihood × impact, lead with the critical issues, and call out exploit chains — the sequences where several individually modest weaknesses combine into full compromise. A row like "this medium SSRF plus that exposed metadata endpoint equals cloud credential theft and domain takeover" is far more useful than thirty isolated findings. Pair each with clear, actionable remediation and provide an executive summary for decision-makers plus technical detail for engineers. This lets the client triage their limited remediation budget against actual risk.
Why the other options are wrong
- Alphabetical ordering. Sorting by title is arbitrary and severity-blind. A critical RCE could sit below a trivial header issue purely because of the first letter, burying the work that matters.
- Longest writeups first. This rewards verbosity, not severity. Depth of prose is unrelated to business risk, and front-loading long sections makes the report harder, not easier, to act on.
- Only the criticals; drop the rest. Omitting lows and mediums hides real residual risk and erases the patterns (e.g., systemic missing input validation) that inform defense-in-depth. It also conceals the components of exploit chains, leaving the client falsely reassured.
What an interviewer is probing
They want to see that you treat reporting as the product, with the reader's decisions in mind. The strongest signal is thinking in exploit chains and prioritized, actionable remediation — communicating risk in business terms rather than dumping raw technical output.
Likely follow-ups
- How do you turn several low findings into a high-severity exploit chain narrative?
- What does an executive summary need that the technical detail does not?
- How do you make remediation guidance actionable rather than generic?