Verify a security fix and keep a useful record

01Define what success should look like

Before changing a service, write down the condition that would demonstrate completion. For a DNS policy, that may be the intended published value plus successful mail tests. For a software issue, it may include a vendor-confirmed fixed package and a suitable retest. Choose evidence that answers the original question.

02Implementation checklist

1. Save the original finding, target, timestamp, scope and supporting observation. Record the responsible owner and planned change.
2. Confirm that the change reached the relevant service or instances. Allow for documented propagation, caching or deployment behaviour before interpreting the next result.
3. Repeat the relevant check against the same asset and context. If the scanner offers a targeted remediation check, understand which finding it retests and whether broader coverage is also needed.
4. Check that the retest completed successfully. Verify any required authentication, target resolution and available coverage. A timeout, blocked request or provider error leaves uncertainty.
5. Compare the evidence, not just the overall score. Investigate changed redirects, hostnames or environments that could explain a different result.
6. Save the change reference, test date, outcome and remaining limitations. Mark a finding resolved only when the available evidence supports that conclusion.

03Separate closure from wider assurance

A targeted retest can establish that one observed issue no longer appears under the tested conditions. It does not establish that unrelated findings were assessed or that the service will remain unchanged. Use clear states such as confirmed fixed, not reproduced, provider-confirmed or unable to verify, and choose the next review based on service changes and risk.