Writing the Report that Wins Management and Technical Buy-In
Domain 3 tests the deliverable that decides whether the engagement had any value: a report that an executive can act on and an engineer can reproduce. One document, two audiences, no overlap between them.
Structure that satisfies both readers
An executive summary leads: business risk in plain language, the two or three themes that matter, quantified exposure (records at risk, systems affected, regulatory clauses such as GDPR Article 32 or PCI DSS 6.5.1), the remediation roadmap with owners and target dates, and a clear statement of overall posture. The technical body follows: scope, methodology and references, timeline, an findings table, then one entry per finding containing title, affected asset, CVSS vector, evidence (raw request and response, command output, timestamps), reproduction steps, business impact, and specific remediation. Appendices hold tool versions, accounts used, and the retest plan.
Writing rules that survive review
Evidence must be redacted for credentials, PII and session tokens, yet remain reproducible - a screenshot without the request that produced it is weak evidence. Never paste raw scanner output as a finding; verify it manually and quote only the confirming excerpt. Name remediation concretely: not 'upgrade the application', but 'upgrade framework X to version Y, then re-run payload Z to confirm'. Separate verified exploitation from theoretical exposure in the finding title itself. Put every finding through peer review for consistent naming, severity and scoring, and send a draft for factual-accuracy review before the final PDF.
Worked example
A confirmed SQL injection carries a CVSS 9.8 base score, but no customer data was extracted. The finding is still rated Critical, and the executive summary frames it as: unauthenticated database read access on the customer portal, an estimated 240,000 user records in scope, a 72-hour breach notification obligation if exploited, and a 14-day remediation target with a retest at day 21. The technical entry shows the injected request, the returned schema name, and the parameterised-query fix.
Traps that cost marks
- Mixing remediation jargon into the executive summary or business framing into the finding body.
- Dumping a scanner XML export as the appendix and calling it evidence.
- Stating a finding as patched or unpatched without a date stamp on the observation.
- No retest criteria, so the client cannot prove the fix worked.
- Omitting the methodology section, which makes every result unauditable.