Many organisations can prove that every employee completed security training, yet cannot say whether anyone behaves more securely as a result. This model, using NHI Mgmt Group's five levels (Ad hoc, Developing, Defined, Managed and Optimised), describes how a security awareness programme grows from a compliance exercise into one that measurably changes behaviour. It scores six capability areas, including two that most programmes neglect: developers who handle secrets and staff using AI tools. It is for awareness leads, CISOs and auditors who need an honest current-state score and a target. To write the programme itself, use the Security Awareness Plan Template.
Key takeaways
- Five levels: Ad hoc, Developing, Defined, Managed and Optimised, scored separately for each capability area.
- Completion is Level 2 evidence: a training record shows attendance; higher levels need evidence of behaviour, such as report rates and self-reported mistakes.
- Culture caps maturity: a programme that names or disciplines people who click cannot pass Level 3, because fear suppresses the reporting every higher level measures.
- Technical audiences count: developers and AI tool users carry credential and data risks that generic modules do not address.
- Level 3 is a sensible first target: segmented audiences, a written plan, no-blame simulations and reporting-led metrics.
The five levels
| Level | Name | What it looks like |
|---|---|---|
| 1 | Ad hoc | Training happens when an auditor or customer asks. One generic module, no owner, no reporting route beyond forwarding to IT. Incidents are the only feedback. |
| 2 | Developing | An annual module and onboarding training exist, completion is tracked, and phishing simulations run. Click rate is the main metric and repeat clickers may be singled out. |
| 3 | Defined | A written annual plan with segmented audiences, role-based paths (finance, service desk, developers, admins, AI users), a report button with feedback, and a published no-blame commitment. Report rate leads the metrics. |
| 4 | Managed | Content is driven by real lures and incidents, campaign difficulty is rated so results compare like for like, behaviour metrics are reported to leadership, and training is paired with technical controls such as secret scanning and phishing-resistant MFA. |
| 5 | Optimised | Staff act as an early-warning network: reports feed detection in minutes, people readily report their own mistakes, and the programme adapts continuously to new threats such as deepfakes and AI agents. |
Capability areas
| Area | Level 1 Ad hoc | Level 3 Defined | Level 5 Optimised |
|---|---|---|---|
| Strategy and ownership | No plan or owner | Annual plan approved by leadership, named owner, budget | Plan reviewed against risk register and incident trends; leaders model behaviour |
| Audiences and content | One module for everyone | Role paths for higher-risk groups; content refreshed after incidents | Content generated from current threat intelligence and staff reports, localised and accessible |
| Simulation and practice | None, or ad hoc tests | Scheduled, no-blame simulations with HR and legal sign-off; non-email exercises | Difficulty-rated campaigns, tabletop and voice exercises, staff help design lures |
| Reporting culture | Unclear how to report; fear of blame | One-click reporting, acknowledgement of every report, no-sanction statement | Reports triaged automatically and fed to detection; self-reporting of mistakes is normal |
| Developers and secrets | Not covered | Secrets handling module; staff know how to respond to a push protection block and report an exposed key | Time from exposure to revocation measured in hours; training tied to scanning results |
| AI tool use | Not covered; shadow AI unknown | Approved tools list, data rules and AI module before access | Unapproved AI use monitored and falling; staff recognise prompt injection and deepfake requests |
Why culture sets the ceiling
The UK NCSC advises that blaming users does not change the reasons people click, such as stress or distraction, and that fear of reprisal stops people reporting mistakes promptly or at all. NIST SP 800-50 Rev. 1 likewise states that phishing exercises should not be punitive and that no employee should be called out. In this model, any programme that uses simulation results for discipline or names individuals is capped at Level 2 in every area, whatever its other strengths.
Evidence for each level
| Level | Acceptable evidence | Not sufficient on its own |
|---|---|---|
| 2 Developing | Completion records, simulation results | Policy documents |
| 3 Defined | Approved plan, audience mapping from HR data, report button usage, published no-blame statement | Completion rate above 95% |
| 4 Managed | Trend of report rate and time to first report against rated difficulty; board reporting; controls paired with modules | Falling click rate |
| 5 Optimised | Staff reports that triggered containment; rising self-reported mistakes; measured revocation time for exposed keys | Awards or vendor benchmarks |
Self-assessment questions
Score each area at the level where every statement is true across the whole workforce, not a pilot team.
- Strategy: is there an approved plan with an owner, and when did leadership last see behaviour metrics rather than completion figures?
- Audiences: can you list which roles get extra training, and is that list driven by HR or identity data so it stays current?
- Simulation: have HR and legal approved the rules, and could anyone be disciplined or named because of a simulated phish?
- Reporting: how long does a reporter wait for acknowledgement, and do staff believe they can report a click without consequences?
- Measurement: do you record campaign difficulty, and is report rate shown before click rate?
- Developers: would a developer who committed an API key know to rotate it, not just delete the line, and whom to tell within the hour? In the xAI API key leak, a scanner alerted the developer the same day, but the key stayed valid for about two months.
- AI tools: do staff know which AI tools are approved and which data must never be entered? The Samsung ChatGPT leak shows how quickly source code reaches a public tool when rules lag adoption.
- Impersonation: do finance staff verify payment requests by a second, known channel even after a convincing video call, unlike in the Arup deepfake fraud?
Moving up: roadmap
From Ad hoc to Developing
- Name an owner, deploy onboarding and annual baseline training, and record completion.
- Publish one simple way to report suspicious messages.
From Developing to Defined
- Write an annual plan with audiences and role paths. See the Security Awareness Plan Template.
- Remove any link between simulation results and discipline, and say so publicly.
- Add the developer secrets module and the AI tools module. See the Shadow AI Policy Template.
- Switch headline metrics to report rate and time to first report. See the Phishing Simulation Programme Guide.
From Defined to Managed
- Rate every campaign's difficulty (SP 800-50 Rev. 1 points to the NIST Phish Scale) and compare like with like.
- Pair each module with a control: phishing-resistant MFA, secret scanning and push protection, an approved enterprise AI tool. See the Phishing-Resistant MFA Guide.
- Add voice, SMS and deepfake exercises for finance and executives. See the Deepfake and AI Impersonation Guide.
From Managed to Optimised
- Route staff reports into detection so a reported lure can trigger mailbox-wide removal. See the Phishing Incident Response Playbook.
- Track self-reported mistakes and exposed-key revocation time as leading indicators of trust.
- Review content each quarter against new attack patterns, including AI agent misuse.
Practitioner checklist
- Score all six capability areas separately and record the evidence for each score.
- Check for any blame-based practice; if present, cap the score at Level 2 and fix it first.
- Confirm developers and AI tool users have their own learning paths.
- Report report rate, time to first report and real phish reports ahead of click rate.
- Record campaign difficulty for every simulation.
- Map the programme to NIST SP 800-53 AT-2, AT-2.1, AT-3 and AT-4 and NIST CSF 2.0 PR.AT-01 and PR.AT-02.
- Set a target level per area for the next 12 months and reassess annually.
Standards and references
- NIST: SP 800-50 Rev. 1, Building a Cybersecurity and Privacy Learning Program
- NIST: SP 800-53 Rev. 5
- NIST: Cybersecurity Framework 2.0
- NCSC: Phishing attacks, defending your organisation
- NCSC: Cyber security culture principles
- NCSC: Telling users to avoid clicking bad links still isn't working
- CISA: Secure Our World
- GitHub Docs: About push protection
Related NHI Mgmt Group resources: Security Awareness and Human Risk Management Guide · Security Awareness Plan Template · Phishing Guide · Security Awareness Training Buyer's Guide