Retest is a state, not an email.

Ask a security team how they verify a fix and you will usually get a description of a calendar reminder. Retest as an event — someone schedules it, someone remembers, someone reschedules it — has a poor success rate and no record.

Verification belongs in the lifecycle

The moment a finding is marked fixed, the system should be able to re-test it without anyone deciding to. Not because the platform is clever, but because a state machine does not forget and a person does.

1. 01Engineer marks the Jira ticket Done; the finding follows to awaiting-retest.
2. 02The retest runs against the same asset and the same authenticated context that produced the original finding.
3. 03Verified: the finding closes, the ticket resolves, evidence attaches to both.
4. 04Not verified: the finding reopens with the new evidence, and the SLA clock restarts — visibly.

The uncomfortable part

A retest that fails is the most valuable data your programme produces, and it is the data most often discarded. Track the reopen rate per finding, per service, per engineer. It is uncomfortable, it is fair, and it is the only honest measure of whether remediation is real.

• Measure retest pass rate, not just fix rate — they differ by a lot.
• Report reopen rate by service. That is where your secure-SDL maturity is visible.
• Never let a finding close without a verification event attached to its history.