8 min read

Intermediate
Template

Retest Report Template

Document remediation verification results after clients fix reported vulnerabilities. Confirms fixes are effective and no regressions occurred.

When to Use

After clients report they've remediated findings, perform targeted retesting to verify fixes are effective. This template documents those verification results. 
# REMEDIATION VERIFICATION REPORT

**Client:** [Company Name]
**Original Assessment Date:** [Date]
**Retest Date:** [Date]
**Report Date:** [Date]

---

## EXECUTIVE SUMMARY

This report documents the results of remediation verification testing performed 
on [X] findings from the original penetration test conducted on [Original Date].

### Retest Results Summary

| Status | Count | Percentage |
|--------|-------|------------|
| ✅ Remediated | X | XX% |
| ⚠️ Partially Remediated | X | XX% |
| ❌ Not Remediated | X | XX% |
| 🆕 New Issues Found | X | - |
| **Total Retested** | **X** | **100%** |

### Overall Assessment
[1-2 sentences on overall remediation effectiveness]

---

## SCOPE OF RETEST

### Findings Included in Retest
| Original ID | Finding | Original Severity |
|-------------|---------|------------------|
| VLN-001 | SQL Injection in Login | Critical |
| VLN-002 | Missing CSRF Protection | High |
| VLN-003 | Weak Password Policy | Medium |

### Findings Not Retested
| Original ID | Finding | Reason |
|-------------|---------|--------|
| VLN-004 | Informational Finding | Client accepted risk |

---

## DETAILED RETEST RESULTS

---

### VLN-001: SQL Injection in Login

| Attribute | Value |
|-----------|-------|
| **Original Severity** | Critical |
| **Retest Status** | ✅ Remediated |
| **Tested On** | [Date] |

#### Original Issue
SQL injection vulnerability in the username parameter of the login form.

#### Remediation Implemented
Client implemented parameterized queries and added input validation.

#### Verification Testing
**Test Performed:**
```
POST /login
username: admin'--
password: test
```

**Result:**
- Application now returns "Invalid credentials" error
- No SQL error messages exposed
- Unable to bypass authentication

#### Evidence
[Screenshot showing failed injection attempt]

#### Conclusion
✅ **Remediated** - The SQL injection vulnerability has been successfully fixed.

---

### VLN-002: Missing CSRF Protection

| Attribute | Value |
|-----------|-------|
| **Original Severity** | High |
| **Retest Status** | ⚠️ Partially Remediated |
| **Tested On** | [Date] |

#### Original Issue
No CSRF tokens on state-changing operations.

#### Remediation Implemented
Client added CSRF tokens to password change and email update forms.

#### Verification Testing
**Tested Endpoints:**
- [x] /account/change-password - CSRF token present and validated
- [x] /account/update-email - CSRF token present and validated
- [ ] /account/delete - CSRF token missing
- [ ] /api/transfer - CSRF token missing

#### Evidence
[Screenshot showing CSRF token in protected forms]
[Screenshot showing missing protection on other forms]

#### Conclusion
⚠️ **Partially Remediated** - CSRF protection added to some forms but not all 
state-changing operations. Recommend extending protection to all endpoints.

---

### VLN-003: Weak Password Policy

| Attribute | Value |
|-----------|-------|
| **Original Severity** | Medium |
| **Retest Status** | ❌ Not Remediated |
| **Tested On** | [Date] |

#### Original Issue
Password policy allowed weak passwords (minimum 6 characters, no complexity).

#### Client Response
Client stated fix was deployed on [Date].

#### Verification Testing
**Test Performed:**
Attempted to set password to: "123456"

**Result:**
Password was accepted without error.

#### Evidence
[Screenshot showing weak password accepted]

#### Conclusion
❌ **Not Remediated** - Weak passwords are still accepted. Fix does not appear 
to be deployed or is not functioning correctly.

---

## NEW ISSUES IDENTIFIED

During retesting, the following new issues were identified:

### NEW-001: Verbose Error Messages

| Attribute | Value |
|-----------|-------|
| **Severity** | Low |
| **Affected Asset** | /api/login |

#### Description
While testing the SQL injection fix, verbose database error messages were 
observed when malformed input is provided.

#### Evidence
```
Error: PDOException: SQLSTATE[42000]: Syntax error in query...
```

#### Recommendation
Implement generic error messages for production environment.

---

## RECOMMENDATIONS

### Immediate Actions Required
1. Complete remediation of VLN-002 (CSRF) on remaining endpoints
2. Verify deployment of VLN-003 (Password Policy) fix
3. Address NEW-001 (Error Messages)

