Understanding Your Findings and the Retest

• The affected asset: the URL, endpoint, host, build or account where the issue sits.
• Evidence: a proof of concept showing the issue was exploited in a controlled way, so a reviewer can see it was reproduced by hand rather than inferred from a scanner signature. False positives are discarded before the report.
• A CVSS v4.0 grade for the technical severity.
• A business-impact rating: what the issue exposes in your context, which data, which accounts, and how it chains with other findings.
• Remediation guidance your engineers can act on.

The executive summary puts the same findings in terms your board and your auditor can use.

1. 01

   Order by business impact

   Start with what the report ranks highest, not with what is quickest to close.

2. 02

   Fix the cause, not the example

   A proof of concept shows one path. Fix the control that failed, such as the missing server-side authorisation check, so the other paths close too.

3. 03

   Talk to the engineer who found it

   The engineer who found a flaw explains the fix to your developer. If you think a finding is wrong or its impact overstated, raise it with that engineer and bring your evidence, such as a compensating control or a reason the path cannot be reached.

4. 04

   Record what you changed

   Note the fix, where it was deployed and when. It makes the retest faster and gives your auditor a trail.

For a secure code review, each finding also carries the file and line, a fix written as a code diff and a suggested regression test, so the fix stays fixed.