Home / Knowledge hub / Retest report
Knowledge hub
Retest report
A short report confirming which earlier findings are now closed and which remain.
What it means
A retest report is a short follow-up to a penetration test report. It lists each earlier finding and says whether it is now fixed, partly fixed or still open, based on repeating the original steps against the updated system. It adds the date of the retest and the version tested.
It does not look for new flaws, though a careful tester may note anything obvious. The point is to close the loop on the first report. Each earlier finding gets a status and a short piece of evidence, such as the exploit now returning an error where it once returned data.
Why it matters
The first report shows where you were. The retest report shows what you did about it. For a customer or auditor, that is often the more important document, because it demonstrates that findings were fixed rather than filed. A report with twenty findings and no retest leaves the story half told.
It also protects your team. When a developer says a flaw is fixed, the retest report is independent confirmation. It is the written form of fix verification and often backs up an attestation letter that says critical issues were closed. It is a short document, but it carries weight.
How it shows up
A good retest is scheduled soon after fixes are deployed, not months later. Give the tester a build that matches production. The report should list every original finding with an ID that matches the first report, its new status, the evidence and any remaining risk.
Look out for retests that only re-read code or accept a developer's note. Check that each closed item was tested by replaying the original exploit, with variations. Open items should stay on the list with owners and dates. A closed-loop retest makes this a routine step rather than a separate project.
Questions people ask
Retest report, answered
What does a retest report contain?
The list of original findings, each with a new status (fixed, partly fixed or open), the date, the version tested and short evidence.
It references the first report by finding ID.
Does a retest look for new vulnerabilities?
Not as its main aim. It checks earlier findings only, though a tester may note anything new they happen to see.
A new test is a separate piece of work.
How soon after fixing should we retest?
Soon after the fixes are deployed, while the context is fresh. Many teams do it within a few weeks.
Waiting months lets new changes blur the picture. Fixes verified quickly also close the loop for customers waiting on the answer.
Do customers ask for retest reports?
Often, especially for high and critical findings. They want to see that the problems were closed, not merely found.
A retest report answers that directly. It also helps your sales team, since the answer is already on paper.
What if a finding is only partly fixed?
List it as partly fixed with a note on what still works and what the remaining risk is. Keep it on the open list with an owner and a date.
Do not mark it closed to tidy the report.
Related
Terms that sit next to this one
Retest
Running the test again to confirm that a reported flaw has really been fixed.
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.
Penetration test report
The document that lists what was found, how, how bad it is and how to fix it.
Attestation letter
A short signed statement that a test was done, for customers or auditors.
Which findings are really closed?
We re-run the exact exploit against the new code, so each closed finding in the retest has proof behind it, not a fresh scan. 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.