Stop Asking “Are We Normal?” Ask “Can We Actually Stop a Breach?”

Every SOC leader I know has, at some point, googled some version of "average dwell time by industry" or "how many analysts do we actually need." It's a natural instinct. You want a number to hold your own program up against. The problem is that the number you find rarely tells you what you think it does.

I've spent years on both sides of this building detections and running incident response, and more recently helping teams figure out where their security operations actually stand. And the more benchmark data I look at, the more convinced I am that the question most people are asking is the wrong one.

"Are we normal?" is a comfortable question because it has a comfortable answer. Most teams sit somewhere in the middle of the pack, and the middle of the pack feels safe. But the average isn't a safety net it's just a description of how under-resourced the industry is on average. A breach doesn't care whether you matched the median. It cares whether you saw it in time.

The Metrics That Actually Matter

Not every number on a SOC dashboard deserves your attention. A vulnerability count, for instance, is trivia it tells you nothing about whether you can catch an active attacker. The metrics worth tracking are the ones that change a decision:

Mean Time to Detect (MTTD) — tells you where to invest in detection coverage
Mean Time to Investigate (MTTI) — tells you whether enrichment should be automated
Mean Time to Contain (MTTC) — exposes gaps in your response playbooks
Dwell time — the clearest signal of where your blind spots live
False-positive rate — the number that quietly burns out your analysts
Detection coverage against a framework like MITRE ATT&CK — your actual roadmap for new detections

A quick note on "MTTR," since it gets thrown around loosely: people use it to mean respond, remediate, recover, and contain, often all at once, blended into a single number. That's not useful. Split it into two honest commitments instead how fast you get eyes on a fresh alert, and how fast you escalate a confirmed critical incident. A blended average can hide the fact that you triage quickly but escalate slowly, or the reverse, and a board deserves to know which.

Dwell Time Is the Number That Should Keep You Up at Night

Here's a gap that's easy to miss: the median time it takes an organization to detect an intrusion on its own is roughly ten days, industry research shows. But when detection comes from someone outside the organization a partner, a customer, law enforcement that number balloons to closer to twenty-six days. Meanwhile, some of the fastest observed attacker break-ins happen in under a minute from initial access to lateral movement.

Sit with that mismatch for a second. If your response SLA is written in hours, but an attacker can move from foothold to damage in under sixty seconds, the SLA was already lost before it was written. That's not a reason to panic it's a reason to shift the question from "how fast do we respond" to "how fast do we detect in the first place," because detection speed is the lever that actually controls the outcome.

If you want an honest gut-check on your own dwell time this week, it doesn't require a budget. Fire off a safe, simulated event a synthetic transaction that should trip a known detection and see if an alert actually fires within a couple of minutes. If it doesn't, congratulations: you just found a blind spot before an attacker did, and for free.

Benchmark Against Your Sector, Not the Planet

A global average blending a bank, a hospital, a SaaS company, and a factory into one number is close to useless. Each of those organizations faces a different attacker profile, a different tolerance for downtime, and a different regulatory environment breathing down its neck. A financial services firm lives under tight response SLAs and heavy scrutiny. Healthcare organizations tend to carry more dwell-time exposure while protecting data that's expensive to lose. SaaS companies fight identity-driven attacks aimed at account takeover. Manufacturing sees comparatively lower targeting, but a single halted production line can be enormously costly.

When you pick a peer group to compare yourself against, match on three things: industry (because the attacker set differs), company size (a 600-person org and a 6,000-person org staff very differently), and regulatory load (PCI, HIPAA, and SOC 2 all pull priorities in different directions). Get those three roughly right, and the comparison finally means something.

The Staffing Math Nobody Wants to Do

This is the part that quietly breaks most build-it-yourself SOC plans. There are 168 hours in a week. One analyst, working a normal schedule, covers around 40 of them. True round-the-clock coverage genuine 24/7/365 needs a bare minimum of about five full-time analysts just to keep one seat perpetually filled, and a realistic, sustainable model looks closer to nine analysts plus a SOC manager once your account for vacation, sick time, escalation paths, and turnover.

That's before you count tooling. Money isn't the only constraint, either plenty of teams buy strong tools and then leave them half-used because nobody has the bandwidth or the specialized skill to run them properly. And headcount doesn't scale neatly with alert volume: an analyst buried under thousands of low-quality alerts burns out and misses the one that mattered. If your noise ratio is ugly, the fix isn't always "hire more people" sometimes it's "fix the signal first."

That single insight fix detection logic before you automate around it is worth repeating on its own. Automating a broken signal just means you process garbage faster. Tune the detections, cut the noise, and only then let automation take the repetitive investigation work off your analysts' plates.

Maturity Is a Ladder, not a Cliff

If you're trying to figure out where you stand, resist the urge to compare yourself to the most sophisticated team you've ever heard of. Most mid-market security programs sit somewhere between "developing" and "mature," and that's a perfectly normal place to be. A structured maturity model something like SOC-CMM, scored across a handful of domains, mapped to a recognizable framework like NIST CSF's Govern, Identify, Protect, Detect, Respond, and Recover functions lets you see honestly where you are without needing to leap straight to elite-tier numbers your staffing can't support yet.

Score yourself honestly, not flatteringly. Map that score to where your budget is actually going. More often than not, you'll find spend clustered heavily in the "Protect" function tools and licenses while "Detect" is thin. That's usually where the real gap hides, even when the dashboards look busy.

What to Actually Do with All This

You don't need a new budget line to start closing the gap. A few things cost nothing but a little time and a willingness to be honest with yourself:

Run a synthetic transaction. Confirm a known detection actually fires, and how fast.
Map you spend to a framework. Drop every security dollar onto the NIST CSF functions and see where the proactive column goes suspiciously quiet.
Review third-party access grants. A quick audit of connected apps and OAuth consents is free shadow-IT discovery that shrinks your unknown attack surface.

None of this "wins" cybersecurity nobody wins this game, you just stop being the easiest target in the room. But a benchmark that's honest about where you sit, measured against people who actually face your kind of attacker, is worth infinitely more than a number that just tells you you're average.

Because the real question was never "are we normal?" It's "if this happened tonight, would we catch it in time?"