An early-stage maturity programme usually shows up as reactive work, undocumented procedures, and inconsistent follow-through. Different teams may handle the same task in different ways, and performance is rarely measured in a structured way. When that happens, the organisation has limited visibility into what is working, what is failing, and where improvement will have the biggest impact.
What early-stage maturity looks like in practice
An early-stage IT maturity programme is usually defined by inconsistency more than by a single missing control. Work is handled reactively, the “same” process varies by team, and people rely on individual habits instead of a shared operating model. That creates local success in pockets, but little repeatability across the organisation.
One of the clearest signs is that the programme cannot yet describe itself in measurable terms. If teams cannot state what gets done, by whom, how often, and with what evidence, then maturity is still being managed through memory and escalation rather than through defined practice. That is often the point where a maturity programme is still closer to coordination than governance.
How to tell the difference between ad hoc and managed
Early-stage programmes tend to show the same operational pattern: undocumented procedures, inconsistent handoffs, and weak follow-through when work crosses team boundaries. A task may be completed, but not the same way twice. That means the organisation can rely on people, but not yet on the process itself.
Another sign is that performance indicators are absent, partial, or too anecdotal to support decisions. If leaders cannot compare current-state execution against an agreed baseline, they do not yet have a maturity model in the practical sense. They have activity, but not control. In maturity terms, the absence of a shared OWASP SAMM style of measurable progression is often the difference between an evolving programme and a purely informal one.
Where the organisation depends on manual coordination, the signs become even clearer. Controls may exist in intent, but exceptions are handled case by case, ownership is unclear, and the same issue reappears because no one has converted the lesson into a durable standard. That is a classic early-stage pattern: the programme is still proving it can run once, not yet proving it can run consistently.
Why visibility is the main limiting factor
At an early stage, visibility is usually the real constraint. Leaders can sense that work is slow or uneven, but they cannot reliably tell whether the problem is process design, execution quality, resourcing, or ownership. Without structured measurement, the programme lacks the evidence needed to prioritise the next improvement that will matter most.
This is why maturity assessments are most useful when they separate symptoms from operating reality. A team may appear productive while repeatedly compensating for undocumented workarounds, while another may look slower simply because it follows a more disciplined process. The maturity question is not whether work is happening, but whether the organisation can explain, repeat, and improve how it happens.
For that reason, a useful early checkpoint is whether the programme can inventory its key processes, show who owns each one, and demonstrate whether outcomes are being measured in a comparable way. If it cannot, the programme is still at the stage where its biggest gain will come from basic standardisation rather than from optimisation.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP SAMM, NIST CSF 2.0 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP SAMM | Software Assurance Maturity Model | Maturity programmes need measurable progression and repeatable practice design. |
| Recommendation — Use SAMM to define current-state gaps and set the next maturity target. | ||
| NIST CSF 2.0 | GV.RR-01 — Organizational Context | Early-stage programmes lack clear ownership, repeatability and defined operating context. |
| Recommendation — Define process ownership and operating context before expanding controls. | ||
| CIS Controls v8 | CIS-8 — Audit Log Management | Structured measurement and evidence collection are core signs of control maturity. |
| Recommendation — Establish consistent evidence and logging so execution can be measured and reviewed. | ||
Practitioner Guidance
What to prioritise: Start with the handful of processes that are most frequent, most visible, or most failure-prone. Maturity work should first reduce variation in the areas where inconsistency creates the most operational drag, not spread thinly across every possible activity.
What to verify: Ask whether each core process has a named owner, a documented sequence, and a repeatable way to prove it happened. If the answer depends on tribal knowledge or informal reassurance, the programme is still immature regardless of how much effort is being spent.
Common mistake: Treating policy publication as maturity. A written procedure that nobody follows consistently is not evidence of maturity, it is evidence that the programme has not yet crossed from documentation to dependable execution.
Practitioner takeaway: Early-stage maturity is best recognised by the gap between intent and repeatability, if the organisation cannot measure, compare, and explain execution, it is still building the basics of control.
Related resources from NHI Mgmt Group
- What are the signs that a PAM programme is still in an early maturity stage?
- What are the signs that a security automation programme is still at the enriched visibility stage?
- What are the signs that a PKI programme is still operating in a reactive stage?
- When does a short-lived API key still create material risk?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 28, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
