Security Awareness and Human Risk Management Guide

Annual awareness modules and click-rate league tables rarely change how people behave under pressure, yet phishing, help desk impersonation and payment fraud still start with a person being persuaded to act. The UK Cyber Security Breaches Survey 2025 found that phishing was experienced by 85% of businesses that reported a breach or attack, while only 19% of businesses had provided staff training in the previous year. Human risk management (HRM) is the shift from delivering training to measuring and reducing the specific risky behaviours that matter, combining behavioural data, targeted interventions and technical controls. This guide covers programme design, role-based training, phishing simulation and reporting, human risk scoring, repeat offenders, privacy limits on employee data, metrics and framework mapping. It is written for security awareness leads, CISOs and security operations teams.

Key takeaways

Measure behaviour, not attendance. NIST SP 800-50 Rev. 1 frames the goal as behaviour change; completion rates show reach, while reporting rates and time to report show whether people act.
Reports matter more than clicks. The NCSC advises measuring how many people reported a phish, not just who clicked, and warns that blaming users "doesn't work".
Technical controls come first where they can. Training should cover what technology cannot block; if a browser policy or allowlisting rule can stop a risk, do that rather than asking people to spot it.
Target the roles attackers target. Help desk, finance, executives, developers and administrators face specific attacks, from reset fraud to deepfake calls, and need role-specific training under NIST AT-3 and CIS Safeguard 14.9.
Human risk scores are personal data. Scoring employees is workplace monitoring; under UK GDPR it needs a clear purpose, the least intrusive means, transparency and often a DPIA.

From security awareness to human risk management

Security awareness programmes traditionally deliver content: an induction module, an annual refresher and a phishing simulation. Human risk management keeps that content but adds measurement of real behaviour, prioritisation of the people and actions that carry the most risk, and interventions timed to the moment a risky action happens.

Dimension	Traditional awareness	Human risk management
Unit of measure	Course completion, quiz scores	Observed behaviours: reporting, credential submission, policy violations, risky sharing
Cadence	At hire and annually	Continuous, with short interventions triggered by events
Content	Same for everyone	By role, exposure and observed weaknesses
Data sources	Learning management system	Email security, simulations, identity provider, endpoint, DLP, browser, help desk records
Response to a mistake	Mandatory retraining	Feedback, coaching, then technical guardrails for persistent risk
Outcome reported to the board	Percentage trained	Trend in reported threats, time to report, high-risk population size, incidents with a human entry point

NIST SP 800-50 Rev. 1 (September 2024) supports this shift. It replaces the 2003 guidance with a cybersecurity and privacy learning programme (CPLP) built on a four-phase life cycle: Plan and Strategy, Analysis and Design, Development and Implementation, and Assessment and Improvement. It says awareness activities "should be conducted on an ongoing basis throughout the year", and that follow-up literacy training can be short ad hoc sessions rather than one long course.

Culture is what makes the measured behaviours stick. The NCSC's cyber security culture principles (June 2025) ask organisations to frame security as an enabler, build the safety and trust that encourage openness, embrace change, make secure behaviour the social norm, have leaders own their influence on culture, and keep rules accessible and easy to understand. A "human firewall" framing that treats staff as the last line of defence works against the second principle: people who expect blame stop reporting.

Role-based training: where the attacks land

NIST SP 800-53 AT-3 Role-based Training and CSF 2.0 PR.AT-02 require training for people in specialised roles, and CIS Safeguard 14.9 calls for role-specific awareness and skills training. The roles below are the ones attackers repeatedly choose.

Role	Attack they face	Behaviour to train	Technical backstop
Service desk	Caller impersonating an employee or contractor to reset passwords or MFA	Identity verification steps that cannot be skipped under pressure; call-back to a known number	Verified reset workflow, manager approval, alerting on MFA re-registration
Finance and payments	Business email compromise, fake supplier bank changes, deepfake executive calls	Out-of-band verification of payment changes and urgent requests	Dual approval, payee change holds
Executives and their assistants	Whaling, voice and video impersonation	Code words or call-back for unusual requests	Phishing-resistant MFA, mailbox rules monitoring
Developers and engineers	Credential phishing for code hosting, malicious packages, secrets pasted into AI tools	Never paste secrets or source into unapproved AI tools; verify package names	Secret scanning, approved AI tooling, package allowlists
IT administrators	MFA fatigue, OAuth consent phishing, adversary-in-the-middle sign-in pages	Treat unexpected MFA prompts as an incident and report them	Number matching or phishing-resistant MFA, consent policies
Recruiters and HR	Malicious CV attachments, fake candidates	Open attachments only in approved viewers; verify identity at interview	Attachment sandboxing, identity proofing for hires

