The Queue Was Never the Job

Walk into almost any security operations center and the first thing you'll see is a queue. A list of alerts, ranked by severity, waiting for a human to work them from the top. The whole operation is organized around emptying that list faster than it fills. We hire against it, we build shift schedules around it, we measure analysts on how quickly they acknowledge and close it. For about twenty years, the queue has been the job.

Start with the arithmetic, because it's brutal. A single analyst can be on the hook for three to five thousand alerts a day. In noisy environments, up to 99% of them are benign, real signal that simply isn't a threat, which means the genuine attacks sit buried behind a wall of it. A large share of alerts, by common estimates north of 60%, never get reviewed at all. You cannot hire your way across that gap, because alert volume scales with your attack surface and headcount doesn't.

The SANS 2025 SOC Survey adds the twist. Satisfaction with generative AI tooling ranked last among every SOC technology it measured. The easy read is "AI isn't ready." Look closer and it's the opposite lesson: roughly 40% of SOCs run AI and ML with no defined role in operations, and 42% run it straight out of the box with no customization. That's not a verdict on AI. It's a verdict on bolting AI onto a broken workflow and expecting the workflow to fix itself.

Both findings get filed as separate problems, one about staffing and one about tooling. They're the same problem, and it's older than either. We built the SOC around the wrong unit of work.

The fix isn't a faster queue. It's not treating the alert as the thing at all.

The alert is the unit of detection, not the unit of work

An alert is what a sensor emits when a rule fires. It is a unit of detection. Somewhere along the way we started treating it as a unit of work, the thing an analyst opens, reasons about, and closes. Those are not the same thing, and the gap between them is where the SOC breaks.

A single real event does not produce a single alert. An attacker who phishes a credential, logs into a cloud console, and reaches for a data store lights up your email tooling, your identity provider, and your cloud logs separately. That's one adversary taking three steps, and your queue renders it as three unrelated rows, probably interweaved with a few hundred benign ones that fired the same hour. The analyst's first and hardest job is reassembly: figuring out that rows 14, 209, and 588 are the same story. The tooling handed them the pieces shuffled and called it a work list.

This is why "reduce alert volume" has never actually fixed anything. Tuning and filtering make the pile shorter, but they don't change what a row is. You are still asking a human to hold twelve fragments in their head and reconstruct the event before they can even begin to make a decision. Most of the cognitive load in a SOC isn't the deciding. It's the reassembly you do before you're allowed to decide. You can't filter your way out of that, because the queue was never structured around events in the first place. It was structured around sensor output.

Once you see it that way, the burnout numbers stop looking like a wellness problem and start looking like an architecture problem. We are asking people to do, by hand, thousands of times a day, the one task computers are genuinely good at: correlating structured records into groups.

The Situation is the unit of work

So change the unit. A Situation is a single real security event, assembled automatically from every alarm and entity that correlation ties together: one actor, one timeline, one narrative, one verdict, one set of response actions. Instead of a row per detection, the work item groups those detections before a human ever opens it. Same actor, same identities, same assets, same window, same arc across the kill chain, collapsed into a single thing that carries a narrative, a severity, a confidence, and the entity-to-entity progression that shows how the event moved.

The phishing example stops being three alerts and a guessing game. It's one Situation: compromised credential, anomalous console login, attempted access to a data store, with the timeline and the affected identities and hosts already assembled. A hundred alarms become one Situation. The analyst arrives at the story instead of the raw feed.

That's not a figure of speech. A single live environment can throw off more than a thousand alarms an hour, on the order of 80,000 a day, volume no human team will ever work row by row. Correlation folds that flood into a handful of Situations, each one typically gathering twenty-five to thirty alarms into a single event. The pile doesn't get prioritized. It gets structured into the events it was always describing.

That single move changes the shape of the job. The analyst's work is no longer "acknowledge, correlate, enrich, then maybe decide." It's four steps that are all judgment: identify what the Situation actually is, investigate the parts the correlation couldn't settle, determine a verdict, and respond. The reassembly, the enrichment lookups, the IOC correlation against intel feeds, the deterministic first pass, that all happened before the human opened it. What's left is the part that needed a person, and only that part.

This is the version of "AI plus humans" that actually holds up, and it's worth being precise about where the line sits. The machine does the correlation and the mechanical first eighty percent, because that work has a stable, checkable answer. The human owns the verdict and the response, because those are calls about business context, cost asymmetry, and consequence that the model doesn't get to make. High-impact response still waits for a person to approve it. The Situation is what makes both halves true at once: it's the artifact where the machine's work ends and the analyst's judgment begins, and you can see the seam. Every correlated alarm, every enrichment, every model verdict is visible and attributable, so the analyst can agree, override, or dig, rather than defer. 

