Skip to content

Glossary

What is a retest?

A retest is a targeted follow-up check after a penetration test. The testing team verifies whether the reported vulnerabilities have actually been closed after remediation.

Retests in plain English

You may know the principle from your car’s safety inspection. If the brakes fail, you have them repaired and bring the car back for a re-inspection. The inspector then looks specifically at the brakes – not at the entire vehicle all over again. Only then do you get your inspection sticker. A retest works the same way: it focuses on the findings from the pentest report and checks whether the repair was successful. Retests are sometimes also called follow-up tests or remediation verification.

Why is this necessary? Because well-intentioned fixes are often incomplete. One input field gets secured, while another with the same flaw remains open. An update is installed on one server but not on the second. A filter blocks exactly the example from the report but lets slightly modified attacks through. Only someone who takes another look through an attacker’s eyes will spot such gaps.

How a retest works

  1. Fix the vulnerabilities: Your team or your IT service provider implements the recommendations from the report – ideally in order of urgency, critical findings first.
  2. Communicate the changes: You tell the testing team which findings have been fixed and what exactly was changed.
  3. Recheck in a targeted way: The testing team repeats the original attacks and tries out variations. This shows whether the root cause was eliminated or just a symptom.
  4. Document the results: Each finding receives a new status, such as “fixed,” “partially fixed,” or “still open.”
  5. Use the evidence: With the documented results, you can demonstrate to auditors, customers, or partners that the gaps have been closed.

An important distinction: a retest is not a new penetration test. It checks the known findings within the original testing boundaries, known as the scope. If you have introduced new features or significantly restructured your environment in the meantime, you need a separate test for that.

A practical example

A fictional scenario: A software vendor has its customer portal tested. Among other things, the report identifies a vulnerability that allows signed-in users to retrieve other users’ records. The development team fixes the flaw exactly at the spot listed as an example in the report and marks the finding as fixed.

The retest, however, reveals that the same missing authorization check is also present in other functions, because the root cause lies in a shared component. The finding receives the status “partially fixed,” and the team now implements the fix centrally. Without the retest, the vendor would have considered the vulnerability closed – and would have reported an incorrect status to a major customer who had asked for proof.

Why does this matter for businesses?

Only the retest turns an assumption into certainty. It confirms that your measures actually work and protects you from a false sense of security.

It is also often a prerequisite for credible evidence. The card payment standard PCI DSS 4.0.1, for example, explicitly requires that exploitable vulnerabilities found during penetration testing be corrected and that the corrections be verified by repeated testing. Art. 32 of the GDPR explicitly calls for a process for regularly reviewing the effectiveness of security measures. Auditors and customers, too, frequently ask for proof that findings have been remediated.

What to look out for

  • Clarify in advance: When you commission the test, ask whether a retest is included and what it covers.
  • Fix promptly: The faster you act, the shorter the gaps stay open – and the less your environment changes before the recheck.
  • Root causes, not symptoms: Fix the flaw at its root, not just at the example from the report.
  • Document changes: A brief description for each finding makes the targeted recheck easier.
  • Set priorities: Critical and high findings first. For missing updates, structured patch management helps.
  • Plan a new test: After major changes, a retest is not enough.

How Rootsektor can help

For Rootsektor penetration tests and security assessments, the retest of remediated vulnerabilities is free of charge. We recheck your fixes in a targeted way, and with the test certificate you can demonstrate the test to customers, partners, insurers, and auditors. You can describe your scope on our Pentest Quote page; after scoping, you receive a fixed-price quote within 24 hours (on business days).

Questions about the retest?

We’ll be glad to explain how the report, remediation, and retest fit together at Rootsektor – clearly and with no obligation.

Request a pentest quote