Help desk: the MGM Resorts breach began with a help desk phone call, and the Co-op attack used help desk social engineering. See the Account Recovery and Help Desk Security Guide.
Deepfake awareness: at Arup, a video call with a fake CFO triggered HK$200 million in transfers. Training should teach a verification habit rather than spotting artefacts, because synthetic media quality keeps improving. See the Deepfake and AI Impersonation Guide.
Generative AI use: the Samsung ChatGPT leak came from staff pasting source code into a public AI tool. Pair the rule with an approved alternative, or people will route around it.

Behaviour change techniques that work

Just-in-time training: deliver a two-minute lesson at the moment of a risky action, such as after a simulated phish is clicked or when a user tries to upload a file to an unapproved site. Microsoft Defender attack simulation training, for example, assigns training to users based on simulation results and tracks completion as Completed, In progress or Incomplete.
Security nudges: short, contextual prompts in the tools people use, such as external sender banners, a warning when sharing a file publicly, or a prompt before approving an OAuth app. Nudges work best when rare; constant warnings produce awareness fatigue.
Gamified training: leaderboards and points for reporting work when they reward the desired behaviour (reporting, verifying) and never rank people by failures.
Security champions programme: volunteers in each business unit who relay local concerns, translate guidance into team language and spot gaps. Give champions time allocation, a named contact in security and early access to campaigns.
Turn staff into attackers: the NCSC suggests having staff write their own phishing emails as an alternative to simulations, which builds insight into manipulation techniques.
Security awareness month: useful for visible leadership messages and refreshing material, but treat it as a campaign within a year-round programme, not the programme itself.

Phishing simulation and reporting done well

The NCSC is blunt: "No training package, including phishing simulations, can teach users to spot every phishing attempt." Simulations are a measurement and practice tool, and they "can also create legal risk", so involve HR before launching. The goal is fast reporting, because a report from the first recipient can protect everyone else.

Make reporting one click. In Microsoft Defender for Office 365, the User reported settings page controls whether the built-in Report button or a third-party add-in is used and where reports go: Microsoft and my reporting mailbox, My reporting mailbox only, or Microsoft only. Reported messages appear on the User reported tab of the Submissions page.
Configure the reporting mailbox correctly. Microsoft requires the reporting mailbox to be identified as a SecOps mailbox in the advanced delivery policy so reports are not filtered, and recommends excluding it from DLP.
Close the loop. Send every reporter a result, using customised result emails for Phishing, Junk and No threats found. The NCSC lists feedback as part of an effective reporting process.
Rate difficulty. Use the NIST Phish Scale (NIST TN 2276), which rates an email's detection difficulty from its visible cues and how well its premise fits the recipient's work, so a rise in clicks on a harder email is not misread as a decline in behaviour.
Vary the channel. Attackers use SMS and voice as well as email; ATT&CK lists T1566.004 Spearphishing Voice alongside attachment and link phishing. The Twilio breach started with SMS phishing of employees.
Include OAuth consent and MFA prompts. Microsoft's simulation catalogue counts accepting an OAuth permissions prompt as a compromise, and unexpected MFA prompts should be reportable. The Uber breach used MFA fatigue against a contractor. See the MFA Fatigue and Bypass Guide.
Never name and shame. NIST SP 800-50 Rev. 1 says simulation activities "should not be punitive, nor should any employee be called out for their response".

Human risk scoring and repeat offenders

A human risk score combines signals into a view of which people or groups carry the most risk, so that effort goes where it changes outcomes. Scores are a prioritisation aid, not a performance rating.

