Skip to main content
Alert checklists give analysts a consistent, auditable set of response steps for every applicable alert. Administrators can target a checklist to every alert or to selected governed alert types such as phishing and malware. A checklist is copied from the effective published configuration when an alert is created or backfilled, so later changes do not silently rewrite an investigation.

​
Complete an alert checklist

Open an alert and select the Checklist tab. Required and optional items are grouped separately. Each item shows its dependency, evidence requirement, policy source, revision, and completion or waiver history. Select an item to open its detail panel. From there you can:
  • review analyst guidance and state history;
  • add Markdown comments, mentions, and attachments;
  • provide required completion evidence;
  • complete or reopen the item; and
  • review the actor and time for completed or waived work.
Concurrent changes are protected by item revisions. If another analyst updates the same item first, refresh the checklist and review their change before trying again.

​
Add an alert-specific step

When the effective policy allows alert-specific steps, select Add step from the checklist summary. Enter a title and optional guidance. The step is added to this alert only and is labeled Alert-specific so it cannot be confused with a governed policy requirement. Alert-specific steps are optional by default. Checklist managers can mark a new step as required before closure. Policy-derived steps cannot be removed from an alert. Alert-specific steps can be archived, but their activity and audit history are retained.

​
Close an alert

Use the close action and choose any status whose stage is Closed. The dialog shows required-item progress and links to remaining blockers.
  • Off records progress without affecting closure.
  • Warn identifies incomplete requirements but permits closure.
  • Block prevents closure until every required item is completed or waived.
When policy permits a privileged override, an authorized user must provide a meaningful reason and acknowledge the remaining blockers. Overrides are retained in the audit trail.

​
Configure policies

Administrators manage checklists in Settings → Alert Checklists. The page shows every checklist and whether it is on, off, or still needs setup. To create one:
  1. Select New checklist and give it a clear name.
  2. Add the steps analysts should complete.
  3. In Settings, choose whether it applies to All alerts or selected alert types.
  4. Select Save and enable.
The checklist is then added to matching new alerts. Use the switch beside a checklist to turn it on or off. Turning it off preserves its steps and change history. The checklist library shows each checklist’s target alert types, and the editor previews how many recently active alerts match. Multiple enabled checklists can match the same alert. Their steps are merged by stable key using the existing global and organization precedence rules. The alert’s Checklist tab explains which checklists were selected and why.

​
Classify and reclassify alerts

The Alert type field uses a governed taxonomy that is separate from the integration source. For example, an alert can have source crowdstrike and type malware. Changing an active alert’s type immediately re-evaluates its checklist. Completed and waived work with the same stable key is preserved, new matching steps are added, and requirements that no longer apply are retired from the active list while remaining in audit history. Closed alerts preserve their historical checklist snapshot even if their classification is corrected. Workflows can evaluate alert.alertCategoryValue and use the Set Alert Type action. Alert templates may also set alertCategoryValue; checklist resolution always runs after that classification is applied. Use Settings to choose what happens when required steps are unfinished. Change history retains prior saved versions and rollback controls. Less common options, such as dependencies and stable automation keys, are grouped under More options for each step. Super administrators manage checklists for all organizations and decide whether organization-specific checklists may supplement them. Organization administrators can only manage their current organization and cannot weaken locked global controls.

​
Rollout and recovery

Backfill applies only to non-deleted alerts whose status stage is not Closed. Jobs are resumable and idempotent. Historical closed alerts are not changed. Operators can temporarily set ALERT_CHECKLIST_ENFORCEMENT_DISABLED=true to stop checklist blocking without deleting checklist state or audit evidence.