What is Re-Testing?

Then comes the question every security team eventually asks:

"Are we actually fixed?"

That question is exactly why re-testing exists.

A study by Netlas found that around 15.5% of security patches are unreliable in some way. Around 8.05% were incomplete, 4.15% were completely incorrect, and the remaining patches had other failure issues.

In simple terms, many vulnerabilities that organizations believe are fixed are still exploitable in some form.

Most clients do not realise this. They see a Jira ticket marked Closed and assume the risk is gone.

Re-testing is the phase where security teams verify whether the remediation actually fixed the vulnerability or simply blocked the exact payload used in the original report.

The Dangerous Illusion of "Fixed"

Many organizations assume remediation is complete once the original exploit stops working.

But real-world security does not work like that.

For example, a login page may block this SQL injection payload:

' OR '1'='1

' OR '1'='1

But the same application may still be vulnerable to:

' OR 1=1--

' OR 1=1--

The first payload failing only proves that one specific input was blocked. It does not prove the application is secure.

This is where re-testing becomes critical.

Re-testing is not simply repeating a penetration test. It is a verification exercise.

The main objective is very specific: Did the remediation remove the root cause of the vulnerability?

That difference matters more than many clients realise.

A Real World Pattern Security Teams See Constantly

Imagine an e-commerce company that failed a penetration test because its login form was vulnerable to SQL injection.

The original payload used was:

' OR '1'='1

' OR '1'='1

The developer reviews the report and quickly adds a denylist rule to block that exact string.

The next day, the Jira ticket is marked as resolved.

From the development team's perspective, the issue is fixed.

But during the re-test, the tester tries a slightly different payload:

' OR 1=1--

' OR 1=1--

The application successfully logs the tester in.

What changed?

The payload changed. The vulnerability did not.

The real problem unsafe SQL query construction still existed.

This is one of the most common issues found during commercial re-testing engagements. Developers often block the symptom attackers used instead of fixing the actual root cause.

Re-Testing vs Reassessment

One of the biggest misunderstandings in security engagements is treating re-testing and full reassessment as the same thing.

They are completely different.

Re-Testing

• Focuses only on findings from the original report
• Uses the same attack paths and proof-of-concept techniques
• Verifies whether remediation worked
• Produces an updated findings report or addendum

Full Reassessment

• Treats the environment as a new target
• Reviews the full attack surface again
• Includes new infrastructure, code, and attack paths
• Produces a completely new penetration test report

This distinction matters because organizations often rebuild applications, migrate to cloud environments, or redesign authentication systems — and then request a "re-test."

At that point, the environment is no longer the same.

That is not remediation verification anymore.

That is a fresh security assessment.

The Most Important Skill in Re-Testing

The tools remain familiar:

• Burp Suite
• Repeater
• HTTP History
• Version verification
• Manual payload testing

But the mindset changes completely.

Penetration testing is about discovery.

Re-testing is about verification.

You are no longer asking: "Can I exploit this?"

You are asking: "Did the fix actually remove the weakness?"

A good re-tester never stops after the original payload fails.

They test:

• Payload variations
• Encoding tricks
• Alternative injection syntax
• Adjacent functionality
• Behavioral differences

Because real attackers will do the same.

What Makes a Re-Test Report Credible

A professional re-test report is not a victory document.

It is evidence.

Every finding should have a clear status:

• Pass
• Fail
• Partial Remediation
• Risk Accepted

And every conclusion must be supported with proof:

• HTTP requests and responses
• Screenshots
• Version verification
• Testing notes
• Timeline documentation

The best re-test reports are simple, precise, and verifiable.

No assumptions. No unnecessary drama. Just technical evidence.

Final Thoughts

Re-testing is often underestimated because it looks smaller than the original penetration test.

In reality, it is one of the most important phases of the security lifecycle.

A blocked payload can create false confidence. A proper re-test removes that false confidence.

Sometimes the most valuable finding in a security engagement is not discovering a new vulnerability.

It is proving that the old vulnerability never really went away.