The technical work is done. What goes into a report that the client will actually act on?
Short answer
A good report serves two audiences: an executive summary that frames business risk for leadership, and detailed, reproducible findings with evidence, accurate risk ratings, and prioritized remediation for the technical team. The report — not the exploit — is the deliverable.
Clients don't pay for shells; they pay for a document that tells them what's wrong, how bad it is, and what to do. A brilliant compromise that's poorly written is wasted work — and a clear report on modest findings can be enormously valuable. This is why reporting is treated as a full phase.
Two audiences, one document
- Executive summary: for leadership. No jargon. It states overall risk posture, the handful of issues that matter most, business impact (data exposure, downtime, compliance), and whether the objectives were met. A CISO should grasp the situation in two pages.
- Technical findings: for the engineers who fix things. Each finding is self-contained.
What every finding needs
- A clear title and description of the issue and root cause.
- Accurate severity — risk-based, not a raw CVSS base score copy-pasted. Context matters: an internal-only SQLi behind MFA differs from the same bug on the public login.
- Reproduction steps and evidence — enough detail (requests, payloads, screenshots) that the client can reproduce it and later verify the fix. Sensitive data is redacted.
- Business impact — what an attacker actually achieves, not "TLS 1.0 is enabled."
- Specific, prioritized remediation — concrete guidance ("parameterize this query," "rotate this credential"), ordered so the client knows what to fix first.
Professional touches
- Report critical findings immediately during the engagement, not buried in a PDF weeks later.
- Include scope, methodology, and timeline so results are interpreted correctly.
- Be honest about coverage and limitations — what you didn't test is part of the risk picture.
- Offer a retest to confirm fixes.
What interviewers look for
That you see the report as the product, can write for both executives and engineers, rate risk in context rather than parroting CVSS, make findings reproducible, and tie everything to actionable, prioritized remediation — plus the maturity to escalate criticals in real time.
Likely follow-ups
- How do you rate severity so it reflects real risk, not just CVSS base scores?
- How would you report a serious finding mid-engagement instead of waiting for the report?
- What makes a finding 'reproducible,' and why does that matter to the client?