Most security awareness programmes fail not because staff are careless but because the programme measures the wrong things, trains everyone the same way and punishes the very behaviour it needs, which is reporting. This page ranks the ten mistakes we see most often in awareness programmes, each with what goes wrong, how to spot it in your own programme and the fix. It draws on the UK NCSC phishing guidance, which says plainly that blaming users for clicking does not work, and on NIST SP 800-50 Rev. 1, Building a Cybersecurity and Privacy Learning Program, published in September 2024. It is for awareness leads, CISOs and HR or L&D partners running or rescuing a programme. To score where your programme sits overall, use the Security Awareness Maturity Model; this page is the list of what usually goes wrong on the way up. The ranking is our editorial judgement of impact and frequency, not a survey result.
The Top 10 at a glance
| # | Mistake | Typical symptom | First fix |
|---|---|---|---|
| 1 | Measuring completion and click rate instead of reporting | 100% completion, flat incident numbers | Make report rate and time to report the headline metrics |
| 2 | Blaming and punishing people who click | Reports drop after a "clicker" email from HR | Written no-blame reporting commitment backed by HR and leadership |
| 3 | Treating training as the main phishing control | Training budget grows, email and MFA controls lag | Layered defence: filtering, DMARC, phishing-resistant MFA, then people |
| 4 | One annual course for everyone | Finance, help desk and admins get the same video as everyone else | Role-based modules for high-risk roles |
| 5 | Gotcha phishing simulations | Complaints, workarounds, staff warning each other | Simulations agreed with HR, used to teach, never to shame |
| 6 | A reporting route that is hard to use or never answers | Suspicious mail forwarded to random people, or deleted | One-click report button, fast triage, feedback to the reporter |
| 7 | Training only email phishing | Phone, SMS, QR and help desk attacks succeed | Cover voice, SMS, QR codes, MFA prompts and callback scams |
| 8 | Asking people to follow processes that make the secure action hard | Staff "know" the rule but bypass it under time pressure | Fix the process: verification steps, out-of-band call-backs |
| 9 | No executive ownership or visible leadership | Executives exempt from training and simulations | Named board sponsor, executives trained first and visibly |
| 10 | Never updating content or reviewing the programme | Same slides for three years, no lessons from incidents | Quarterly content refresh from incidents and threat intelligence |
Items 1 and 2 decide whether people report at all; items 3 to 5 are about where training effort goes and who it reaches; items 6 to 8 are about whether the secure action is easy to take; items 9 and 10 decide whether the programme is owned and kept current.
1. Measuring completion and click rate instead of reporting
What goes wrong: the programme reports course completion percentages and phishing simulation click rates to the board because they are easy to collect. Completion proves attendance, not behaviour. Click rate depends heavily on how hard the lure was, so it can be pushed up or down at will, and it says nothing about whether anyone told the security team.
How to detect it: look at your last quarterly report. If the top line is completion or click rate and there is no figure for how many real suspicious messages staff reported, or how fast, you have this problem.
The fix: the NCSC phishing guidance recommends measuring reports as well as clicks, so people are not discouraged from speaking up. NIST SP 800-50 Rev. 1 builds metrics and evaluation into the learning programme life cycle so the programme is improved on evidence. Move to behaviour and outcome measures:
- Report rate: share of a simulated or real campaign's recipients who reported it.
- Time to first report: minutes from delivery to the first user report; this is what lets the SOC pull a live campaign from every mailbox.
- Real-threat report share: proportion of confirmed malicious messages that were first spotted by a user rather than a tool.
- Repeat-susceptibility trend: whether the same people keep falling for lures, used to target support, not discipline.
See the Phishing Simulation Programme Guide for running campaigns that produce these numbers.
2. Blaming and punishing people who click
What goes wrong: people who click a simulation are named to their manager, sent to remedial training as a penalty, or warned through HR. The NCSC guidance is direct: blaming users for clicking on links does not work, and users who fear punishment are less likely to report mistakes promptly, or at all. A member of staff who clicked a real phishing link and stays quiet for a day is far more dangerous than one who clicked and reported in two minutes.
How to detect it: report volumes fall after a simulation round; staff ask whether reporting "counts against them"; your acceptable use policy lists clicking a phishing link as a disciplinary matter.
The fix: publish a no-blame reporting commitment, signed off by HR and senior leadership, that says reporting a mistake, including a link already clicked, will never lead to discipline. The NCSC recommends exactly this reassurance, supported by HR, support teams and senior management. Thank people who report, publicly where they agree. Reserve disciplinary routes for deliberate policy breaches, not for being fooled.
3. Treating training as the main phishing control
What goes wrong: leadership treats awareness as the answer to phishing, so when a phish succeeds the response is "more training". The NCSC phishing guidance says training is over-emphasised in many phishing defences and that expecting users to spot every phishing email is unrealistic. It sets out four layers: make it hard for attackers to reach users (DMARC, SPF and DKIM, filtering, limiting public information), help users identify and report phishing, protect against the effects of undetected phishing (patching, limited admin rights, blocking malicious sites, multi-factor authentication) and respond quickly to incidents.
How to detect it: post-incident actions that list only "retrain the user"; no phishing-resistant MFA on email or admin accounts; DMARC still at p=none.
The fix: position the awareness programme as layer two of four in every board paper. Pair each training theme with the technical control that catches what people miss. For credential phishing the biggest single reduction comes from phishing-resistant authentication: see the Phishing-Resistant MFA Guide.
4. One annual course for everyone
What goes wrong: every employee watches the same 30-minute module once a year. The finance clerk who can release payments, the help desk agent who can reset MFA and the cloud administrator get the same content as someone with no privileged access. NIST SP 800-53 Rev. 5 separates general literacy training and awareness (AT-2) from role-based training (AT-3), and NIST CSF 2.0 does the same with PR.AT-01 for all personnel and PR.AT-02 for individuals in specialised roles. The NCSC recommends focusing extra support on high-risk roles such as those handling finances or sensitive data.
How to detect it: your LMS has one mandatory security course and nothing assigned by role; the help desk has never been trained on caller verification.
The fix: build a role matrix and assign short, frequent modules:
| Role | Main threats | Content to add |
|---|---|---|
| Finance and payments | Business email compromise, invoice and bank detail changes | Call-back verification on a known number; see the BEC Awareness for Finance Teams Guide |
| Help desk and IT support | Vishing, impersonation of staff for password and MFA resets | Identity verification script and escalation; see the Vishing and Help Desk Social Engineering Awareness Guide |
| Executives and assistants | Whaling, impersonation, deepfake voice | Short briefings and a verification phrase process; see the Security Awareness for Executives and Assistants Guide |
| Administrators and developers | Credential theft, consent phishing, secrets in code | Admin account hygiene, OAuth consent risks, secret handling |
| All staff | Phishing, smishing, QR phishing, MFA fatigue | Spot, stop, report; short monthly nudges |
5. Gotcha phishing simulations
What goes wrong: simulations use lures designed to trick as many people as possible, such as fake bonus or pay-rise emails, fake parcel notices during the holidays, or messages impersonating HR during a restructure. They produce high click rates, angry staff and very little learning. The NCSC guidance warns that simulations can erode trust, can create legal risk if people are punished, and that organisations should check with HR first; it also suggests alternatives such as staff crafting their own phishing emails to learn the techniques.
How to detect it: complaints to HR or works councils after campaigns; staff warning each other in chat channels; click rate swings wildly with lure choice.
The fix: agree a simulation charter with HR, legal and, where relevant, staff representatives. Ban lures that exploit pay, benefits, health or redundancy. Grade lures by difficulty so trends are comparable. Show a short teachable moment on the landing page, and use results to target support, never to rank individuals publicly.
6. A reporting route that is hard to use or never answers
What goes wrong: staff are told to "forward suspicious emails to security" but the address is hard to find, forwarding strips the headers, and nobody replies. People stop bothering. The NCSC recommends a simple, quick reporting process and feedback that shows users their reports matter. NIST SP 800-53 Rev. 5 AT-2(4) covers training people to recognise suspicious communications and anomalous system behaviour, which only pays off if there is a clear route for what they spot; IR-6 covers incident reporting.
How to detect it: measure median time from user report to triage verdict; count reports that never got a reply; ask a sample of staff how they would report a suspicious text message or phone call (most programmes have no route for these at all).
The fix: deploy a report button in every mail client, route reports into the SOC queue with automated verdicts for clear cases, send the reporter a result, and publish one route for suspicious calls and texts. See the Phishing Report Button and User Reported Message Triage Guide.
7. Training only email phishing
What goes wrong: the programme is built around spotting suspicious emails, while attackers have moved to the phone, SMS, collaboration chat, QR codes and MFA push prompts. MITRE ATT&CK tracks this spread: Spearphishing Voice (T1566.004) for initial access, Multi-Factor Authentication Request Generation (T1621) for MFA fatigue, and Phishing for Information (T1598) for reconnaissance. In the Twilio breach, employees received SMS messages pointing to fake sign-in pages; in the MGM Resorts breach, a phone call to the help desk was the way in.
How to detect it: list the channels your last ten real social engineering attempts used and compare them with your training catalogue. If voice, SMS or QR codes appear in the first list and not the second, the gap is visible.
The fix: add modules on vishing, smishing, QR phishing and unexpected MFA prompts, with the single message "if you did not start it, deny it and report it". See the QR Code Phishing (Quishing) Guide and the Callback Phishing (TOAD) Guide.
8. Asking people to follow processes that make the secure action hard
What goes wrong: training tells staff to verify payment changes, but the payment process has no verification step and a target that rewards speed. The help desk is told to verify callers but has no reliable way to do it and is measured on time to resolve. Awareness cannot fix a process that rewards the insecure path. The NCSC suggests making important requests verifiable through a second channel, such as a phone call, and making high-risk processes harder to exploit.
How to detect it: interview a few people in high-risk roles and ask what they would do with an urgent request from a senior manager on a Friday afternoon. If the honest answer is "do it", the process is the problem.
The fix: work with process owners to build verification into the workflow: dual approval and call-back on a known number for bank detail changes, documented identity verification for help desk resets, and the authority for staff to delay an urgent request without penalty. See the Help Desk Identity Verification Policy Template.
9. No executive ownership or visible leadership
What goes wrong: the programme sits with a single awareness officer inside IT, executives are excused from training and simulations, and nobody senior talks about security except after an incident. Staff read the signal correctly. NIST CSF 2.0 places roles, responsibilities and authorities in the Govern function (GV.RR), and NIST SP 800-50 Rev. 1 frames the learning programme as part of building a security and privacy culture, which needs leadership.
How to detect it: no board sponsor named in the programme charter; executive completion rates lower than staff; executives not included in simulations.
The fix: name a board-level sponsor, have the executive team complete training first and say so, include executives and their assistants in simulations with their agreement, and report programme outcomes to the board twice a year using the metrics from mistake 1.
10. Never updating content or reviewing the programme
What goes wrong: content is bought once and replayed for years. It still warns about misspelt emails from foreign princes while attackers use well-written AI-generated lures, help desk vishing and consent phishing. Lessons from your own incidents never reach the training. NIST SP 800-53 Rev. 5 AT-2(6) asks that literacy training cover the current cyber threat environment, and AT-6 covers collecting feedback on training results to improve it.
How to detect it: content last reviewed more than a year ago; no module traced to an incident or threat report from the last 12 months; post-incident reviews never produce an awareness action.
The fix: run a quarterly content review fed by the SOC's user-reported phishing trends, incident post-mortems and threat intelligence; retire stale modules; add one short module per quarter on a current technique. See the AI-Generated Phishing Defence Guide for one theme many programmes now need.
Measuring whether the programme works
| Metric | How to collect | Direction that shows progress |
|---|---|---|
| Report rate on simulations | Simulation platform plus report button data | Rising, and rising faster than click rate falls |
| Median time to first report | Report button timestamps against delivery time | Falling, ideally to minutes |
| Share of real malicious messages first reported by users | SOC triage records | Rising |
| Role-based training coverage for high-risk roles | LMS assignments against the role matrix | Close to 100% of finance, help desk, admin and executive roles |
| Help desk verification adherence | Quality sampling of reset tickets | Rising, with failures followed up as coaching |
| Incidents with an awareness lesson fed back | Post-incident review actions | Every relevant incident produces content within a quarter |
Mapping to frameworks
| Mistake | NIST CSF 2.0 | NIST SP 800-53 Rev. 5 |
|---|---|---|
| 1 Wrong metrics, 10 Stale content | ID.IM-01 | AT-6, AT-2(6) |
| 2 Blame, 6 Reporting route | PR.AT-01 | IR-6, AT-2(4) |
| 3 Training as the main control | PR.AT-01 | AT-2, AT-2(3) |
| 4 One course for everyone | PR.AT-02 | AT-3, AT-4 |
| 5 Gotcha simulations, 7 Email only | PR.AT-01 | AT-2(3) |
| 8 Process design | PR.AT-02 | PL-4 |
| 9 Leadership | GV.RR | PM-13 |
AT-2(3) is the 800-53 enhancement for social engineering and mining training. In ISO/IEC 27001:2022, control A.6.3 covers information security awareness, education and training and A.6.8 covers information security event reporting. CIS Controls v8.1 Control 14, Security Awareness and Skills Training, covers the same ground; see the CIS Control 14 Security Awareness and Skills Training Guide.
Where to start
- Publish the no-blame reporting commitment with HR this month (mistake 2); nothing else works while people fear reporting.
- Fix the reporting route and start sending feedback to reporters (mistake 6).
- Change the headline metrics to report rate and time to report (mistake 1).
- Build the role matrix and give finance, help desk, administrators and executives their own modules (mistake 4).
- Then review simulation design, channel coverage and process design (mistakes 5, 7 and 8), and set the quarterly content review (mistake 10).
Practitioner checklist
- A written no-blame reporting commitment is signed by HR and a senior leader and repeated in training.
- Report rate and median time to first report are the headline programme metrics.
- Every mail client has a report button, and every reporter gets a verdict back.
- A single published route exists for suspicious calls, texts and chat messages.
- A role matrix assigns extra modules to finance, help desk, administrators and executives.
- The simulation charter, agreed with HR and legal, bans lures on pay, health and redundancy.
- Training covers voice, SMS, QR codes and unexpected MFA prompts, not just email.
- High-risk processes such as bank detail changes and MFA resets have built-in verification steps.
- A board sponsor is named and executives complete training first.
- Content is reviewed quarterly against incidents and threat intelligence.
Standards and references
- NCSC: Phishing attacks, defending your organisation
- NIST: SP 800-50 Rev. 1, Building a Cybersecurity and Privacy Learning Program
- NIST: SP 800-53 Rev. 5, Security and Privacy Controls (AT family)
- NIST: Cybersecurity Framework 2.0
- MITRE ATT&CK: Phishing: Spearphishing Voice
- MITRE ATT&CK: Multi-Factor Authentication Request Generation
- MITRE ATT&CK: Phishing for Information
Related NHI Mgmt Group resources: Security Awareness Maturity Model · Security Awareness and Human Risk Management Guide · Security Awareness Plan Template · Phishing Simulation Programme Guide