The last board deck I presented had a clean line on it: our security operations center (SOC) scored mature on the model, level 4 across most domains, with detection engineering and incident management documented and measured. Two weeks after that deck, we cleaned up an intrusion that had been sitting in our environment for longer than I'd like to admit in print. The score and the dwell time were telling different stories.
Those two facts coexist because a SOC maturity model measures which capabilities exist on paper and how well they are organized, while performance under attacker movement is a separate question with separate metrics. The maturity score only answers the first one. When a SOC leader carries the score upstairs as evidence that the SOC is performing, the report is answering the wrong question.
In brief:
- A SOC maturity model scores whether a capability exists and how well it is documented. It stays silent on time-to-detect, tested coverage, and escaped-alert rate.
- A high maturity score and a weeks-long missed intrusion are fully consistent, because the score measures presence while the intrusion measures performance.
- Goodhart's Law explains the failure: once the maturity number becomes the target, spend flows toward raising the score rather than reducing risk.
- Use the model as a gap-assessment scaffold and a roadmap tool for non-technical leadership, because it fails the moment you treat it as a performance metric.
Use maturity models for roadmaps and outcomes for scorecards
Maturity models have real value, and I have run SOC Capability Maturity Model (SOC-CMM) assessments that paid off. The model is a structured scaffold for gap assessment across five domains, a repeatable way to find soft spots. When I justify a budget line to a chief financial officer (CFO) unfamiliar with a Sigma rule or a security information and event management (SIEM) query, "we are at level 2 and need level 3 at a defined cost" is genuinely useful.
The score goes wrong when it stops being a diagnostic and becomes the objective. The model tells you whether you have a documented detection engineering process that is systematically measured for quality and timeliness, which is a level 4 claim. It says nothing about whether those detections fire when an attacker uses the technique they are supposed to catch. Presence and performance are two different measurements, and the org that confuses them is the org I have been.
What the model scores and what it stays silent on
SOC-CMM scores capability and maturity. Capability is what the SOC can deliver as output, and maturity is how well it is organized. On the maturity side, all five domains run a 0-5 scale from non-existent to continuous improvement, and a level 4 aspect is quantitatively managed: measured for quality, quantity, and timeliness. That can sound like performance, but it measures how well the process is instrumented while leaving the target of the instrument untested.
- Scores: process documentation and consistency, technology inventory (whether you run SIEM, endpoint detection and response (EDR), security orchestration, automation, and response (SOAR), and network detection and response (NDR)), service-delivery scope, staffing and training, and capability breadth.
- Silent on: mean time to detect, mean time to contain, dwell time, tested coverage against real attack variants, and escaped-alert rate.
The second list holds the numbers a board should actually care about, and they are also the ones teams find hardest to produce, since nearly half of organizations say they struggle to evaluate detection engineering effectiveness in SANS's 2025 survey. The model treats those outcomes as open gaps its users wrestle with, so outcome coverage sits outside the score.
Why a high score and a missed intrusion sit together comfortably
Separate the two questions and the coexistence makes sense. Take detection coverage, the thing everyone points at to prove the SOC works. A maturity assessment confirms you have detections mapped to MITRE ATT&CK and a green heatmap, but coverage breaks silently as environments and telemetry change. A green square can overstate coverage, because a technique has many real-world variants, and one mapped detection will not catch the version an attacker actually uses.
Traditional SIEM rules show how a documented capability goes untested. They're often deployed and then left to drift as configurations change until the technique walks past them. The gap widens as attackers lean on valid-credential access over malware, with 97% of identity attacks being password attacks in Microsoft's 2025 data, so a static signature rule often has nothing to fire on. The model scores the existence of a detection process; it does not emulate an adversary to see if the detection still fires. When I had a level 4 process and a weeks-long dwell time in one quarter, both were true: the process was organized, the detection quiet because no one tested it.
The metrics that actually track a working SOC
If the maturity score reports presence, you need a small set of metrics that report performance. These are the ones I now put in front of the board alongside, and increasingly instead of, the maturity number. They measure the window an attacker gets, and that window is short, since the average intruder breaks out in 48 minutes after initial access, faster than many SOCs can alert.
- Mean time to detect (MTTD): the window between when an incident starts and when you catch it. This is the number that would have surfaced my dwell-time problem months earlier.
- Mean time to contain (MTTC): detection to full containment, reported by incident class, because "ransomware in production costs us X days of disruption" lands with a board in a way a maturity level never will. For scale, the global median time to identify and contain a breach is 241 days.
- Dwell time: total time a threat sits in the environment. The global median rose to 11 days in 2024, up from 10 in 2023, and if you are not measuring your own, the model will not tell you where you land.
- Tested coverage: the percentage of detections you have implemented and validated, since written rules alone do not count. Adversary emulation and purple-team exercises turn a claimed heatmap into a tested one.
- Escaped-alert rate and false negatives: the misses the SOC never saw. False positives create fatigue, with 70%+ of security leaders already struggling with alert fatigue and false positives, while false negatives are the breaches you did not catch.
These numbers move when the SOC gets better or worse at its actual job, and the maturity score does not. Let them trigger decisions, so a spike in MTTC prompts a response-plan review and a drop in tested coverage prompts rule tuning.
How incentives game the score
Goodhart's Law explains the incentive problem. In Marilyn Strathern's phrasing, once a measure becomes the target it stops being a useful measure, because rewarding a metric creates pressure to manipulate it, and the measured system can degrade while the reported number improves.
That pattern describes how a maturity program goes wrong. Once the board watches the number, the SOC gets pressure to raise it, and that is easy: buy tools that fill inventory gaps, or write standard operating procedures (SOPs) that lift a process to level 4. Neither reduces dwell time or closes a gap. The same harm recurs per metric: rule-count targets inflate alerts, and time-to-close targets push analysts to close tickets as false positives while performance decays.
Report outcomes, keep the model for the roadmap
Split the board report into two layers with different jobs: one creates accountability and the other supports roadmap planning, and keeping them separate stops the roadmap from masquerading as proof of performance.
- Outcome and tested-coverage layer, for accountability: MTTD, MTTC, dwell time, tested coverage against your priority ATT&CK techniques, false-positive and escaped-alert rates, and the results of your last tabletop or purple-team exercise. Frame the containment numbers in business terms, because business context is what turns technical accuracy into oversight.
- Maturity layer, for roadmap and budget only: current and target levels plus the investment needed to close the gap. This is where the model belongs, to justify the check while outcome metrics prove the work.
For years I let the roadmap tool double as the performance report, and they are not the same artifact. When the CFO asks whether we are more secure than last quarter, answer with dwell time, and when the CFO asks what the next $400K buys, the maturity gap analysis is exactly the right answer. Pair them, and stop substituting one for the other.
Frequently asked questions about SOC maturity models
What does a SOC maturity model like SOC-CMM actually measure?
SOC-CMM scores maturity across five domains (business, people, process, technology, and services) and scores capability only in the technology and services domains. Maturity measures how well things are organized on a 0-5 scale; capability measures what the SOC delivers as output. It captures process consistency, technology inventory, staffing, and service scope, and it leaves time-to-detect, dwell time, tested coverage, and escaped-alert rate outside the score.
Can a SOC score high on maturity and still miss a real intrusion?
Yes, and the two facts are fully consistent. The maturity score measures whether a capability exists and how well it is documented, while under-load performance requires separate testing. A detection engineering process can score level 4 for being systematically measured while the detections themselves have silently broken as configurations drifted.
What outcome metrics should a SOC report for performance?
Report mean time to detect, mean time to contain, dwell time, tested detection coverage against your priority ATT&CK techniques, and false-negative or escaped-alert rate. These move when the SOC gets better or worse at its actual job. Segment containment time by incident class and frame it in business terms for board reporting.
Is a SOC maturity model still worth using?
Yes, as a gap-assessment scaffold and a roadmap-communication tool. It gives a structured, repeatable way to find capability gaps and a common language for justifying budget to non-technical leadership. The failure is treating the score as a performance metric, so keep it for the roadmap layer and report outcomes separately.
How does Goodhart's Law apply to SOC maturity scores?
Goodhart's Law says that when a measure becomes a target, it stops being a good measure. Once the board tracks the maturity number, teams get pressure to raise it, and raising it is easy: buy tools to fill inventory gaps, or document processes nobody runs. Those actions raise the score without reducing risk, so spend flows toward the number rather than toward closing detection gaps or shrinking dwell time.