How do organisations implement Capability Maturity Model?

What a maturity model is really measuring

A capability maturity model is not a scorecard for its own sake. It gives an organisation a structured way to judge whether a process is ad hoc, repeatable, defined, managed or optimised, then compare that current state with a target state. The value comes from making process capability visible enough to prioritise investment, not from the label on the maturity level.

In practice, this means the organisation must define what “good” looks like for the specific process under review, agree the evidence that proves it, and apply the same yardstick consistently over time. Maturity is therefore a control-and-governance conversation as much as it is an assessment exercise.

For teams building the model, the central question is whether the maturity levels describe observable behaviour. A useful model ties each level to clear evidence such as policy, ownership, metrics, review cadence, exception handling and outcome tracking, so the assessment is based on what the organisation can actually demonstrate rather than self-attested confidence. The strongest models are those that can be reassessed without changing the scoring logic each cycle.

How organisations implement the model without turning it into theatre

Implementation usually starts by selecting the process or domain to assess, such as identity governance, third-party risk, incident response or software delivery. The next step is to define the maturity dimensions that matter for that process, then describe each level in operational terms so assessors can distinguish between a basic control and a consistently managed capability. GRC Maturity Model is a useful reference point for structuring those dimensions around risk appetite, evidence and roadmap discipline.

The model then needs an assessment method. That usually means collecting artefacts, interviewing owners, sampling records and comparing actual practice against the defined level criteria. The assessment should identify both the current maturity level and the gaps preventing the next one, because the purpose is to turn measurement into a prioritised improvement plan rather than a static rating.

Good implementation also separates process maturity from tool presence. A team can own a platform, automate parts of a workflow or produce reports and still remain immature if decisions are inconsistent, exceptions are unmanaged or evidence is not trusted. That is why organisations often pair the maturity model with a roadmap that sequences improvement work by risk and operational dependency, not by what is easiest to automate first.

Where maturity models fail in security programmes

Maturity programmes tend to fail when they measure activity instead of capability. An organisation can collect dashboards, run workshops and publish a level without proving that controls are repeatable, owned and reviewed. The result is a comforting label that does not survive audit, incident review or board challenge.

Another common failure is inconsistent scoring across teams. If identity, third-party and operational processes are assessed with different assumptions, the model stops being comparable and becomes a set of unrelated opinions. A mature programme needs defined evidence standards, calibration between assessors and a regular review cycle so the score remains stable enough to track progress.

The third failure mode is treating the model as a one-time project. Maturity only has meaning if reassessment is scheduled, remediation is tracked and the target state is adjusted when risk changes. That is especially important where security controls depend on external parties, shared services or identity-driven workflows, because drift in those areas can quickly invalidate an earlier assessment.

Practitioner Guidance

What to prioritise: Start with one process that has clear business and security consequences, then define maturity levels using evidence the team can actually produce. If you cannot show the artefacts for a level, the level is not operationally real.

What to verify: Check that scoring is based on repeatable practice, not policy existence or tool deployment. The best test is whether a different assessor would reach the same conclusion from the same evidence set.

Decision rule: If a maturity gap maps to material risk exposure, treat it as an improvement backlog item with ownership and due dates. If the gap is mostly cosmetic, do not let it displace controls that reduce real operational or security exposure.

Practitioner takeaway: A useful maturity model makes current practice measurable, target state explicit and remediation prioritised. If it cannot drive those three outcomes, it is probably a reporting exercise rather than a management control.

Related resources from NHI Mgmt Group

• How do organisations operationalise NHI ownership at scale?
• When should organisations treat an NHI as a high-priority risk?
• How can organisations reduce the blast radius of compromised agent identities?
• Should organisations prioritise external exposure or internal credential governance first?