Reporting
Reporting
This domain tests whether you can turn testing into defensible, actionable evidence. Expect executive summaries, technical findings, risk ratings, reproduction steps, remediation, and data handling.
Core rules
- Write for two audiences: executives need business impact and priorities; engineers need exact reproduction and fixes.
- Every finding needs an asset, description, evidence, impact, likelihood, CVSS vector where used, remediation, and references. Separate observation from inference.
- Record scope, dates, limitations, and testing accounts. State what was not tested.
- Protect sensitive data: redact credentials, tokens, personal data, and customer records; store evidence with access control.
Worked example
A SQL injection is confirmed in a login form. The report title names the asset and issue, not “critical bug.” Evidence includes the request, response, payload, timestamp, and test account. Reasoning: a raw scanner dump cannot be reproduced or prioritized. You assign CVSS using the actual vector and explain business impact: authentication bypass could expose HR records. Remediation is specific: parameterized queries, input validation, least-privilege database account, and regression tests. You add a retest criterion: the payload returns a normal login failure and no database error.
Traps
- Pasting tool output without validation or context.
- Rating severity without likelihood, exposure, or data sensitivity.
- Omitting the exact request, payload, or affected parameter.
- Including live passwords or personal data in the report body.
- Giving vague remediation such as “patch the server.”
- Forgetting scope, dates, limitations, and retest status.