Alert management is the operational layer that sits between your detection rules and your analysts. A detection rule fires. Something needs to decide what severity that alert gets, who it goes to, what the SLA is, and what automated enrichment runs before a human touches it. Getting this structure right is the difference between a SOC that handles 200 alerts a day smoothly and one that drowns in the same volume.
This post covers the alert data model, severity schema, status lifecycle, queue assignment rules, and the triage automation criteria that determine whether an alert can be handled programmatically or needs human judgment.
The Alert Data Model
Every alert in a well-structured SOC has a consistent set of fields regardless of which detection rule generated it. These fields are what make automation, routing, SLA tracking, and reporting work reliably. If your alert schema is inconsistent — some alerts have a source field, others don't — automation breaks and reporting becomes unreliable.
alert_id: "ALT-2026-08472" // unique, sequential, traceable
title: "PowerShell spawned from WINWORD.EXE"
severity: "P1" // P1 | P2 | P3 | P4
status: "New" // lifecycle stage
source: "CrowdStrike Falcon" // detection platform
detection_rule: "Office_Macro_Spawns_Shell"
mitre_technique: "T1566.001"
created_at: "2026-08-26T14:32:11Z"
assigned_queue: "Tier2-Malware"
assigned_analyst: null // null until picked up
sla_due: "2026-08-26T14:47:11Z" // 15 min SLA for P1
// Entity fields — what the alert is about
host: "WORKSTATION-042"
user: "DOMAIN\\jsmith"
ip_address: "10.4.12.88"
// Enrichment fields — added by automation
user_department: "Finance"
host_criticality: "High"
threat_intel_match: false
recent_alerts_same_host: 3
// Investigation fields — filled by analyst
disposition: null // True Positive | False Positive | Benign TP
investigation_notes: null
closed_at: null
closed_by: null
Severity Schema
Severity is the most important field in the alert schema because it drives SLA, queue assignment, notification, and escalation. The mistake most SOCs make is defining severity too broadly — "High" means everything from a credential dump to a failed login attempt, which means analysts can't prioritize the queue effectively.
A working severity schema has four levels with explicit, objective criteria for each:
P1 — Critical (15-minute SLA)
Active threat with confirmed or near-certain malicious activity. Immediate action required. Examples: confirmed ransomware file creation, confirmed credential dumping tool execution, DCSync from non-DC account, Domain Admins group modification outside change window, active C2 communication confirmed by EDR.
P2 — High (1-hour SLA)
High-confidence indicator of compromise with significant business risk if confirmed. Examples: PowerShell from Office application, LSASS memory access from unexpected process, impossible travel with successful authentication, Kerberoasting RC4 ticket sweep, scheduled task creation from suspicious binary.
P3 — Medium (4-hour SLA)
Suspicious activity that requires investigation but has meaningful false positive potential. Examples: failed login threshold exceeded, new local admin account, process connecting to unusual external IP, after-hours admin activity from 9-5 account, large data export volume.
P4 — Low (24-hour SLA)
Informational or low-risk activity worth recording but not urgent. Examples: single failed login, known vulnerability scanner activity, policy violation without active exploitation, benign software behaving unexpectedly.
If more than 20% of your P1 alerts close as false positives over a 30-day period, the detection rule generating them should be downgraded to P2 or tuned more aggressively. P1 should be reserved for alerts where the analyst's first instinct is "this is real until proven otherwise," not "let me check if this is real."
Alert Status Lifecycle
The status field tracks where the alert is in the investigation lifecycle. Most SOC ticketing systems have their own status labels — map these to your platform's native fields rather than trying to rename them.
New → Alert created, no analyst action yet
Assigned → Picked up by an analyst
In Progress→ Active investigation underway
Pending → Waiting on external input (other team, user, tool)
Escalated → Passed to Tier 2, IR team, or management
Closed → Investigation complete, disposition recorded
// Disposition values — required before closing
True Positive → Confirmed malicious, incident created
False Positive → Confirmed benign, rule needs tuning
Benign True Positive→ Expected behavior, documented and closed
Inconclusive → Unable to determine, document findings
Queue Assignment Criteria
Queue assignment routes alerts to the right analyst group before any human touches them. The routing logic should be explicit and documented — not "Tier 1 gets everything" but specific criteria that determine which queue an alert lands in.
IF severity == "P1" AND source IN ["EDR", "SIEM"]
THEN queue = "Tier2-Critical"
IF mitre_technique IN ["T1486", "T1489"] // ransomware
THEN queue = "IR-Team", notify = "IR-Lead"
IF host_criticality == "Domain Controller"
THEN queue = "Tier2-Identity"
IF severity == "P2" AND source == "Email Gateway"
THEN queue = "Tier1-Phishing"
IF severity IN ["P3", "P4"]
THEN queue = "Tier1-General"
DEFAULT queue = "Tier1-General"
Triage Automation Rules
Triage automation runs before an analyst touches the alert. Good automation adds context. Great automation makes some alerts disappear because they're proven benign without human effort. Dangerous automation closes real incidents.
The four criteria that must all be true before any alert can be automatically closed:
- False positive rate under 5% — measured over 30 days of actual data, not estimated
- Deterministic decision logic — every analyst would make the same call given the same data
- Safe failure mode — if the automation makes a wrong call, the consequence is low-risk
- Reversible action — anything the automation does can be undone without escalation
Enrich: always safe
→ Pull threat intel on IPs, domains, hashes
→ Look up user department, manager, last login
→ Check host criticality rating
→ Count related alerts in last 7 days
Auto-close: only when ALL four criteria met
→ Known scanner IP hitting known scanner signature
→ Vulnerability management tool matching its own CVE scan signature
→ Alert from allowlisted account on allowlisted host for allowlisted action
// Never automate these actions
Never: isolate host without human approval
Never: disable account without human approval
Never: close P1 or P2 automatically regardless of rule
Never: auto-close behavioral anomaly alerts
Track mean time to triage before and after automation. Track the false negative rate — alerts that automation touched but that later turned out to be real incidents. Both numbers should improve. If mean time doesn't change or false negatives increase, the automation is adding work, not removing it.
Complete alert triage framework — severity matrix, 5-phase triage process, escalation criteria, automation readiness checklist, and ticket wording templates. Built from 10 years of real SOC operations at major Canadian financial institutions.
Get SOC Starter Kit — $39 Or Join Intel Pack — $14.99/mo