Skip to content

Open Close Reopen Workflow

Every BreachSpider ticket follows a three-state lifecycle: Open, Closed, and Reopened. Each state transition is logged in the audit log with a timestamp, actor, and reason, creating the chain of custody that auditors need to verify your remediation process.

State: OPEN

A ticket enters the Open state when it is created, either manually or by an auto-ticket rule.

What happens on creation:

  • The ticket appears in the environment's Tickets tab with state: Open.
  • The assignee is notified via the configured destination (email, Jira issue, ServiceNow incident).
  • The audit log records TICKET_CREATED with the full ticket details: CVE ID, asset, assignee, destination, priority.
  • The linked finding remains in the active findings list.

While a ticket is open:

  • The assignee works on the remediation: applying a patch, implementing a compensating control, coordinating with a vendor, or completing whatever action the ticket requires.
  • The ticket can be viewed and tracked in the Tickets tab.
  • No automatic state changes occur. The ticket stays open until someone explicitly closes it.

State: CLOSED

A ticket moves to the Closed state when remediation is complete or when the finding has been formally dispositioned.

How to close a ticket:

  1. Navigate to your environment's Tickets tab.
  2. Find the open ticket.
  3. Click Close.
  4. Select a close reason (required):
Close Reason When to Use
patched The vendor patch was applied successfully. The vulnerability is remediated.
risk_accepted The team reviewed the finding and formally accepted the risk. Document the justification.
false_positive The finding was determined to be incorrect. The CVE does not affect this asset.
vendor_notified The vendor has been notified and a fix is expected. The ticket is closed pending vendor action.

  1. Add resolution notes (optional but recommended): Document what was done, when, and by whom. Examples: "Applied firmware V3.0.1 during maintenance window 2026-06-05 0200-0400. Verified by process engineer." or "Risk accepted by OT Manager per policy OT-RM-003. Device scheduled for replacement Q4 2026."

  2. Click Confirm Close.

After closing:

  • The ticket appears in the Closed view (filter by state in the Tickets tab).
  • The audit log records TICKET_CLOSED with the close reason, resolution notes, actor, and timestamp.
  • The linked finding is NOT automatically acknowledged. Go to the finding and acknowledge it separately to complete the audit trail.

Why closing does not auto-acknowledge: The ticket tracks the remediation work. The acknowledgment documents your evaluated position on the vulnerability. These are intentionally separate actions. You might close a ticket (patch applied) but want to verify the patch was effective before acknowledging the finding. Or you might close a ticket (vendor_notified) while leaving the finding active pending the vendor's response.

State: REOPENED

A closed ticket can be reopened if circumstances change and the remediation needs attention again.

When to reopen:

  • A patch that was applied failed or was rolled back.
  • A new exploit was published for a CVE that was previously assessed as low risk.
  • A compensating control was removed or degraded.
  • The vendor's expected fix did not materialize.
  • An auditor flagged the closure as insufficient.

How to reopen:

  1. Navigate to the Tickets tab.
  2. Filter to Closed tickets.
  3. Find the ticket.
  4. Click Reopen.
  5. Add a reason for reopening (required): "Firmware update V3.0.1 caused process instability. Rolled back to V2.9.4. Vulnerability is re-exposed."
  6. Click Confirm Reopen.

After reopening:

  • The ticket returns to Open state.
  • The audit log records TICKET_REOPENED with the reason, actor, and timestamp.
  • The linked finding is flagged for re-review if it was previously acknowledged.

The Complete Audit Chain

For a single finding, the ideal audit trail looks like:

1. FINDING matched     (automatic -- matching engine)
2. TICKET_CREATED      (manual or auto-rule)
3. TICKET_CLOSED       (reason: patched, notes: "Applied V3.0.1")
4. FINDING_ACKNOWLEDGED (reason: patched)

This four-step chain proves: the vulnerability was identified, a remediation action was initiated, the remediation was completed, and the finding was formally dispositioned. This is the evidence chain NERC CIP auditors, IEC 62443 assessors, and SOC 2 reviewers are looking for.

Ticket Lifecycle via API

Close a ticket:

curl -X POST \
  -H "Authorization: Bearer bs_live_..." \
  -H "Content-Type: application/json" \
  -d '{
    "reason": "patched",
    "notes": "Applied firmware V3.0.1 during maintenance window."
  }' \
  "https://breachspider.com/api/v1/environments/5/tickets/101/close"

Reopen a ticket:

curl -X POST \
  -H "Authorization: Bearer bs_live_..." \
  -H "Content-Type: application/json" \
  -d '{
    "reason": "Patch rolled back due to process instability."
  }' \
  "https://breachspider.com/api/v1/environments/5/tickets/101/reopen"