A useful security finding lets another person repeat the observation. Name the relevant version and setup, give the shortest steps that trigger the behavior, include the evidence, and explain what the result means. If the reader has to guess which parts were measured and which were inferred, the report is unfinished.
A compact report usually needs:
- Conditions: version, configuration, prerequisites, and authorized scope.
- Steps: the minimum sequence needed to reproduce the behavior.
- Evidence: exact response, state change, or redacted excerpt.
- Expected behavior: the rule or contract the system should follow.
- Impact: what a user or attacker can do, under the stated conditions.
- Limits: what was not tested and what could change the result.
- Fix and check: a remediation direction and a regression test.
Include enough evidence to prove the point, then stop. A packet capture may contain credentials and unrelated traffic. Keep the original under the engagement’s retention rules; share the smallest redacted excerpt that makes the behavior clear. A screenshot can show an error message, but it rarely explains the request, state, or sequence that produced it.
Severity belongs after impact. A score can summarize a finding, but it cannot replace reachability, privileges, user interaction, and real consequence. If the impact is uncertain, say what test would resolve it.
NIST SP 800-115 covers technical testing from planning through mitigation. OWASP’s Web Security Testing Guide organizes application tests. Use either as a framework, then follow the actual scope and reporting requirements for the work.
The strongest report is easy to hand off. The next person can see what happened, run the test, understand the boundary, and check whether the fix holds. That is more persuasive than a dramatic title or a high severity label.