A leadership report earns trust by stating its own limits: what was tested, what was observed, what changed since the last run, and which boundaries prevent generalizing any of it to the whole system.
The template is four moves — scope, observation, delta, limit — and every number travels with its context.
What to include
- Use overall risk as a summary of the run and always show the target, scenarios, and date beside it. A score of 72 does not mean that 72% of the real system is vulnerable.
- For an eligible Starter+ run, include the evidence pack and related controls while stating that the mapping organizes review; it does not certify compliance.
- Compare equivalent runs to show resolved findings, new findings, and score changes. If scope changed, disclose that before presenting a trend.
Show overall risk beside the target, scenarios, and date — a score of 72 says nothing about the system, only about that run. Compare equivalent runs to show resolved and new findings, and disclose scope changes before presenting any trend.
Explain without turning a hypothesis into a fact
- Translate `attack_exposure` as exposure observed in the tested scenarios. Do not turn the score into a percentage of responses, users, or real incidents.
- Describe the asset and plausible consequence conditionally. Quantify customer data or revenue at risk only when a separate analysis supports the number.
- Show the before-and-after comparison and name the cases that were replayed. This communicates progress without claiming that every future variation is covered.
Translate attack_exposure as exposure observed in the tested scenarios — never as a percentage of responses or a projection to production. Describe consequences conditionally, quantify business risk only with a separate analysis, and name the cases that were replayed.