Blog

A retest after a pentest: why it still matters when "we already fixed it"

A checkbox in the tracker does not close a finding. A retest looks at whether the scenario is gone, not the row in the table.

After the report, development writes "fixed" and everyone exhales. A month later it turns out the storefront form was fixed and the same trick remained in the API. Or it was closed for the customer role and forgotten for the manager. A retest exists for exactly that. It is shorter than the first pass: it looks at confirmed items, it does not start recon again.

What counts as closed

  • The scenario no longer works on the same address and with the same role.
  • The neighboring API method was checked, not only the screen a manager sees.
  • A secret that was exposed was rotated, not "hidden" in another file.
  • The report has a retest date, not a verbal "we shipped it".

Without a retest a pentest becomes a wish list. With it the owner has a basis to say that specific holes are closed, without confusing that with "the site is safe forever". New releases still deserve their own place on the calendar.

A retest is part of a Lexora website pentest. If someone else already wrote the report and the checkboxes have no second pass, we can check only the closed items. For new clients who do not have a report yet, it is wiser to start with the free basic audit and then decide whether a full pentest is needed.

Related Lexora services

Have the fixes already shipped?

We will check whether the scenarios from the report are gone, not only the tracker rows.