An immature program usually shows up as minimal budgets, generic yearly training, heavy dependence on spreadsheets, and a narrow focus on click rates or other isolated metrics. If phishing simulations, automation, and role-based targeting are limited, the organisation is probably measuring activity more than managing risk, which leaves behavior change largely untouched.
How immaturity shows up in the program design
An immature human risk management program usually looks like a communications function with security language around it, rather than a measured behaviour-change programme. The signs are easy to spot: one-size-fits-all training, annual refreshers that are treated as compliance events, and activity metrics that do not explain whether risky decisions are changing.
Another signal is weak targeting. If the same message goes to everyone, from frontline staff to high-risk roles, the programme is not using role context, exposure, or business process to shape intervention. That usually means the team is optimising for completion rates and training coverage instead of reducing meaningful human error pathways.
Imaturity also appears in tooling and operating model choices. Heavy spreadsheet dependence, fragmented ownership, and manual campaign execution make it hard to adapt quickly, test interventions, or connect human-risk data to broader security operations. When the programme cannot show who is at risk, what changed, and whether the change lasted, it is still at a basic stage of maturity.
If the organisation is already investing in phishing simulations or behaviour nudges, the key question is whether those controls are tied to actual risk patterns and outcomes. You can read that shift from programme activity to risk management in the way intervention design becomes more specific over time, especially when response is aligned to role, scenario, and observed behaviour rather than a single generic message. For a lifecycle and governance view of that problem space, see NHI Mgmt Group’s Ultimate Guide to NHIs and the Top 10 NHI Issues as a useful comparison for how immature programmes often stay stuck at visibility and activity rather than control and accountability.
What the operational signals usually reveal
Immature programmes tend to rely on a narrow set of indicators, usually click rates, training completion, or campaign participation. Those numbers are not useless, but they become misleading when they are treated as the end goal. A low click rate can coexist with poor reporting behaviour, weak escalation discipline, or repeated exposure in the same high-risk workflows.
A stronger programme can explain not just whether someone clicked, but whether the organisation learned anything actionable from the event. If the team cannot segment by role, department, or threat scenario, then the programme is not yet mature enough to prioritise interventions. That gap often shows up as little evidence of experimentation, very little use of automation, and no credible feedback loop from incidents back into awareness design.
The operational test is whether the programme can distinguish noise from real exposure. Mature teams can say which groups need different treatment, which messages changed behaviour, and which risks persist despite repeated contact. Immature teams usually can only report that a campaign ran and that a percentage of recipients interacted with it.
Programs that are stuck at this stage often need a more structured evidence base. General guidance from the NCSC UK Advice and Guidance is useful here because it reinforces the need to connect awareness work to real operational controls, not just awareness outputs. If the evidence never moves beyond completion and click-through reporting, the programme is still operating as an awareness tracker rather than a risk-reduction function.
Risk and Threat Considerations
An immature human risk management programme creates predictable exposure because it fails to reduce the behaviours that attackers rely on most. When the organisation measures attendance or clicks instead of decision quality, phishing, social engineering, and policy bypass risks can persist even though the programme appears active.
Failure mechanism: control design stays generic, so the organisation does not change risky behaviour in the roles, processes, or scenarios where mistakes matter most. That leaves recurring exposure in the same places, while the reporting layer suggests progress that the control layer has not actually earned.
Impact: the organisation may keep funding training and campaigns without reducing likelihood of credential theft, fraudulent approval, data mishandling, or repeated human error in business-critical workflows. Over time, that gap weakens both security confidence and executive trust in the programme.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST CSF 2.0 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | GV.RM-01 — Risk Management Strategy | Human-risk programs need a risk-based strategy tied to outcomes, not activity counts. |
| GV.OV-01 — Cybersecurity Governance | Program immaturity often shows weak ownership, accountability, and oversight. | |
| PR.AT-01 — Awareness and Training | The subject directly concerns the maturity of awareness and training efforts. | |
| Recommendation — Tie awareness work to explicit risk outcomes and track whether interventions reduce exposure. Assign clear ownership for human-risk metrics, interventions, and escalation paths. Move beyond annual training by targeting learning to role, scenario, and observed behaviour. | ||
| CIS Controls v8 | 14 — Security Awareness and Skills Training | CIS Control 14 directly addresses security awareness and skill development maturity. |
| 17 — Incident Response Management | Human-risk programs should feed observed behaviour into response and escalation workflows. | |
| Recommendation — Measure training effectiveness by behavioural change, not only completion. Use user-reported events and incident lessons to refine human-risk interventions. | ||
Practitioner Guidance
What to verify: ask whether the programme can name the high-risk populations, the behaviours it is trying to change, and the evidence that the change persisted beyond the latest campaign. If it cannot show role-specific outcomes, the programme is probably still at a reporting stage.
What to prioritise: build a small number of interventions around the highest-exposure roles and scenarios first, then prove whether those interventions change reporting, escalation, or error rates. Broad training only becomes useful once the team can show why a group needs that intervention and what success looks like.
Practitioner takeaway: an immature programme is not defined by a lack of activity, but by a lack of evidence that activity is changing risk in the places that matter most.
Related resources from NHI Mgmt Group
- What breaks when organisations rely on phishing simulations without a broader human risk management program?
- What are the signs that a vendor risk management program is failing?
- What are the signs that an enterprise risk program is failing to operate as a management tool?
- What are the signs that a human risk program is failing to surface the right employees?