The executive summary is written for someone who will never read a request header. It should state what was tested, what the most serious realistic outcome was, and whether the overall posture improved or worsened since the last test — in plain language, in under a page.
Each finding needs six things: a title, a severity with the scoring rationale, the affected component, evidence, exact reproduction steps, and a fix specific enough to implement. "Implement proper access control" is not remediation guidance; "add the ownership check in OrderPolicy::view and cover it with the test case below" is.
Two sections are frequently missing and worth demanding: a coverage statement saying what was in scope and what was deliberately not tested, and a retest record. Without the first, a clean report is meaningless; without the second, you have no evidence the issues were ever fixed.
Report sections and who reads them
| Section | Audience | Why it matters |
|---|---|---|
| Executive summary | Founders, board, customers | The version that gets forwarded |
| Scope and methodology | Auditors, buyers | Proves what was and was not covered |
| Findings with evidence | Engineers | The work list |
| Severity and risk rating | Product owners | Prioritisation |
| Remediation guidance | Engineers | Turns findings into commits |
| Retest record | Auditors, customers | Evidence issues were closed |
In short
- Ask for a sample report before signing anything.
- CVSS scores should include the vector string and the reasoning.
- An attestation letter is the artefact your customers actually want.
- Reports should be handed over with a walkthrough call, not emailed cold.