Most security operations centers reach a baseline of reactive detection reasonably well. You buy a SIEM, deploy an EDR, hire or outsource a tier-1 queue, and you close alerts. That is not maturity. That is the floor. Real plateaus — the ones that consume careers — come after.

I have watched SOC teams at three different organizations hit the same three walls in the same order. Naming them helps.

Plateau one: escape from ticket-driven culture

The tier-1 queue is a gravity well. Alerts come in, analysts triage, tickets close, metrics report. The operating model rewards volume. The problem is that the adversary does not care about your queue — the interesting activity rarely looks like an alert, and the analysts trained to close tickets quickly are trained away from curiosity.

Breaking this plateau requires permission and time:

  • Carve out hunt time — not "when the queue is clear" (it never is), but protected calendar time every week.
  • Measure detection quality, not alert volume. A false-positive rate, a coverage map against MITRE ATT&CK, or a count of net-new detections shipped.
  • Hire or develop at least one senior analyst whose job is explicitly not the queue. If everyone is on tickets, nobody is hunting.

Plateau two: detection engineering as a discipline

Most SOCs write detections the same way 2005 sysadmins wrote shell scripts — one analyst, one rule, deployed straight to production, no tests, no peer review, documented in a comment field if at all. Then a vendor update nukes half of them and nobody notices for six weeks.

Detection-as-code is the way out. In practice:

  • Detections live in a Git repository, with tests, reviews, and CI/CD into the SIEM or EDR platform.
  • Every detection has a purpose, a data dependency, a known false-positive profile, and an owner.
  • You have an engineering function — not a rotating analyst — that owns the rule lifecycle. Two people is enough to start.

This sounds like process overhead until your first major platform migration. Then it becomes the only reason your detections survive.

Plateau three: purple team and the MSSP question

The third wall is proving your detections actually work against the behavior they claim to catch. Red teams find gaps once a year and file a PDF. Purple teams find gaps continuously, hand them to detection engineering, and fix them in sprint. If your red team exercises do not feed a backlog, they are entertainment.

Related: this is often the plateau where the MSSP relationship breaks. An MSSP can run the tier-1 queue forever. They cannot, in my experience, be the detection engineering function or the purple team. Those require context about your business that an outsourced team will never have. Most mid-market orgs hit a point where they pull hunt and detection engineering in-house and leave triage outsourced. That is fine. Naming it explicitly is how you get there without a messy transition.

MTTD is a vanity metric if your detections only cover the behavior you already had detections for. Coverage against the adversary behaviors you have not yet detected is the metric that matters.

Metrics that push you past the plateau

  • ATT&CK technique coverage, not generic "alerts tuned."
  • Detections added or retired per month, with a quality review of each.
  • Mean time to investigate a hunt hypothesis, not mean time to close a ticket.
  • Purple team findings closed versus open, with age.

The takeaway

Map your SOC against these three plateaus honestly. If you are still arguing about alert volumes, you are at plateau one. If every detection change is an ad hoc edit in the console, plateau two. If your red team reports do not change what the blue team does on Monday, plateau three. Each plateau is broken by the same thing: making something that used to be a heroic one-off into an engineered practice with owners, measurements, and a backlog.