Incident investigations
Create and restrict investigations, manage timelines and ownership, and close with verified containment state.
An incident collects detections, decisions, evidence, and response work for a security investigation. It provides an accountable timeline; it does not itself execute containment.
Open and assign
At Incidents → Create incident, enter a title, severity, owner, affected asset IDs, initial observations, and visibility. Choose restricted visibility for employee-sensitive or otherwise limited evidence. Users need both incident visibility and the separate grant for sensitive attachments.
At Incident → Team, assign an incident commander, service owner, and communications lead. Link the detections and findings being investigated so each decision can refer to its supporting observations.
The incident moves through open, investigating, contained, recovering, and closed. Use the containment and recovery checks in this guide before changing its state.
Investigate and contain
At Incident → Timeline, add evidence references, source timestamps, and factual updates. Distinguish when activity occurred from when the note was added. Label hypotheses and identify the observations or gaps supporting each decision.
Use SOC triage and playbooks to choose response steps. Request containment through Incident → Response → Request action; adding a timeline note does not execute it.
Before moving to contained, inspect each required containment action's acknowledged result. A pending approval or offline target means containment is incomplete. Partial containment remains visible with the affected target list. Marking the incident contained does not rewrite those results.
Recover and close
At Incident → Recovery, assign owners to eradication, application recovery, credential rotation, and monitoring tasks. Before removing containment, have the application owner confirm the required functions work and run finding verification for vulnerabilities involved in the incident.
Use Release isolation or quarantine restoration to remove those controls. Each requires a new authorized request and agent acknowledgement; changing the incident state does not release them.
Select Incident → Close with a resolution, residual risks, outstanding tasks, and report audience. Guard records whether active isolation, quarantine, unresolved findings, and temporary exceptions remain. Closure requires acknowledging those residual states; it does not remove them. Reopening appends to the same incident ID and preserves the previous closure.
Export the post-incident report, review lessons and rule tuning, and remove unnecessary access. Retention holds can preserve evidence beyond ordinary deletion. See Incident API and audit records.