Signal	Typical source	What it indicates	Caution
Simulation outcomes and reports	Simulation platform, reporting mailbox	Susceptibility and vigilance	Normalise for difficulty
Real phish reported or clicked	Email security, SOC cases	Behaviour under real conditions	Low volumes per person
Authentication hygiene	Identity provider	Weak MFA methods, denied MFA prompts, password reuse found in breach data	Some signals point to attacks, not user failure
Data handling events	DLP, cloud access security broker	Risky sharing, uploads to unapproved apps	Often business-driven; check with the team
Endpoint and browser events	EDR, browser management	Blocked downloads, unapproved extensions	Usually better fixed by policy
Exposure	Role, privileges, public profile	Impact if the person is compromised	Exposure is not behaviour; do not penalise it

Repeat offenders: Microsoft defines a repeat offender as a user compromised in consecutive simulations, with a default threshold of 2 that can be changed on the Settings tab, and tracks both the current run and the number of times a user has been classified this way. Use the count to trigger support, not sanctions.
Escalation ladder: first, immediate feedback and a short lesson; second, a conversation with a champion or manager about workload and context; third, technical guardrails such as stricter link handling, attachment sandboxing or removal of privileges the person does not need. Persistent policy violations that are deliberate belong in the disciplinary process (ISO/IEC 27001:2022 Annex A 6.4), which should be separate from the awareness programme.
Predicted vs actual: Microsoft reports a predicted compromise rate per simulation alongside the actual rate, which helps separate a hard email from a weak population.

Privacy, employment law and where identity fits

Scoring individuals means monitoring workers. The ICO's guidance on monitoring workers says employers must "select the least intrusive means" to achieve a clear purpose, that a DPIA is mandatory for monitoring likely to be high risk, including monitoring that could lead to financial loss such as performance management, and that consent is rarely an appropriate lawful basis in employment.

Purpose and transparency: tell staff what is collected, why and how it is used, and let them see and challenge results that affect them.
Minimise and retain briefly: collect only signals that drive an intervention, aggregate for reporting, and set a retention schedule for individual scores.
Separate from HR decisions: keep risk scores out of performance reviews unless a DPIA, legal advice and works council or union consultation support it.
Secure the HRM platform's integrations: HRM platforms pull data through API tokens and OAuth apps with read access to email security, identity, endpoint and DLP tools. Those credentials are non-human identities with broad visibility into the workforce. Scope them read-only, store them in a vault, rotate them and review the vendor's data storage location and sub-processors. See the SaaS and OAuth App Governance Guide and the API Key Management Guide.
Insiders are different: bribery and malicious insiders, as in the Coinbase support agent breach, are not awareness failures. Handle them through access controls and insider risk processes. See the Insider Threat and Identity Guide.

Choosing between training and technical controls

Prefer technical controls when the bad outcome can be blocked reliably. Malicious pop-ups, browser hijackers, fake update prompts and unapproved extensions are better handled by managed browser policy, extension allowlists and application control than by asking users to recognise them. See the Enterprise Browser and Browser Security Guide and the Application Allowlisting Guide.
Prefer training and process when the attack abuses legitimate authority. A payment request from a spoofed executive or a convincing help desk caller uses valid channels; verification habits and process controls are the main defence.
Combine both for credential phishing. Phishing-resistant MFA removes most of the value of a stolen password, and reporting gives the SOC time to purge a campaign. ATT&CK lists M1017 User Training as one mitigation for T1566 Phishing among several technical ones (M1054 Software Configuration, M1021 Restrict Web-Based Content).
Small organisations: use the built-in reporting, simulation and training features of your email platform, run quarterly simulations with a short follow-up lesson, and spend the remaining effort on MFA and backups. A champion per team is often enough.
Large organisations: justify an HRM platform when you have several data sources to correlate, need role-based targeting at scale, and have the privacy governance to support individual scoring.

Rolling out a human risk programme

