How do you know an exposure is really closed after the fix?

Why is a closed ticket not enough?

Fixes fail in ordinary ways. A patch is applied to one server in a pool and not the others. A configuration change is reverted by the next deployment. A WAF rule is added in monitoring mode. In each case the ticket closes and the exposure stays.

What is a retest?

A retest repeats the test that found the exposure after the fix is reported. If the test fails to reproduce the exposure, the fix is confirmed. CyCognito describes a retest after each fix as part of its remediation workflow. IONIX lists instant re-validation of remediated items on its homepage.

What is regression testing?

Regression testing keeps testing over time, so an exposure that returns is caught. Hadrian describes automatic regression testing after fixes. watchTowr describes re-testing the hour a new threat emerges, which is related but aimed at new threats rather than at your own fixes.

Where do compensating controls fit?

If you put a WAF rule in front of an exposure instead of fixing it, retest too. The question changes from whether the vulnerability is gone to whether the rule blocks exploitation. Record it as mitigated, not fixed, so the real fix stays on the list.

How do you measure it?

Mean time to remediate (MTTR) is the usual measure, from finding to fix. Measure it to the confirmed retest, not to the closed ticket, or the number will flatter you. Several vendors state MTTR reductions for their products; treat those as vendor claims and measure your own.

What should you ask a vendor?

• Is the retest automatic when a ticket closes, or do we trigger it?
• Do you keep testing after a fix, and how often?
• How do you record a mitigated exposure differently from a fixed one?

What next?

Read Compensating controls in practice and check the retest line in each vendor's notes.