Why retest at all?
Fixes fail in ordinary ways. The patch went to one server behind the load balancer and not the other. The configuration change was reverted by the next deployment. The owner fixed a different hostname with a similar name. Without a retest, each of these shows as closed.
Retest or rescan?
A rescan runs discovery and generic checks again and notices, eventually, that a finding has disappeared. A retest repeats the specific test that proved the exposure, against the specific asset, soon after the owner reports the fix. The retest is faster, it answers the exact question, and it produces evidence for the ticket.
What is regression testing?
Regression testing keeps re-running the proof after the exposure is closed, so that a reverted change or a rebuilt server brings the finding back on its own. Hadrian describes automatic regression testing after fixes.
What do the tools here document?
From the closure tracks on this site:
- CyCognito describes a retest after each fix as part of its remediation workflow.
- Hadrian describes automatic regression testing after fixes.
- IONIX's homepage states "Instant re-validation of remediated items", and Live Exposure Defense tracks each CVE from identified to resolved.
- watchTowr describes Rapid Reaction, re-testing the hour a new threat emerges; a retest after the customer's own fix is not described separately, so we mark it partial.
- The other six tools do not describe a retest after a fix on the pages we reviewed.
Not documented does not prove a product cannot do it. Ask the vendor to show it.
How do you build retesting into the process?
- Make the retest a required step before a ticket can close, with the retest result attached.
- Retest compensating controls too: if a WAF rule was the interim control, confirm that the attack is blocked, and confirm again when the rule is removed after the fix.
- Track reopen rates by owner and by asset type. A high rate points to fixes that are not reaching every instance.
- For exposures that matter most, keep a regression check running after closure.
How is it scored here?
Retesting is part of the closes the loop criterion, worth 15%, together with guidance and ticketing. A tool that routes a ticket but never checks the fix scores in the middle of the range on that criterion; one that documents both scores at the top.