The SOC as a System — Tiers, Functions, and Metrics

A SOC analyst’s day is a queue. Hundreds — sometimes thousands — of alerts arrive each shift. The analyst’s job is to work that queue as accurately and efficiently as possible: open ticket, enrich, pivot, decide, document, close or escalate. Repeat.

But the queue doesn’t exist in a vacuum. It’s the output of a system — sensors, SIEM, enrichment pipelines, detection rules, team structure, shift schedules, and management incentives. Understanding that system is the difference between an analyst who burns out in six months and one who gets better every week.

The Two SOC Models

The tiered model works well at volume. A well-run L1 tier closes 70–80% of alerts before they need escalation, protecting L2 and L3 capacity for complex cases. But it has a known failure mode: handoff loss. Tickets that cross from L1 to L2 carry whatever context the L1 analyst documented — and L1 analysts under time pressure document less. Information degrades at each tier crossing.

The tierless model is growing in popularity, especially in mid-size organizations. Because analysts own outcomes rather than steps, there’s no incentive to hand off prematurely. The tradeoff: breadth-first training takes longer, and volume spikes can overwhelm a squad.

The 6 SOC Functions

Every SOC, regardless of structure, must own six functions. The question is who owns each one.

Function	What it means	Who owns it (tiered)
Monitoring	Eyes on telemetry — dashboards, alert feeds, anomaly queues	L1
Alert Intake & Triage	First-touch on every alert: enrich, classify, close or escalate	L1
Investigation	Deep-dive on likely-TP alerts: timeline, pivot, scope	L2
Response & Containment	Take action: isolate, revoke, block, engage IR	L2/L3 + IR
Intel Consumption	Read CTI, update IOC feeds, brief team on active threats	L3 / Intel team
Detection Engineering	Write, tune, and maintain the rules that generate alerts	DE team / L3

MTTD and MTTR: The SOC’s Vital Signs

The relationship between the two matters: a low MTTD with high MTTR means you’re detecting fast but not acting fast — which leaves the attacker operating even after you’ve noticed. A low MTTR with high MTTD means you contain quickly once you know, but threats dwell for days or weeks before you do.

Common MTTD killers even with good rules:

Alert queue saturation — rules fire but analysts can’t reach the ticket before the threat has moved laterally
Low precision — 96% FP rate conditions analysts to treat all alerts as noise; the real threat gets closed as a FP
Shift handoff gaps — alert fires at 23:45, no analyst sees it until 08:00 the next morning
Triage SLA not enforced — no accountability mechanism for how long alerts sit unacknowledged

SLAs and Severity Matrices

A SOC without SLAs has no accountability mechanism. Every alert should have:

A severity tier (P1/P2/P3/P4 or Critical/High/Medium/Low)
An acknowledgment SLA (how long until an analyst opens the ticket)
An investigation SLA (how long until a disposition is recorded)
An escalation SLA (how long until L2 is engaged if L1 cannot resolve)

SLAs only work if someone is watching them. SOC managers typically run dashboards showing “breach” counts — alerts that exceeded their SLA without a disposition. High SLA breach rates are the earliest leading indicator of queue saturation, well before analyst burnout becomes visible.

11 Strategies of a World-Class SOC— MITRE / John Hubbard SANS SEC450 — Blue Team Fundamentals— SANS Institute