A passed retest should prove more than a patched endpoint

Patch validation and control validation are different

Patch validation repeats the reported proof of concept. Control validation asks whether the security rule now holds across every relevant route and state.

Both checks matter. Replaying the original request provides a clear closure signal, while related-path testing shows whether the fix addressed the underlying design rather than one visible symptom.

What a defensible retest covers

The exact scope depends on the finding, but a useful retest records the build tested, identities used, original evidence and expected secure behavior.

• The original exploit with the same prerequisites and payload
• Adjacent endpoints, object types and supported HTTP methods
• Other roles, tenants and lifecycle states governed by the same rule
• Regression behavior to confirm legitimate users still complete the workflow
• Logging or alerting improvements included in the remediation plan

Closure evidence should remain reproducible

A closure note should identify what changed, what was tested and why the result demonstrates risk reduction. Screenshots alone are weak evidence without the request context, affected version and observed response.

If a related path remains vulnerable, the finding is not fully closed. Record the partial improvement, explain the remaining exposure and agree on the next verification point rather than issuing an ambiguous pass.