Back to blog
GRC Fundamentals

Security maturity models: why "implemented" is only halfway

Maturity scoring appears in SAMA CSF, HITRUST and many internal programmes. What the levels mean, why most organisations plateau at the middle, and how to climb without inventing bureaucracy.
GRC Copilot Team
Security maturity models: why "implemented" is only halfway

A maturity model scores how well established a practice is, not merely whether it exists. That difference explains a result that surprises many organisations: a control can be fully implemented, working perfectly, and still score in the middle of the scale.

The typical levels

Wording varies between models, but the progression is remarkably consistent:

  1. 0 - Non-existent. Nothing happens; nobody owns it.
  2. 1 - Ad hoc / initial. It happens sometimes, driven by individuals rather than process. Results depend on who is available.
  3. 2 - Repeatable but informal. A consistent way of doing it exists in practice, but it is not documented or approved. It survives a busy week; it does not survive a resignation.
  4. 3 - Defined and formalised. Documented, approved, communicated and consistently applied across scope. Most organisations stop here.
  5. 4 - Managed and measurable. Effectiveness is measured with metrics, and results are reported to management periodically.
  6. 5 - Optimised / adaptive. Measurement drives continual improvement; the practice adapts to changing threats.

Why the plateau at level 3 is so common

Levels 1 to 3 are about doing the thing properly, which security teams are good at. Level 4 is about proving it works over time, which is a governance activity most teams never set up. The jump requires:

  • Defining what "effective" means for the control, numerically.
  • Collecting that measure on a schedule.
  • Reporting it to management, with trends.
  • Retaining the reports as evidence.
Nothing in that list is technical. It is the cheapest maturity increment available - and the one most likely to be dismissed as bureaucracy right up until an assessor caps your score at 3.

Score maturity from real evidence

GRC Copilot scores controls against maturity models like SAMA CSF, shows exactly which level each sits at, and highlights where measurement is the missing step.

Where you will meet maturity scoring

  • SAMA CSF - six levels, with level 3 the usual baseline expectation and higher levels for critical controls. Measurement is explicitly what separates 3 from 4.
  • HITRUST CSF - scores across policy, procedure, implemented, measured and managed dimensions, so a certifiable total requires the upper dimensions.
  • Internal programmes - many organisations adopt a CMMI-style scale voluntarily to show progress over time.
  • NIST CSF tiers - a related but distinct concept describing the rigour of risk management practices rather than per-control maturity.

Note the contrast with implementation scoring: the NCA ECC asks whether a control is implemented; SAMA asks how mature it is. The same control, the same evidence, two different questions - which is why organisations subject to both should score twice from one evidence base rather than running two programmes.

Climbing deliberately

  1. 1 to 2: agree one consistent way of doing it. No documentation needed yet - just stop improvising.
  2. 2 to 3: document it, get it approved, communicate it, and apply it across the whole scope. Partial scope coverage keeps you at 2.
  3. 3 to 4: define a metric, measure on a cycle, report to management, keep the reports.
  4. 4 to 5: act on the measurements - show a decision or change that came from the data, and a threat-driven adjustment.

Choosing target levels honestly

Level 5 everywhere is neither achievable nor sensible. Target by criticality:

  • Controls protecting critical services or regulated data - level 4, sometimes 5.
  • Most controls - level 3.
  • Low-risk supporting controls - level 2 or 3 may be proportionate.

An organisation claiming uniform level 4 across every control is usually either misunderstanding the model or scoring itself generously - and assessors probe exactly that.

The honest limitation

Maturity measures process discipline, not security outcomes. A mature process can institutionalise a weak control - consistently, measurably, and with excellent reporting. Use maturity alongside risk assessment and adversarial testing, never instead of them.

Frequently asked questions

Is level 5 the goal?

Rarely, and not everywhere. Target by criticality; the cost of sustaining level 5 across a whole control set outweighs the benefit for most organisations.

Can we self-assess maturity?

Yes, and you should - but self-assessment drifts generous. Score against evidence and have someone independent challenge the higher scores.

What is the single fastest way to raise our score?

Add measurement and periodic reporting to controls already at level 3. It requires no engineering and unlocks the level most programmes are stuck below.

Does ISO 27001 use maturity levels?

Not for certification - it is conformity-based. But its requirement for monitoring, measurement, analysis and evaluation is effectively the level 4 discipline under a different name.

Key takeaways

  • Maturity scores how established a practice is, not whether it exists.
  • Most organisations plateau at 3 because measurement is never set up.
  • The 3-to-4 step is governance, not engineering - the cheapest gain available.
  • Maturity is process discipline; it does not prove the control is the right one.
#maturity #cmmi #sama-csf #hitrust #measurement