Overview
The findings are the heart of the report — the detailed documentation of each vulnerability discovered. This lesson covers writing effective findings.
Learning objectives
- Describe the structure of a well-written finding.
- Explain what each finding must communicate.
- Connect findings to evidence and remediation.
Core concept
A finding documents a single vulnerability in enough detail for the owner to understand, verify, and fix it. A well-structured finding typically includes: a clear title, the severity, a description and root cause, evidence/reproduction steps, the impact, the affected component(s), and remediation guidance. Findings are written for a technical audience (developers, administrators) and must be accurate, clear, and reproducible — each drawing on the evidence collected during the engagement.
How it works
For each vulnerability, the tester writes a finding that ties together the engagement's work: what the vulnerability is (title, description, root cause), how serious it is (severity, from impact × likelihood), proof that it is real (evidence and reproduction steps from the evidence-collection discipline), what it affects and what could happen (impact/affected components), and how to fix it (remediation). Findings are usually ordered by severity (most critical first). Accuracy and clarity are essential — the finding must let developers reproduce and understand the issue precisely, without exaggeration. Good findings are the actionable core that drives remediation.
Practical example
A finding might read: Title — "Broken object-level authorization on invoice endpoint"; Severity — Critical; Description/root cause — the endpoint returns invoices based on the ID without verifying ownership; Evidence/reproduction — steps and redacted request/response showing user A retrieving user B's invoice; Impact — any user can access others' invoices (mass data exposure); Affected component — the invoice API; Remediation — enforce per-object ownership checks. This complete finding lets developers verify and fix the issue precisely.
Cybersecurity relevance
Findings are the actionable substance of the report — where discovered vulnerabilities become fixable items. Their quality (accurate, clear, reproducible, well-evidenced) determines whether developers can efficiently confirm and remediate them. They integrate the whole engagement: methodology (how found), evidence (proof), severity (priority), and remediation (fix). Poorly written findings (vague, unreproducible, exaggerated) waste effort and erode trust; strong findings drive effective remediation. Writing good findings is a core professional skill, combining technical accuracy with clear communication.
Common mistakes
- Vague or unreproducible findings developers cannot verify or fix.
- Missing elements (no severity, evidence, or remediation), leaving findings incomplete.
- Exaggerating beyond the evidence, undermining credibility.
Key takeaways
- A finding documents one vulnerability with title, severity, description/root cause, evidence/reproduction steps, impact, affected components, and remediation.
- Written for a technical audience, findings must be accurate, clear, and reproducible, drawing on collected evidence, and are ordered by severity.
- Findings are the actionable core of the report; their quality determines remediation efficiency and integrates methodology, evidence, severity, and remediation.
Check your understanding
- What elements should a well-written finding include?
- Why must findings be reproducible and accurate rather than vague or exaggerated?