Baseline: collect current reporting rate, time to report, simulation compromise rate by department, and incidents in the last year with a human entry point.
Fix the reporting path first: one-click reporting, a monitored mailbox, triage and feedback to reporters. Everything else depends on it.
Complete the privacy work: DPIA, staff notice and data retention rules before collecting individual risk signals.
Pilot: run role-based training and simulations with two or three high-exposure groups, such as finance and the service desk, for one quarter. Compare against a baseline group.
Add signals gradually: start with simulation and reporting data, then identity signals, then DLP and endpoint signals, reviewing false positives with each team.
Scale: extend to all staff, recruit champions, and automate just-in-time lessons for the most common risky actions.
Roll back any nudge or simulation type that drives complaints, help desk load or reporting declines; pause individual scoring if the DPIA assumptions change.

Detection and measurement

Metric	Definition	Healthy direction
Report rate	Share of simulation recipients who reported the message	Rising
Time to first report	Minutes from delivery of a real or simulated phish to the first user report	Falling
Real threat reports	User-reported messages confirmed malicious per month	Rising, then stable
Credential submission rate	Share of recipients who entered credentials, normalised by Phish Scale difficulty	Falling
Repeat offender population	Users over the repeat threshold, and how long they stay there	Falling
Human-initiated incidents	Confirmed incidents with a phishing, social engineering or mis-sharing entry point	Falling in impact

NIST SP 800-50 Rev. 1 also suggests tracking the "percentage of participants who changed a behavior in the workplace" and testing knowledge before training, straight after and three months later. Completion rates remain useful as a compliance measure but should not be the headline. The SOC should monitor the reporting mailbox volume, triage times and whether reports led to campaign-wide purges.

Framework mapping

Framework	Reference	What it requires or describes
NIST CSF 2.0	PR.AT-01, PR.AT-02	Awareness and training for all personnel and for specialised roles
NIST SP 800-53 Rev. 5	AT-2 Literacy Training and Awareness, with AT-2(1) Practical Exercises, AT-2(2) Insider Threat, AT-2(3) Social Engineering and Mining, AT-2(4) Suspicious Communications and Anomalous System Behavior; AT-3 Role-based Training; AT-4 Training Records	Initial and recurring training, lessons learned from incidents, practical exercises, records
CIS Controls v8.1	Control 14, Safeguards 14.1 to 14.9	Programme at hire and at least annually (14.1), social engineering (14.2), authentication (14.3), incident reporting (14.6), role-specific training (14.9)
ISO/IEC 27001:2022 Annex A	6.3 Information security awareness, education and training; 6.4 Disciplinary process; 6.8 Information security event reporting	People controls for awareness, consequences and reporting
NIS2 Directive	Art. 20(2); Art. 21(2)(g)	Management body training; basic cyber hygiene practices and cybersecurity training
MITRE ATT&CK v20	T1566 Phishing (M1017 User Training); T1598 Phishing for Information; T1204 User Execution; T1621 Multi-Factor Authentication Request Generation	Techniques where user behaviour is part of the defence

Common failure patterns

Click rate as the only metric. It rewards easy simulations and ignores reporting. Pair it with report rate and Phish Scale difficulty.
Punishing people who click. The NCSC warns staff who fear punishment may not report mistakes, removing an early warning source.
Email-only training. Attackers also use phone and SMS and impersonate trusted third parties, as in the Marks and Spencer attack.
Help desk outside the programme. Service desk staff are trained on customer service, not on resisting a confident caller asking for an MFA reset.
Training to compensate for missing controls. Asking users to spot every malicious pop-up when browser policy could block it wastes goodwill.
Scoring without governance. Individual risk scores built without a DPIA or staff notice create legal exposure and destroy trust in the programme.

Practitioner checklist

Deploy one-click reporting with a SecOps-designated mailbox, triage and feedback to every reporter.
Report report rate and time to first report to leadership, alongside click and credential submission rates.
Rate simulation difficulty with the NIST Phish Scale before comparing campaigns.
Deliver role-based training to service desk, finance, executives, developers, administrators and HR.
Run voice, SMS, MFA prompt and OAuth consent scenarios, not just email.
Complete a DPIA and staff notice before scoring individuals, and keep scores out of performance reviews.
Use a support-first escalation ladder for repeat offenders, ending in technical guardrails.
Replace training with technical controls wherever a risk can be blocked reliably.
Scope, vault and rotate the API tokens that HRM and simulation platforms use.