Reporting, Remediation Guidance, and Professional Communication
Reporting, Remediation Guidance, and Professional Communication tests whether you can turn technical work into a clear, actionable document. CWEE expects findings that a developer can reproduce and a manager can prioritize without reading raw payloads first.
Structure the report
Lead with an executive summary: what was tested, the business impact, and the overall risk. For each finding, include title, severity, affected asset, prerequisites, reproduction steps, evidence, impact, and remediation. Use CVSS as a supporting score, not a substitute for explaining exploitability. Separate confirmed findings from observations and mark assumptions. Give remediation that addresses root cause: parameterized queries, server-side authorization checks, allowlists, output encoding, and secret rotation. Include retest guidance.
Worked example
An IDOR returns another tenant's invoices. The report does not say "change the ID." It states that GET /api/invoices/{id} lacks object-level authorization, shows requests from two controlled accounts, explains tenant data exposure, and recommends binding the query to the authenticated tenant plus a regression test. Severity reflects confidentiality impact and ease of exploitation.
Traps
Screenshots without requests are hard to reproduce. CVSS scores without narrative hide real impact. Recommending only a WAF or input blacklist misses root cause. Mixing multiple issues into one finding obscures prioritization. Overstating impact or using real customer data damages credibility. Clear, calm language and precise evidence earn more than dramatic claims.