How to interpret retest results

Every retest ends with a clear result that automatically updates the vulnerability status, so you always know where each finding stands.

Possible results

• Fixed: the remediation was confirmed and the vulnerability is no longer exploitable.

• Partially fixed: the fix reduces the problem, but does not eliminate it completely.

• Not fixed: the vulnerability is still exploitable.

• Blocked: the environment prevented the retest, for example because the target was not accessible, Strike's IP was not authorized or the credentials were invalid.

Each result comes with evidence explaining what was found.

How results affect the vulnerability

• Fixed moves the vulnerability to Fixed status and marks it as verified by Strike.

• Any other result keeps it in Pending fix. You can request a new retest once you adjust the fix or resolve the environment block.

• The most recent retest always defines the current status.

To see all the statuses of a vulnerability, see Managing the vulnerability lifecycle. If the result is Blocked due to an access issue, see How to authorize Strike's IPs and How to upload credentials for testing.

Retest evidence

Every completed retest includes:

• A written analysis of what was tested and what was observed.

• Attached evidence files you can download.

The same quality standard applies whether the retest was run by the Retest Agent or by a Striker.

Retest history

The vulnerability detail includes a Retest history section with each attempt in chronological order:

• Date and who requested it.

• The result of each retest.

• A preview of the evidence and attachments, which you can expand to the full record.

• If a retest is underway, it appears at the top as in progress.

This gives you auditable traceability from detection to verified fix.