> For the complete documentation index, see [llms.txt](https://dualguard.gitbook.io/dualguard/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://dualguard.gitbook.io/dualguard/security-reviews/security-reviews-for-protocol-teams/mitigation-review.md).

# Mitigation Review

Mitigation Review is the follow-up review that happens after findings are acknowledged and fixes are implemented.

Its purpose is simple: confirm that the reported issue is actually fixed, that the patch matches the intended behavior, and that the remediation does not create a new vulnerability.

### When mitigation review happens

Mitigation review starts after:

1. Findings are validated and finalized
2. Your team decides which findings will be fixed
3. Fixes are implemented and linked to the relevant findings

This is the last verification step before release readiness.

For the full review sequence, see [How Security Review Contests Work](/dualguard/security-reviews/security-reviews-for-protocol-teams/how-security-review-contests-work.md).

### What your team needs to provide

To keep verification fast and reliable, provide:

* The updated commit, branch, or tagged release candidate
* PRs or commits linked to each finding being fixed
* Brief notes for any implementation choice that changes intended behavior

Clear mapping matters. It helps reviewers verify each issue directly instead of reverse-engineering the remediation.

### What DualGuard checks

During mitigation review, DualGuard verifies three things:

* The original issue is no longer reachable
* The fix behaves as intended
* The patch does not introduce new risk nearby

This is not a full re-run of the original contest over the entire codebase. It is a targeted review of the remediation and its local security impact.

### What counts as a good remediation package

The best mitigation reviews happen when fixes are easy to trace.

That usually means:

* One PR or commit path per finding when practical
* Clear commit history and reproducible test setup
* Notes for tradeoffs, accepted risks, or partial fixes

If multiple findings are fixed in one large refactor, verification becomes slower and the chance of needing follow-up review increases.

{% hint style="warning" %}
Large remediation changes can expand the attack surface. If the patch set is broad enough, DualGuard may recommend a short follow-up review instead of treating it as routine fix verification.
{% endhint %}

### What you receive

At the end of mitigation review, your team receives confirmation of the verification outcome for the fixed findings.

That typically includes:

* Which fixes were successfully verified
* Which items need more work or clarification
* Whether the patch set introduced any new concerns

This gives your team a cleaner basis for launch or upgrade sign-off.

### What mitigation review does not do

Mitigation review is important, but its scope is narrower than the original review.

It does not:

* Re-audit unrelated parts of the system
* Automatically cover new features added after scope freeze
* Replace a follow-up contest when the changes are large

If remediation changes core logic, permissions, accounting, or integrations in a major way, DualGuard may recommend another focused review window.

### Planning guidance

Mitigation review is usually faster than the original contest, but timing depends on the size of the patch set and the number of validated findings.

To keep this phase short:

* Finalize issue disposition quickly
* Submit fixes in a clean and traceable format
* Avoid bundling unrelated changes into the remediation branch

For broader timing expectations after a contest, see [Protocol Involvement Post-Audit](/dualguard/security-reviews/protocol-teams/protocol-involvement-post-audit.md) and [Security Review Contest Timeline](/dualguard/security-reviews/protocol-teams/security-review-contest-timeline.md).