Skip to content

Acknowledging a Finding

Acknowledging a finding means your team has reviewed it and taken a documented position. It does not mean the vulnerability is fixed. It means you are aware of it and have made a deliberate decision about how to handle it.

Acknowledgment is the foundation of your compliance audit trail. Every acknowledged finding is logged with a timestamp, the person who made the decision, the reason, and any notes. This is the evidence auditors review when evaluating your vulnerability management program.

How to Acknowledge

  1. Open the finding (click the CVE in your environment findings list).
  2. Click Acknowledge.
  3. Select a reason (required).
  4. Add notes (optional but recommended for audit trail).
  5. Click Confirm.

Acknowledgment Reasons

Each reason serves a specific purpose and creates a different audit trail record:

Not Applicable

This CVE does not actually affect your specific configuration. Use when:

  • The affected feature or component is disabled on your device.
  • The affected component is not present in your configuration.
  • The CVE affects a different variant, firmware branch, or hardware revision than what you have.
  • Your specific version is confirmed not affected after checking the vendor advisory.

Example: CVE-2025-12345 affects Siemens S7-1500 with web server enabled. Your S7-1500 has the web server disabled. Not applicable.

Compensating Control

You cannot patch the vulnerability but you have mitigated the risk through other means. When you select this reason, you are prompted to describe the control you applied. This description is logged in the audit trail.

Common compensating controls for OT environments:

  • Network isolation (moved the device to a dedicated VLAN with strict ACLs).
  • Protocol disabling (turned off the vulnerable service or protocol on the device).
  • Enhanced monitoring (added IDS/IPS rules for the CVE's exploitation signature).
  • Application whitelisting (restricted executables on engineering workstations).
  • Physical access controls (restricted physical access to the vulnerable device).

Example: "Isolated PLC-A-Line3 to VLAN 10.3.x. ACL permits only HMI at 10.3.0.5 on port 102. Added Snort signature SID:2025-32433 for exploitation detection."

Accepted Risk

You are aware of the vulnerability and have decided to accept the risk without patching or implementing compensating controls. Use this reason with caution and document the business justification.

Appropriate for:

  • Low-severity findings on isolated, non-critical systems.
  • Findings where the cost of remediation significantly outweighs the risk.
  • Temporary risk acceptance with a scheduled review date.

Example: "Low-severity information disclosure on historian backup server. Server is isolated, read-only, and scheduled for decommission in Q3 2026. Risk accepted per OT manager approval."

False Match

BreachSpider matched this CVE to your asset, but the match is incorrect. The CVE does not affect your product. Use this when:

  • The matching engine associated the CVE with the wrong product.
  • The vendor name matched but the specific product is not affected.
  • The version range check was incorrect.

Submitting a false_match acknowledgment provides feedback that helps improve the matching engine over time.

Escalated

You have escalated this finding to a vendor, MSSP, internal team, or other responsible party. The finding remains in your active list until the escalation is resolved.

When selecting escalated, consider also creating a ticket to track the escalation to completion.

After Acknowledging

Once a finding is acknowledged:

  • It moves to the Acknowledged view. Toggle the filter at the top of the findings list to see acknowledged findings.
  • It is logged in the audit log. The entry includes: timestamp (UTC), actor (email and name), action (FINDING_ACKNOWLEDGED), CVE ID, asset name, reason, and notes.
  • It no longer appears in the active finding count on your dashboard. Your exposure metrics reflect only unreviewed findings.
  • It still appears in compliance reports. Acknowledged findings are included in NERC CIP evidence packages and other compliance reports as evidence of your documented vulnerability management process.

Restoring an Acknowledged Finding

If circumstances change -- a patch is released, a compensating control is removed, a new exploit appears -- you can restore an acknowledged finding to active status:

  1. Navigate to the Acknowledged view in your findings list.
  2. Find the finding.
  3. Click Restore.
  4. The finding returns to your active queue with its original BCS score.
  5. The restoration is logged in the audit log as FINDING_RESTORED.

Acknowledge via API

curl -X POST \
  -H "Authorization: Bearer bs_live_..." \
  -H "Content-Type: application/json" \
  -d '{
    "reason": "compensating_control",
    "notes": "Isolated to VLAN 10.3.x. ACL blocks all inbound except HMI."
  }' \
  "https://breachspider.com/api/v1/environments/5/matches/42/acknowledge"