Reporting, Remediation and Communication
Reporting, Remediation and Communication
This domain tests the deliverable: clear findings, defensible risk ratings, actionable remediation, and audience-appropriate communication. A technically correct test with a poor report loses marks.
Core rules and concepts
- Report structure: executive summary, scope and methodology, timeline, findings, evidence, risk rating, remediation, and appendices.
- Findings need title, severity, affected asset, description, reproduction steps, evidence, business impact, and fix. Avoid raw tool output without interpretation.
- Risk rating can use CVSS as a base, but context (exposure, data sensitivity, compensating controls) must adjust the final priority.
- Executive summary: business language, top risks, overall posture, no jargon or exploit steps.
- Remediation should be specific and testable: parameterized queries, least privilege, patching, configuration change, detection.
- Retesting confirms fixes and checks for regressions. Handle report data as confidential; encrypt and limit distribution.
Worked example
A SQL injection finding is rated High: public endpoint, customer data, no WAF. Reproduction shows the request, a time delay, and a minimal proof. Impact explains account and data exposure. Remediation names parameterized queries and a database least-privilege account, with a retest step. The executive summary says 'a public login form can be manipulated to access customer records' and avoids payload strings. If the same issue were on an internal, non-sensitive, already-segmented system, the priority could drop with the context documented.
Traps that cost marks
- Pasting scanner output as the finding.
- Rating severity without business context or compensating controls.
- Missing reproduction steps or evidence.
- Giving vague remediation such as 'fix the vulnerability.'
- Naming and shaming individuals or exposing sensitive data in the report.
- Skipping retest verification.