Crawl, Walk, Run Maturity Model

What the crawl, walk, run model changes in practice

The crawl, walk, run maturity model is not just a project slogan. It gives teams a deliberate sequence for introducing new controls, starting with a contained rollout, then broadening scope as the operating model, tooling, and ownership become stable enough to support it.

That sequencing matters because many security programmes fail at the handover point, where a control is technically sound but too disruptive to adopt at scale. In access control work, phased rollout helps teams avoid sudden friction for application owners while still moving toward a stronger target state.

Why phased maturity works for security programmes

The model works because it reduces both technical and organisational risk. Early phases expose hidden dependencies, reveal gaps in process and integration, and make it easier to learn what the control really costs to operate before the organisation commits to full rollout.

It is especially useful where the control affects many systems at once, such as identity, access, logging, or policy enforcement. A crawl stage creates a limited proof point; a walk stage tests repeatability; a run stage confirms that the programme can sustain the control without constant manual intervention.

That logic is closely related to maturity-based security roadmaps such as OWASP SAMM, which also treats security capability as something that should be built progressively rather than switched on all at once.

Where the model is most useful

The crawl, walk, run pattern is most effective when the target capability touches operating teams that must absorb change, not just approve it. That includes access control programmes, governance changes, cloud guardrails, security monitoring, and other controls that require coordination across owners, engineers, and support teams.

It is also helpful when the organisation needs evidence before scaling. A small deployment can show whether the control improves security outcomes, whether users work around it, and whether the process can be measured and supported. If those questions are not answered early, a broad rollout can create resistance that is hard to reverse.

For programmes that are really about security capability, an identity-focused rollout can benefit from a wider maturity lens such as Identity Security Maturity Model, which frames staged progress across identities, entitlements, and governance rather than treating implementation as a single event.

What good implementation looks like

Good use of the model means each phase has a real purpose. Crawl should prove the control can work in a constrained environment. Walk should test scale, repeatability, and supportability. Run should mean the control is embedded enough that it can be governed, measured, and improved like a normal operational capability.

That does not mean every team must move at the same pace. A phased model should be used to manage adoption, not to create indefinite delay. If the organisation never defines what success looks like at each stage, the model becomes an excuse for half-finished deployment rather than a path to maturity.

In practice, this is why maturity programmes often pair phased rollout with a roadmap, like the approach used in GRC Maturity Model, where staged progress is tied to assessment, evidence, and measurable improvement.

Risk and Threat Considerations

The main risk is mistaking partial rollout for operational maturity. If a team expands too quickly, controls can be inconsistent across environments, workarounds can become normalised, and ownership can remain unclear. In security programmes, that creates exposure where the control appears to exist but does not yet behave reliably everywhere it matters.

Failure mechanism: Incomplete rollout can leave a split environment where some systems are protected and others are not, or where policy is enforced unevenly enough that users route around it. That gap is especially dangerous in access control, because inconsistent enforcement often looks acceptable in testing but fails under real operational pressure.

Impact: The result can be fragmented governance, weaker assurance, and a false sense of control effectiveness. In the worst case, the organisation scales a fragile design, then discovers that exceptions, manual handling, or ownership gaps have already become embedded at enterprise level.

Practitioner Guidance

Why practitioners should care: The model is most valuable when it is treated as a governance tool, not just a delivery pattern. Each stage should answer a different question, from “does it work here?” to “can we operate it repeatedly?” to “is it ready for normal business use?”

Common misunderstanding: Teams often assume crawl, walk, run means doing less security work at the beginning. In reality, the early phase should be the most scrutinised, because it sets the design, ownership, and operating assumptions that later phases inherit.

Practitioner takeaway: Define the exit criteria for each phase before rollout begins, otherwise the maturity model becomes a label for gradual deployment rather than a disciplined path to sustained control.

Related resources from NHI Mgmt Group

• Crawl, Walk, Run
• What is the difference between the crawl, walk, and run phases in a cloud migration programme?
• How do organisations keep governance strong when they run a hybrid authentication model?
• What is the difference between maturity and compliance in the Essential Eight model?