SOP: Alert Triage Standard Operating Procedure¶

Document Type: Standard Operating Procedure Classification: Internal Applies to: SOC Tier 1 Analysts Version: 1.0 (Template — adapt to your environment)

1. Purpose¶

This SOP defines the standard process for Tier 1 SOC analysts to triage security alerts. Consistent triage process ensures: SLAs are met, alert quality data is captured, and Tier 2 receives well-prepared escalations.

2. SLA Requirements¶

SLA timers start from alert creation time, not acknowledgment time.

3. Triage Process¶

Step 1: Alert Acknowledgment (≤ SLA threshold above)¶

• [ ] 1.1 Open alert in [CASE MANAGEMENT TOOL]
• [ ] 1.2 Assign the alert to yourself
• [ ] 1.3 Change alert status to "In Progress"
• [ ] 1.4 Record acknowledgment timestamp in ticket

If the alert queue is at capacity and SLA will be breached: Notify the shift lead immediately. Do NOT silently miss SLAs.

Step 2: Initial Context (2–5 minutes)¶

Before enrichment, gather basic context:

• [ ] 2.1 What is the alert detecting? (read the rule description)
• [ ] 2.2 What MITRE ATT&CK technique does this map to? (if documented)
• [ ] 2.3 Who is affected? (user, host, IP — note all three if present)
• [ ] 2.4 Look up the affected asset in asset inventory:
• Criticality level: ____
• Business owner: ____
• Environment: ☐ Production ☐ Dev/Test ☐ Cloud ☐ OT
• [ ] 2.5 Look up the affected user in directory:
• Department: ____
• Role: ____
• Admin rights: ☐ Yes ☐ No

Step 3: Enrichment (5–15 minutes)¶

Run standard enrichment queries in SIEM. Use your team's enrichment playbook or SOAR automation if available.

Standard enrichment checklist: - [ ] 3.1 Correlated alerts for this user (7 days) - [ ] 3.2 Correlated alerts for this host (7 days) - [ ] 3.3 IP reputation check (if external IP involved) - [ ] 3.4 File hash check (if file artifact involved) - [ ] 3.5 Authentication history for user (24 hours) - [ ] 3.6 Process execution history for host (4 hours before/after)

Document findings in the ticket as you go. Do not rely on memory.

Step 4: Triage Decision¶

Based on context and enrichment, make one of four decisions:

Decision A: FALSE POSITIVE

Use when: You can positively identify the alert as a known non-malicious pattern.

Required evidence: At least one of: - Known exception or approved change ticket - System/user documented as authorized to perform this action - Historical pattern confirming this is normal behavior

Action: - [ ] Close ticket as "False Positive" - [ ] Document the reason clearly: "Closed FP — [reason]" - [ ] Tag with FP reason category (for rule tuning metrics) - [ ] If this FP occurs repeatedly: create a rule tuning request ticket

Decision B: BENIGN / INFORMATIONAL

Use when: Activity is confirmed real but not malicious and requires no action.

Action: - [ ] Close as "Benign — Informational" - [ ] Note the context explaining why it's benign - [ ] No escalation needed

Decision C: NEEDS INVESTIGATION / ESCALATE TO TIER 2

Use when: You cannot confirm FP or benign; suspicious indicators exist; warrants deeper investigation.

Required before escalation: - [ ] Asset context gathered - [ ] User context gathered - [ ] Standard enrichment completed - [ ] Summary of why you believe escalation is warranted

Escalation note format:

ESCALATING [Alert Name] — [Host/User]
Assessment: Suspicious — [1-2 sentence summary of suspicious indicators]
Context: Asset criticality=[X], User role=[X], Admin=[Y/N]
Enrichment: [Key findings — correlated alerts, IP reputation, etc.]
Recommended action: [Investigate / Declare incident]
Evidence attached: [Yes/No]

Decision D: TRUE POSITIVE — DECLARE INCIDENT

Use when: Clear evidence of malicious activity with high confidence.

Action: - [ ] Create Incident in incident management system - [ ] Notify Tier 2 analyst immediately (do not rely on ticket queue) - [ ] Begin containment steps per relevant runbook if trained to do so - [ ] Notify shift lead

Step 5: Documentation¶

Regardless of decision, the ticket MUST contain:

TRIAGE SUMMARY
--------------
Alert: [Alert Name]
Host: [Hostname] | Criticality: [Level]
User: [Username] | Role: [Role] | Admin: [Y/N]

Enrichment Findings:
- Correlated alerts (7d): [Count and summary]
- IP reputation: [Clean/Malicious/Unknown]
- Historical behavior: [Normal/Anomalous]
- [Other findings]

Decision: [FP / Benign / Escalated / Incident Declared]
Reason: [Clear, specific reason]
Time spent: [X minutes]

4. Alert Queue Management¶

Priority Queue Processing¶

Process alerts in this order: 1. Critical alerts (any age) 2. High alerts past 50% of SLA time 3. High alerts (newest first) 4. Medium alerts past SLA 5. Medium alerts 6. Low alerts

Never cherry-pick interesting alerts over aged high-severity ones.

SLA Breach Response¶

If a high or critical alert is approaching or past SLA: 1. Immediately notify shift lead 2. Shift lead may reassign or request help 3. Document the breach reason in the ticket 4. Never silently let SLAs expire

5. Common FP Patterns¶

Document your organization's known FP patterns here. Examples:

6. Escalation Matrix¶

7. Quality Standards¶

Your triage tickets will be reviewed for:

• [ ] SLA compliance (acknowledged on time)
• [ ] Complete documentation (all sections filled)
• [ ] Clear FP reasoning (FP tickets have specific, verifiable reason)
• [ ] Escalations include complete enrichment (not passed up unenriched)
• [ ] FP tagging used (enables rule tuning)

SOP-TRIAGE v1.0 | Owner: SOC Manager | Review: Quarterly