Remediation Verification & Retest: Closing the Loop

Prerequisites

• STE-K010: Evidence Documentation
• STE-K011: The Evaluation Report

Why This Lesson Matters

A finding that is documented but never fixed is a liability. A finding that is "fixed" but the fix is not verified is even worse — the organisation believes the risk is resolved when it is not. Remediation verification closes the loop: you re-run the test case, confirm the control now passes, and formally close the finding with evidence. Without this step, the evaluation is incomplete.

1. The Retest Lifecycle

Finding identified → Finding reported → Client remediates → Evaluator retests
                                                                   ↓
                                                    Pass → Finding closed
                                                    Fail → Finding remains open
                                                           → Root cause of re-failure documented
                                                           → Remediation timeline revised

The retest is not a new evaluation. It tests only the controls that previously failed. It does not discover new findings (those belong to a new engagement scope).

2. Retest Test Cases

Each failed finding has one or more associated test cases. For a retest, re-run exactly those test cases:

Original finding: F007 — Vertical Privilege Escalation
Original test case: TC-AC01-007
Original evidence: EX-031 to EX-034

Retest test case: TC-AC01-007-RT (RT = retest)
  Same procedure as TC-AC01-007 exactly
  → Authenticate as VIEWER-001
  → POST /api/users/update-role with role: admin
  Expected (now fixed): HTTP 403 Forbidden

Retest evidence:
  EX-071: HTTP request (same as EX-031 but with new timestamp)
  EX-072: HTTP 403 response confirming the fix

Result: PASS — finding F007 closed.

3. Partial Fixes and Re-Failures

Partial fix: The developer fixed one aspect but the vulnerability remains exploitable via a different path.

Example: F007 was a role parameter in the request body.
Developer fix: validate role in the /api/users/update-role endpoint.

Retest:
  TC-AC01-007-RT: Role escalation via update-role → now returns 403 (PASS)
  TC-AC01-008-RT: Role escalation via PUT /api/users/{id} (different endpoint, same field)
    → returns 200 (FAIL)

Documentation:
  "F007 partially remediated. The original attack vector (POST /api/users/update-role)
   is now blocked. However, the same vulnerability exists at PUT /api/users/{id}
   which was not included in the original test scope.

   Recommendation: extend the fix to all user modification endpoints.
   Finding F007 remains OPEN. New variant documented as F007-B."

4. Regression Testing

Fixing one vulnerability can sometimes introduce another. Retest scope should include basic regression checks on affected components:

After fixing SQL injection in ProductController:
  Retest TC-IN01-003 (original SQLi) → PASS
  Also test:
    TC-IN01-003-REG-01: Legitimate product search still works (positive test)
    TC-IN01-003-REG-02: Special characters in search no longer cause errors
    TC-IN01-003-REG-03: Product results are accurate and complete

If the fix broke legitimate search functionality → regression finding.

5. Finding Status Lifecycle

Status transitions:
  OPEN → Under remediation (client started fix)
  Under remediation → Remediated (client reports fix complete)
  Remediated → CLOSED (evaluator verified fix with evidence)
  Remediated → OPEN (evaluator retested; fix is insufficient)
  OPEN → ACCEPTED RISK (client formally accepts the risk; sign-off required)
  OPEN → DEFERRED (scheduled for future remediation; new target date agreed)

Accepted Risk: If a client cannot or will not fix a finding, they can formally accept the risk. This requires written sign-off from an authorised executive. The evaluator documents the acceptance in the report but bears no liability for the residual risk.

6. The Retest Report

A retest produces a brief supplemental report:

RETEST REPORT — STE-2026-0001-RT1
Original report: STE-2026-0001 (June 22, 2026)
Retest date: July 8, 2026
Scope: F001 through F005 (all Critical findings)

| Finding | Original result | Retest result | Notes |
|---|---|---|---|
| F001 | FAIL | PASS | Unauthenticated API access blocked |
| F002 | FAIL | PASS | MFA enforced for admin accounts |
| F003 | FAIL | FAIL | Role update still possible via PUT /api/users/{id} |
| F004 | FAIL | PASS | SQL injection patched in ProductController |
| F005 | FAIL | PASS | File upload restricted to allowed extensions |

Summary:
  4 of 5 Critical findings resolved. F003 remains open with a partial fix.
  Variant F003-B identified at a different endpoint.
  Recommendation: fix F003-B within 7 days. Schedule RT2 upon completion.

7. Common Mistakes

Mistake 1: Closing a finding based on the developer's word. "We fixed it" requires evidence. Run the test case. Capture the 403 response. Document the result.

Mistake 2: Not testing for partial fixes. If the original finding was about one endpoint, the fix may only cover that endpoint. Always consider whether the same vulnerability pattern exists elsewhere in the application.

Mistake 3: Retesting without recording the timestamp. Retest evidence must have a different (later) timestamp than the original finding evidence. Without timestamps, it is impossible to prove the fix was applied before the retest.

8. Practice Exercises

1. Write a retest test case for finding F004 (SQL injection in ProductController). The test must use the same procedure as the original but expect a different (fixed) outcome.

2. You retest F007 (role escalation). The POST endpoint now returns 403. However, you discover the PUT /api/users/{id} endpoint has the same flaw. How do you classify the finding status and what do you document?

3. A client formally accepts the risk of F009 (missing security headers) because their CDN does not support custom headers. Write the formal risk acceptance entry for the report.

9. Lab

Assessment mode: quiz

You are given an original report with 5 findings and a developer's remediation notes. Design the retest test cases, then interpret provided retest results and determine: which findings to close, which remain open, and what the retest report summary should say.

10. Framework Alignment

11. Further Reading

• OWASP DefectDojo — https://defectdojo.com — Open-source finding lifecycle management tool
• NIST SP 800-53A — Section 4.3: Assessment result reuse and continuous monitoring
• Jira/ServiceNow security finding workflows — Most enterprises manage finding lifecycle in these tools; understanding the flow is operational knowledge

["Write a retest test case for a described original finding that uses identical procedure to the original but defines a different expected result (the fix)", "Classify a finding as closed, partially remediated, or new variant based on provided retest results and document each classification with specific evidence justification", "Produce a retest report summary table for five findings showing original result, retest result, and status change notes, and write a three-sentence summary paragraph"]

Prerequisites → Why this matters → Retest lifecycle diagram → Retest test cases (original vs RT version) → Partial fixes and re-failures (worked example) → Regression testing → Finding status lifecycle → Retest report format → Common mistakes → Practice exercises → Quiz lab → Framework alignment → Further reading