The Alert Lifecycle — From Sensor to Close

Before an analyst ever opens a ticket, the alert has already traveled through several automated systems. Understanding that pipeline explains why some alerts arrive richly contextualized and others arrive as bare log lines — and why both cases require different triage disciplines.

The Pipeline: Seven Stages

Stage 1: Sensor fires

Every alert begins with a sensor: EDR, SIEM correlation rule, IDS/IPS, cloud security service, or a 3rd-party feed. The sensor observes something that matches its detection logic and emits an event.

Stage 2: SIEM ingests and correlates

The SIEM receives the alert and may apply additional correlation: “is this alert part of a chain of events from the same host in the last 5 minutes?” Good SIEM correlation can merge what would otherwise be five separate tickets into one incident. Poor correlation generates five separate tickets that analysts must mentally link — a significant cognitive overhead.

Stage 3: Enrichment

Stage 4: Ticket creation

The SIEM or SOAR platform creates a ticket with the alert data + enrichment attached. The ticket is assigned a severity, routed to the appropriate queue (cloud, endpoint, email, identity), and timestamped. This is the moment the SLA clock starts.

Stage 5: Analyst triage

The analyst opens the ticket. Their job: confirm the enrichment is accurate, perform additional pivots the automation missed, form a working hypothesis, and reach a disposition. This is the subject of the next lesson.

Stage 6: Disposition recorded

Every ticket must reach one of four dispositions:

Stage 7: Feedback to detection

False Negative Blindness

The alert lifecycle has a dangerous asymmetry: every FP is visible (it creates a ticket), but every FN is invisible (no ticket exists). This creates a systematic bias toward treating the visible problem (FP volume) as the only problem.

This is why coverage metrics (DML level, technique coverage heatmaps) matter — they make FN risk visible before a breach occurs.