Practice
Writing severity so triage stays calm
Audit packs fail when every issue sounds catastrophic. Engineers stop trusting the ranking; product leaders stop reading past page two. We treat severity language as part of the service, not decoration.
Separate impact from surprise
A surprising UI quirk that only appears on a rare device may be low impact. A boring, predictable form error that blocks checkout for everyone is high impact. Write the impact first, then the surprise.
Name the audience who feels it
“Users who deny location cannot complete store locator” is clearer than “location handling is suboptimal.” Security findings benefit from the same concreteness: who is exposed, under what condition, and what is already mitigated.
Offer a next step, not a lecture
Each finding ends with a suggested action: change copy, add a fallback, remove a debug flag, update a screenshot. If we cannot suggest a next step, we revisit whether the finding belongs in the pack.
Allow accepted risk
Some medium issues will ship. Recording that decision in the walkthrough notes protects the team later and keeps the auditor’s role honest. Our job is clarity before launch, not perfection theatre.