Dismissing and Restoring Findings

BreachSpider provides two ways to handle reviewed findings: acknowledgment and dismissal. Understanding the difference ensures you use the right action for each situation and maintain a clean audit trail.

Acknowledge vs Dismiss

In practice:

• Use Acknowledge for almost everything. It creates the detailed audit trail that auditors expect. Even findings you do not plan to act on should be acknowledged with a reason (not_applicable, accepted_risk, false_match).

• Use Dismiss only for confirmed false matches that you want completely removed from your working view. Dismissed findings do not appear in the default findings list or in compliance reports.

• Use Patched status (through the ticket workflow) for findings that have been remediated by applying a vendor patch. This is the ideal resolution.

How to Dismiss a Finding

1. Open the finding in your environment findings list.
2. Click the Dismiss button (X icon).
3. Confirm the dismissal in the dialog.
4. The finding moves to the Dismissed view.

Dismissal is immediate. The finding is removed from your active findings list, your dashboard metrics, and your Strike List.

How to Restore a Dismissed Finding

If you need to bring a dismissed finding back into active status:

1. Navigate to your environment's findings list.
2. Toggle the view to Dismissed (filter toggle at the top of the findings list).
3. Find the dismissed finding.
4. Click Restore.
5. The finding returns to your active queue with its original BCS score.
6. The restoration is logged in the audit log as FINDING_RESTORED.

When to Dismiss

Confirmed false matches after investigation: You verified that the CVE does not affect your specific device configuration, and you do not need the finding in your compliance evidence. Note: in most cases, acknowledging with reason: false_match or not_applicable is a better choice because it creates a richer audit trail.

Duplicate findings: If the same CVE-to-asset match appears twice due to a data issue, dismiss the duplicate.

Test data cleanup: If you added test assets and generated test findings, dismiss them when cleaning up.

When Not to Dismiss

Do not dismiss findings you have not fully evaluated. A dismissed finding is out of sight. If you are not sure whether it is relevant, acknowledge it with a note instead.

Do not dismiss findings to reduce your dashboard metrics. The dashboard is supposed to reflect your real exposure. Dismissing findings to make the numbers look better defeats the purpose and creates audit risk.

Do not dismiss patched findings. Use the ticket workflow instead: create a ticket, close it with reason: patched, then acknowledge the finding. This creates the full remediation chain (CVE found > ticket opened > patch applied > ticket closed > finding acknowledged) that auditors want to see.

Compliance Implications

Dismissed findings still appear in the audit log. The log records who dismissed the finding and when. If an auditor asks why a critical finding was dismissed rather than acknowledged, the audit log provides the answer.

For regulated environments (NERC CIP, IEC 62443), acknowledged findings are the preferred documentation method because they include a reason and notes. Dismissal is a weaker form of documentation. Use acknowledgment as your default and reserve dismissal for edge cases.

Restoration Scenarios

Common reasons to restore a dismissed or acknowledged finding:

• New exploit published: A previously low-risk CVE now has a public exploit. Restore it and re-evaluate.
• Compensating control removed: You acknowledged with a compensating control, but that control was later changed or removed. Restore and re-evaluate.
• Vendor patch released: A previously unpatchable CVE now has a patch. Restore, apply the patch, create a ticket, and close the loop.
• Audit preparation: You need to demonstrate that you reviewed all findings, including ones previously dismissed. Restore, acknowledge with documentation, then proceed.