Home / Knowledge hub / Retest
Knowledge hub
Retest
Running the test again to confirm that a reported flaw has really been fixed.
What it means
A retest is a second run of a security test, aimed at the specific flaws found earlier. Its single question is whether each one is really fixed. The tester repeats the original steps against the updated application and records the result. The word retest also covers re-running a stored exploit automatically.
It is not a new test of everything. It checks the fix, and it should also look for the obvious ways a fix gets bypassed, such as the same flaw on a similar endpoint. A good retest records the original request and the new response side by side.
Why it matters
A reported flaw is not a closed flaw. Developers fix the symptom, a change is deployed to the wrong environment, or a patch only covers one route to the problem. Without a retest, the ticket says done and the weakness remains.
A retest also gives you evidence. A customer or auditor asking whether findings were resolved gets a dated result that shows the original exploit now fails. That is stronger than a note in a ticket. It is the last step in remediation and the heart of a closed-loop retest.
How it shows up
You meet it as a follow-up engagement after the fix window, often included in the price of the original test for a limited period, or as an automatic rerun of the original exploit when new code is deployed. The output is a status per finding: fixed, partly fixed or still open.
Mistakes: running a fresh scan and calling it a retest, testing a different environment from the one that was fixed, and closing findings on a developer's say-so. Use the original reproduction steps, test the live build, and keep a retest report with the evidence.
Questions people ask
Retest, answered
Is a retest the same as a rescan?
No. A rescan looks for issues in general. A retest repeats the exact exploit that was reported to see if it still works.
Only the second proves that specific fix.
How soon should we retest?
After the fix is deployed to the environment where the flaw was found. Waiting too long lets other changes blur the result.
Many teams retest in batches after each sprint.
What if the retest fails?
The finding stays open and goes back to the developer with the new result. Often the fix covered one path and missed another.
Record each attempt so the history is clear.
Do I pay for a retest?
Practice varies. Some providers include a retest within a set period, others charge separately.
Ask before you sign, as it affects how you plan fixes.
Can a retest be automated?
Yes, where the exploit is a stored request that can be replayed against the new build. Automation makes it cheap enough to run on every release.
Logic flaws may still need a person to judge the result.
Sources
Where this comes from
Related
Terms that sit next to this one
Closed-loop retest
Re-running the exact exploit after a fix, so the finding closes only on proof.
Fix verification
Proving a fix works by repeating the original exploit against the new code.
Retest report
A short report confirming which earlier findings are now closed and which remain.
Remediation
The actual work of fixing a finding: the change, the review, the release.
Regression
A bug that was fixed and has come back, usually undone by a later change.
Is the exploit really dead?
A fix is proven by re-running the exact exploit against the new code, not by a fresh scan. Ask us to run it on one of your applications.
Or start with a $199 pilot on one application: thirty days, success criteria agreed before day one, credited against the annual if you convert.