### Process Improvements
- Implement pre-deployment security testing
- Create security regression test suite
- Establish fix verification process before marking issues resolved

---

## APPENDIX: RETEST CHECKLIST

| Step | Completed |
|------|-----------|
| Reviewed original findings | ✓ |
| Confirmed scope with client | ✓ |
| Tested in same environment | ✓ |
| Used same tools/techniques | ✓ |
| Documented all test cases | ✓ |
| Captured evidence for all findings | ✓ |
| Tested for regressions | ✓ |
| Checked for bypass techniques | ✓ |

---

**END OF REPORT**

Status Definitions

Remediated

Vulnerability is fully fixed. Original attack vector no longer works. No bypass techniques successful.

Partially Remediated

Fix is incomplete. Some attack vectors blocked but others remain. Or fix can be bypassed with modifications.

Not Remediated

No effective fix implemented. Original vulnerability still exploitable as documented in initial report.

New Issue

New vulnerability discovered during retesting. May be introduced by the fix or previously missed.

Evidence to Attach

A retest report asserts that an attack no longer works. Each assertion needs its own attempt, recorded, or it is only the client fix claim restated.

Original reproduction: The attack exactly as the first report described it, replayed before anything else, so a change in behaviour is attributable to the fix rather than to a different test.

Failed attempt output: The response, error or blocked action after the fix, captured in full rather than paraphrased.

Environment parity: Same build, or a stated and justified difference; same account role; same network position; same tool versions.

Deployment proof: A version identifier or change reference for the release the client says fixed it, where they can supply one.

Unfixed endpoints: For a partial fix, the endpoint list with each protected and unprotected case marked, since that list is the remaining work.

Bypass attempts: Encoding variants, alternate content types, parameter pollution and casing tried before the fix was called effective.

Likely False Positives

Remediation verdicts are the easiest thing in a report to overstate, because the client wants them and the evidence is a single attempt.

  • Blocked payload read as fixed: A WAF rejecting the exact original string while a variant still succeeds is a partial fix, not remediation.
  • Remediated on client statement: A verdict has to come from a reproduction attempt, not from the release note or a screenshot of a diff.
  • Tested against the wrong environment: Staging with the fix and production without it produces a verdict that does not hold for the live system.
  • Different account or role: A fix that only works for the tested role may simply not have exercised the privilege level where the weakness lived.
  • Partial filed as remediated: Unprotected state-changing endpoints alongside protected ones make the finding partial, whatever the fix summary claims.
  • New issue folded into the original: A weakness introduced by the fix needs its own ID so it can be tracked, assigned and closed.
  • Regression not recorded: A fix that removes the vulnerability by breaking the feature is not clean remediation and should say so.

Retest Checklist

Before retesting

  • ☐ Original findings and their evidence reviewed
  • ☐ Scope, environment and window agreed with the client in writing
  • ☐ Fix claims and their release identifiers collected
  • ☐ Test accounts at the same privilege level arranged

During retesting

  • ☐ Original attack replayed verbatim before any variant
  • ☐ Bypass variants attempted for every payload the fix blocked
  • ☐ State-changing endpoints enumerated rather than sampled
  • ☐ Authenticated and unauthenticated behaviour recorded separately where it differs

After retesting

  • ☐ Each finding carries one verdict from the status definitions
  • ☐ New issues raised with their own identifiers
  • ☐ Evidence attached for both the blocked and the still-working case
  • ☐ Regression noted where the fix changed functionality

Report

  • ☐ Findings excluded from the retest listed with the reason, including risk acceptance
  • ☐ Retest window and tester named
  • ☐ Open items carry a route to another retest
  • ☐ Counts in the summary table equal the verdicts in the detail

Fixing the Artefact

Verdict wording

  • • Use the defined status terms instead of "fixed" or "resolved"
  • • Split a partial result into the endpoints that are protected and those that are not
  • • Leave a status field empty until the attempt has been made

Evidence

  • • Attach the failed attempt output rather than a description of it
  • • Keep the original attack text identical to the first report so the difference is meaningful
  • • Record the environment difference wherever parity could not be achieved

Scope and handling

  • • List findings excluded from the retest with the reason, including accepted risk
  • • State the retest window, the tester and the build tested
  • • Re-check the client name and any copied text from the previous report

Related Topics

Technical Report

Full technical report template

Finding Template

Individual finding template

Executive Summary

Executive summary template