Glossary

Retest

Re-running the original reproduction steps for a specific finding after it has been fixed, to verify whether it is still exploitable.

  • Remediation verification

The retest is the piece that turns a pentest report into proof that the security programme works. Without it you have a list of problems and a promise to fix them.

To be useful it has to happen finding by finding, not in bulk. A document saying “14 of 17 have been remediated” traces nothing. Each retest needs the original finding identifier, the date it was run, the same reproduction steps and an explicit verdict: fixed, mitigated, risk accepted, or still present.

The two middle verdicts carry the most information and are the worst documented. If it is “mitigated”, say what the measure mitigates and what remains exposed. If it is “accepted”, name who accepted it, the date, and how long the acceptance lasts. A retest that only distinguishes fixed from not fixed loses exactly what an auditor wants to read.

Want to see it on your own data?

The proof of concept stands up an environment with your real scope. No cost, no commitment to continue.

Start a proof of concept