A real retest verifies the security invariant and observed impact on the fixed build. It does not stop when the endpoint returns a different status. The tester should replay the original exploit, inspect persistent and asynchronous effects, try root-cause-based bypasses, test alternate actors and routes, and confirm authorized behaviour still works.

Anchor the retest to the original evidence

  • Finding ID, affected endpoint and operation.
  • Original roles, tenants, objects and workflow state.
  • Raw proof and observed business impact.
  • Expected secure behaviour.
  • Root-cause hypothesis and remediation summary.

If the vendor cannot reconstruct the original conditions, the result is not directly comparable. Resolve missing accounts, data and environment details before the window.

Identify the exact fixed build

Record release, commit, configuration and feature flags. Confirm the remediation is deployed to the tested environment. A successful test against a different branch or disabled feature does not close production exposure.

Replay the original exploit

  1. Recreate the attacker and target state.
  2. Confirm the authorized control case still works.
  3. Send the original unauthorized request or sequence.
  4. Capture the complete response and system outcome.
  5. Verify protected data and state through an authoritative view.

A 401, 403 or 404 is useful only when denial occurs before data disclosure, mutation, queue submission or downstream processing.

Try bypasses derived from root cause

  • Alternate methods, content types and API versions.
  • Bulk, nested and indirect operations.
  • Same-role peers, lower roles and cross-tenant actors.
  • Case, encoding, identifier and sequence variations.
  • Stale sessions, refreshed tokens and changed account state.
  • Web, mobile, webhook and background paths.

A blacklist patch may block the published payload while preserving the underlying weakness. Variants should challenge the corrected control without expanding into an unplanned full assessment.

Inspect side effects beyond the response

Check database state, object ownership, audit events, notifications, files, queues and downstream jobs. For time-delayed processing, wait for the defined outcome or inspect controlled operational evidence.

Run positive regression checks

  • Authorized owner can still complete the action.
  • Intended privileged role retains bounded access.
  • Valid tenant workflows continue.
  • Errors do not reveal new sensitive details.
  • Monitoring records the correct principal and outcome.

Verify shared fixes across representative consumers

When middleware, policy or a shared library changed, sample several endpoints and services. Confirm legacy and alternate clients use the new enforcement. State which consumers were tested and which remain outside the retest.

Use accurate final statuses

Resolved

Original and reasonable variant paths no longer cause impact, while legitimate behaviour remains functional.

Partially resolved

The main proof is blocked but a sibling path, actor or state still violates the invariant.

Mitigated

A compensating control reduces exploitability while the underlying defect or dependency remains.

Not retested

Environment, access, data or scope prevented verification. This is not closure.

Require a retest evidence packet

  • Tester, date, environment and fixed version.
  • Accounts, roles, tenants and prepared state.
  • Original replay and observed outcome.
  • Variants and positive checks performed.
  • Final status, limitations and residual risk.

Screenshots of a changed response are insufficient without actor context and state verification. Evidence should let AppSec reproduce the conclusion safely.

Reconcile the retest with engineering records

Match the vendor result to the remediation ticket, deployed release and security register. Preserve the original finding severity, the engineering change, the tested conditions and the final technical status as separate facts. If the tested build is not yet production, assign ownership for confirming deployment rather than implying production risk is closed. Record new variants as linked findings with their own evidence and deadlines so they do not disappear inside a failed retest note.

Detect superficial retesting

  • No reference to fixed build or deployment.
  • Only one request repeated without setup validation.
  • Success claimed solely from a different status code.
  • No bypass or alternate-actor attempts.
  • No positive regression or side-effect check.
  • Every result marked resolved despite blocked evidence.

Apply the evidence discipline in NIST SP 800-115 to remediation verification: plan the conditions, execute the test, analyze the outcome and report limitations.

The practical decision

Verify the fixed behaviour, not the changed symptom. Replay the original exploit on the named build, challenge the root cause through bounded variants, inspect durable side effects and prove legitimate access still works. Close only with a precise evidence-backed status.

Use WIMD for independent, evidence-led retesting that verifies exploitability, bypass resistance and regression on the fixed build.