Note what a Situation is not. It isn't a "case" you open in a ticketing tool after the fact, and it isn't a generic "investigation" bucket you dump telemetry into. It's the native unit the SOC runs on, the system of record, forming continuously from live signal. The alert becomes what it always should have been: evidence inside a Situation, not a task on a human's list.

The goal is zero queue, and that's the starting line

If Situations are the unit of work, the target state has a name, and it's a strange one to say out loud in security: zero queue. Zero queue is the state where nothing is left to triage, not because alerts were filtered away or ignored, but because the deterministic work is finished and every Situation that needed a human decision has already had one. The list is empty because the work is genuinely done, not deferred.

Two things usually get thrown at that idea, and both are worth answering directly.

The first is "zero queue means you're missing things." This is the reflex that empty means blind. It's the right instinct, and it's why an empty queue can't stand on its own. Silence only counts as safety if it's backed by numbers that explain it: how much volume actually arrived, how much was auto-resolved as benign, how much got escalated to a human, whether the model's confidence is holding calibrated, whether the noise is trending up or down. Quiet without those numbers is anxiety. Quiet with them is assurance. The difference between the two is the whole game, and it's why observability into the machine's work matters more in a zero-queue SOC, not less.

The second is "then what do the analysts do?" This is the part people miss, so I'll be blunt about it. Zero queue is not the finish line. It's the starting line. For twenty years, reaching the bottom of the queue was a fantasy that never happened, so we never had to answer what a SOC does with the time. The answer is the work that actually reduces risk and never fit into a queue-driven day: hunting against hypotheses in your own environment, tuning detections so tomorrow's noise is quieter, and building the playbooks that make the next Situation resolve faster. That's not idle time you've created. It's the proactive half of security operations that the queue was eating the entire time.

What this changes on Monday

The reframe is free to say and expensive to adopt, so here's what actually has to change.

Your metrics have to move first, because they encode the old model. Mean time to acknowledge, alerts closed per shift, queue depth: every one of those measures how well a human services a list, which is the job we're trying to stop doing. If your analyst reviews still anchor on tickets-per-shift, you are paying people to be fast at the thing the machine should own, and you are training your best people to leave. Measure Situations resolved, verdict accuracy, time-to-verdict on the ones that matter, and how much of the week analysts spent hunting, tuning, and building instead of servicing rows.

Your correlation has to be good enough to trust, which is the hard engineering part nobody's marketing slide mentions. Grouping alarms into a real event by actor, identity, asset, time, and kill-chain stage, continuously, at production volume, without silently merging two events into one or splitting one into five, is difficult. It's the difference between a Situation you can act on and a pile with a nicer label. Get it wrong and you've added a layer of misplaced confidence on top of the same old queue.

And you have to be honest about whether you can run this way in-house. Most can't, and it's no knock on them. It takes correlation engineering, model output you can audit, analysts trained to work verdicts instead of rows, and the leadership runway to change the metrics before the payoff shows up. That's a lot of bench depth to own. Renting the capability from a SOC that already built it is a legitimate answer, and often the honest one. The point isn't who runs it. The point is that a SOC organized around a queue is servicing sensor output, and a SOC organized around Situations is defending the business. Those are different jobs.

At Binary Defense this is the model our SOC runs on, and the reason NightBeacon exists: to do the correlation and the mechanical first pass so our analysts arrive at Situations, own the verdicts, and spend their reclaimed time hunting rather than sorting. But you don't have to buy anything to act on the idea. Look at your own operation and ask one question. Is your team working events, or working a list? If it's a list, the queue isn't your workload. It's your architecture, and it's the thing to change.

Common questions

What is a Situation in a SOC?

A Situation is a single real security event, assembled automatically from every alarm and entity that correlation ties together by actor, identity, asset, time, and kill-chain stage. Instead of working a list of disconnected alerts, an analyst opens one Situation that already carries the timeline, the affected hosts and identities, a narrative, and a proposed verdict.

What does zero queue mean in a security operations center?

Zero queue is the state where there is nothing left to triage. It happens not because alerts were filtered away or ignored, but because the deterministic correlation and first-pass work is finished and every Situation that needed a human decision has had one. It's a starting line, not a finish line: the point is to free analysts to hunt, tune detections, and build playbooks.

Are security alerts the same as incidents?

No. An alert is what a sensor emits when a rule fires, so it's a unit of detection. A single real incident usually produces many alerts across email, identity, endpoint, and cloud. Treating each alert as a task forces analysts to reassemble the event by hand before they can decide anything, which is where most of the cognitive load and burnout come from.

Does reaching zero queue mean threats are being missed?

Only if the quiet isn't backed by numbers. An empty queue is trustworthy when it's accompanied by the volume that actually arrived, how much was auto-resolved as benign, how much was escalated to a human, and whether the model's confidence is holding calibrated. Quiet without those numbers is anxiety. Quiet with them is assurance.