Home / Knowledge hub / Closed-loop retest
Knowledge hub
Closed-loop retest
Re-running the exact exploit after a fix, so the finding closes only on proof.
What it means
A closed-loop retest takes the exploit that proved a finding and runs it again after the fix. The finding closes only if the exploit now fails. If it still works, the finding stays open and goes back to the developer with the new result. The loop runs from finding to fix to proof, and then closes.
The loop is closed in the sense that the same evidence that opened the finding is used to shut it. Nothing is closed on a promise or a pull request alone. It treats the original exploit as a test case that the fix has to pass.
Why it matters
Open loops are where risk hides. A team marks a ticket done after a code change, a later scan sees nothing new, and the flaw lives on in a form the scan cannot spot. Re-running the exact exploit removes that gap. The finding is closed because it was tested, not because everyone hoped.
It also saves time on the audit side. The record shows the finding, the exploit, the fix and the passing retest, in order. That is the evidence an auditor wants, and it forms the base of the retest report that goes to customers. It is the practical form of fix verification.
How it shows up
Run it after every fix to a confirmed finding, in an environment that matches production. Keep the original request, the account used and the data. The retest should also try nearby variations, since fixes that block one input often miss a second. Record the date, the build and the result.
Teams get it wrong by retesting only the happy path, running it before the fix is deployed, or letting the developer close the ticket. In a pipeline, a retest can run on schedule or on each build, and a failing result can hold the release through a security gate.
Questions people ask
Closed-loop retest, answered
How is a closed-loop retest different from a regular retest?
A regular retest may check that a fix looks right. A closed-loop retest uses the exact original exploit, so the finding closes only on proof that it now fails.
The tie to the original evidence is what closes the loop.
Is it the same as running another scan?
No. A scan hunts for patterns across the app. A closed-loop retest targets one proven flaw and replays its exact steps, plus close variations.
It answers one question: is this specific flaw gone?
What happens if the retest fails?
The finding stays open, with the new result attached. It returns to the owner, and the clock for the fix stays running.
Nothing is lost, because the evidence shows what still works.
Can it run automatically?
Yes. Once the exploit is recorded, it can be replayed on a schedule or in a CI pipeline, and a failure can block a release.
This also catches regressions months later.
Does it need the original tester?
Not if the exploit is recorded in a replayable form. The request, the account and the steps are enough.
A person should still review the result. The tester's skill then goes into judging new variations, not repeating old steps.
Sources
Where this comes from
Related
Terms that sit next to this one
Fix verification
Proving a fix works by repeating the original exploit against the new code.
Retest
Running the test again to confirm that a reported flaw has really been fixed.
Retest report
A short report confirming which earlier findings are now closed and which remain.
Regression
A bug that was fixed and has come back, usually undone by a later change.
Gating a build
Stopping a release automatically when a security check fails.
Did the fix survive the same exploit?
This is how we close findings: re-running the exact exploit against the new code, not a fresh scan. It can run on a schedule or in CI/CD. Book a pilot on one app.
Or start with a $199 pilot on one application: thirty days, success criteria agreed before day one, credited against the annual if you convert.