Writing findings that get fixed

The goal: the issue gets fixed

A finding is successful when the client fixes the problem. That sounds obvious, but many reports fail at it: they are vague, overstate severity, or bury the fix. Write every finding asking "will the person reading this know exactly what to do?"

Qualities of a strong finding

• Specific: name the exact URL, parameter, or file; not "the site has XSS" but "the comment field on /post reflects input without encoding".
• Reproducible: give the steps so the developer can see it themselves. If they cannot reproduce it, they cannot confirm the fix.
• Honest severity: use CVSS fairly; do not inflate a low issue to look impressive, or hide a serious one.
• Fix-first: the remediation is the most important line. Make it concrete and referenced.
• Plain language: avoid jargon where a simple word works; define any term you must use.

Avoid false positives and overstatement

Before writing a finding, confirm it is real (not a scanner false positive) and that the severity matches the real risk in this client's context. Overstating severity erodes trust; the next time you say "critical", they may not believe you. Honesty is a professional asset.

Re-testing

Many engagements include a re-test: after the client fixes the issues, you check that the fixes actually work and that they did not introduce new problems. Because your findings were specific and reproducible, re-testing is straightforward. This closes the loop and gives the client confidence.