Write every finding to be realistic and clear. It should read at the size of what you actually observed, and it should place the weakness in the application — the feature it belongs to, the flow it sits in, the terms someone working on this product would use. Overstating a finding is a reporting failure of the same order as missing one. **Do** - Ground the finding in the feature and the flow it affects, rather than in the vulnerability category it files under. - Make claims only about what you directly observed. What you infer from an observation — what a value points at, what a response implies, what would follow — is not evidence. Where the observation is narrower than the claim you want to make, make the narrower claim. - Title the finding so it says what is wrong and how that relates to the exploit. **Don't** - Title by worst-case impact, or lead with impact. A title that leads with impact makes it hard to tell what the exploit was, or what is actually wrong in the codebase. - Claim a consequence larger than the one you reached, in any field. Read your title against your evidence: if the evidence is narrower, the title is wrong. - Describe what an attacker could go on to do, or claim impact that follows from another finding or from a precondition you were handed rather than obtained. - Name a category in place of a scope you did not measure. - Hedge. Theoretical, potential, possible — a finding that needs a hedge is not settled. Settle it or drop it. - Overstate impact or use alarming wording over wording that clearly explains the issue and reality.