What Security Maturity Actually Looks Like
By Domenic DiNatale
The CMMI-based security maturity model says you're at Level 3 — defined, documented, consistently applied. The SOC 2 audit is clean. The NIST CSF assessment puts you solidly in the "manage" tier. On paper, your security program is mature.
Then an attacker spends six weeks in your environment before anyone notices.
Maturity models measure what they're designed to measure: the existence and consistency of processes. They're useful instruments. A Level 1 organization genuinely is more exposed than a Level 4 organization, in general. Frameworks give security programs a structure for improvement and give leadership a legible way to communicate about security investment. These are real benefits.
But there's a subtle and important difference between optimizing for a maturity score and building genuine security resilience. Organizations that conflate the two end up with programs that score well on assessments and fail in practice. The score becomes the goal, and the gap between documented capability and operational reality grows unexamined.
What the Models Miss
Maturity models tend to measure the existence and consistency of security practices — do you have a vulnerability management program, an asset inventory, an incident response plan, defined roles and responsibilities. These are inputs, and they're meaningful inputs. But the models generally don't evaluate whether those inputs are producing the security outcomes you actually need.
A vulnerability management program that scans quarterly and remediates on a 90-day SLA looks mature in a framework assessment. It's also significantly less effective than one that scans continuously and treats critical vulnerabilities in internet-facing systems as P1 incidents. The process exists in both cases. The operational effectiveness is completely different.
An incident response plan that was written two years ago and reviewed annually checks the maturity model box. A team that runs realistic simulations quarterly and has refined their playbooks based on actual drill findings is operating at a fundamentally different level. The framework scores them similarly. Their actual readiness is not similar.
This gap — between process existence and operational effectiveness — is where mature-looking organizations get breached and are genuinely surprised. The processes said everything was working. The operational reality was different.
The Score-Optimization Problem
When a maturity score becomes an organizational goal rather than a measurement, a predictable distortion follows. Security investments get directed toward improving the score rather than improving outcomes. Teams spend cycles on documentation, formalization, and governance artifacts — the things frameworks measure — at the expense of detection fidelity, response capability, and architectural improvement.
This isn't malicious. It's rational within the incentive structure. If the CISO is being evaluated on achieving a maturity level, the optimal path is to get to that level as efficiently as possible. Documentation and process formalization are more tractable than the harder work of improving detection quality or redesigning network architecture. So that's where the investment goes.
The tell is when security programs can answer "do we have this process?" in detail but struggle to answer "did this process catch anything last quarter?" The former is what maturity models ask. The latter is what actually matters.
What Operational Maturity Looks Like
Genuine security maturity is visible in how organizations behave under operational conditions, not how they perform in assessments. A few markers that distinguish operational maturity from documented maturity:
Detection is calibrated, not just configured. The SIEM is running. But the team knows the signal-to-noise ratio of their alert stack, has worked to reduce false positive volume, and can tell you with confidence which alert categories produce actionable findings and which are background noise. They're not just collecting data — they're maintaining a functioning early warning system.
Incidents generate improvement. Every significant security event — whether or not it meets the technical definition of a breach — is treated as a source of information about what the architecture allowed and what the process missed. Post-mortems happen and produce changes. The organization's security posture improves as a function of operational experience, not just as a function of framework progression.
The response capability has been tested under realistic conditions. Not tabletops only — actual exercises that stress coordination, information availability, and decision-making under pressure. The team knows what breaks in their response process because they've broken it intentionally, in a controlled context, before an attacker had the opportunity to break it in an uncontrolled one.
The security team understands the architecture. Not at an abstract level — they know specifically which systems are most critical, which trust relationships create the most risk, where segmentation is strongest and weakest, and what the blast radius of a specific compromise would look like. This knowledge exists in people, not just in documentation.
Maturity as Measurement, Not Destination
The reframe is straightforward but requires discipline to maintain: maturity models are measurement tools, not destinations. They're useful for benchmarking, for communicating progress to leadership, and for identifying gaps against a reference framework. They're poor guides to security investment when treated as goals in themselves.
The destination is a security program that performs under adversarial conditions — one where incidents are detected at an early stage, where damage is contained by architectural properties that limit lateral movement, where response is practiced and coordinated, and where every failure produces genuine organizational learning.
Some of those properties will score well on maturity assessments. Some won't map directly to framework criteria at all. The architecture question — "what can an attacker actually do if they get in?" — is rarely well-captured by maturity models that focus on process existence rather than structural security properties.
Mature security looks less like a document library and more like a system that gets better when things go wrong. That's not what most frameworks are measuring. But that's what survives contact with real adversaries.
This post is part of a series on security as an architectural problem. Read the full series on the Intellitech blog.