Human Risk Management Programme Guide

An annual training course with a 98% completion rate tells you almost nothing about whether your people will approve a fraudulent payment, accept a stray MFA prompt or paste customer data into a public AI tool. Human risk management (HRM) replaces that completion metric with a running programme: define the behaviours that matter, measure them from real telemetry, intervene where the risk is, and change the systems that make risky behaviour easy. This guide is the operating manual for that programme: governance, the behaviour catalogue, data sources, interventions, metrics and a 12-month rollout. It is for awareness leads, CISOs and security operations teams who already run training and now need to show reduced risk. For the concepts and the case for moving beyond awareness, read the Security Awareness and Human Risk Management Guide first; this page goes deeper on running it.

Key takeaways

Start from behaviours, not courses. Write down 10 to 15 specific, observable behaviours (reports suspicious email, verifies payment changes out of band, rejects unexpected MFA prompts) and build everything around them.
Measure from systems you already own. Email reporting, identity provider logs, DLP, endpoint and help desk tickets show real behaviour; quiz scores and completion rates do not.
Reward reporting more than you punish clicks. NCSC guidance warns that blame suppresses reporting; the report rate and time to report are the leading indicators that matter.
Fix the process before the person. If a risky behaviour recurs across a team, the control, workflow or tool is usually the root cause, and an engineering fix beats another module.
Govern the data. Behaviour scoring is employee monitoring: agree purpose, retention and access with HR, legal and works councils before the first dashboard goes live.

What a human risk programme changes

NIST SP 800-50 Rev. 1, Building a Cybersecurity and Privacy Learning Program (September 2024), replaced the 2003 awareness guidance with a life cycle of four phases: plan and strategy, analysis and design, development and implementation, and assessment and improvement. It explicitly ties learning to behaviour change and culture, and lists longitudinal behaviour measures (timely updates, MFA adoption, phishing reporting) next to completion counts. HRM takes that last step seriously: the programme exists to move behaviours, and training is one intervention among several.

Element	Compliance awareness	Human risk management
Goal	Everyone completes the annual course	Measured reduction in specific risky behaviours
Unit of work	Course or module	Behaviour, with an owner and a metric
Data	LMS completion, quiz scores	Email reports, IdP and MFA logs, DLP, endpoint, help desk, simulation results
Targeting	Same content for all staff	Role and risk based: finance, help desk, admins, executives, developers
Timing	Once a year, at onboarding	Continuous, including just-in-time prompts at the moment of risk
Response to mistakes	Remedial course	Coaching, control change, process redesign; discipline only for wilful policy breach
Reporting to the board	Completion percentage	Behaviour trends, incidents prevented, residual human risk by business unit

Governance and operating model

Most stalled programmes fail on ownership, not content. Put the programme on a written charter before buying anything.

Sponsor: the CISO, with a named executive from HR. NIST SP 800-50r1 expects leaders to champion the programme and HR to reinforce norms through onboarding and workplace materials.
Programme owner: one person accountable for the behaviour catalogue, metrics and roadmap. In small organisations this is a part-time awareness role; in large ones a small team with a data analyst.
Behaviour owners: each behaviour gets an owner who controls the fix. Payment verification belongs to the finance controller, help desk identity checks to the service desk manager, MFA prompt handling to the identity team.
Security operations link: the SOC consumes user reports, closes the loop with reporters and feeds confirmed incidents back into the behaviour data.
Privacy and employee relations: HR, legal, the data protection officer and, where they exist, works councils or unions agree what is measured, at what level of detail, and how results may be used.
Champions network: one volunteer per team or site who relays campaigns and brings back friction points. Champions are cheap and give you qualitative signal no dashboard provides.

Write a short programme policy that states, in plain language: the behaviours in scope, that the programme is supportive rather than disciplinary, the escalation path for repeated high-risk behaviour, and the data retention period. The Security Awareness Training Policy Template is a starting point for that document.

Building the behaviour catalogue

A behaviour must be specific, observable in data you can lawfully collect, and linked to a real attack path. "Be careful with email" fails all three tests. Start with the behaviours behind your own incidents and the common social engineering routes, then add regulatory ones (for example handling of personal data).

Behaviour	Attack it counters	Primary data source	Behaviour owner
Reports suspicious email within 30 minutes (our target)	Phishing, AiTM credential theft	Report button telemetry, mail gateway	Security operations
Rejects and reports unexpected MFA prompts	MFA fatigue, push bombing	IdP sign-in and MFA denial logs	Identity team
Verifies bank detail changes by calling a known number	Business email compromise, supplier fraud	Finance workflow records, exception logs	Finance controller
Follows identity checks before password or MFA resets	Help desk social engineering	Service desk tickets, reset audit trail	Service desk manager
Keeps sensitive data out of unapproved AI tools and personal storage	Data leakage, shadow AI	DLP and secure web gateway events	Data protection lead
Installs updates within the set window	Exploitation of known flaws	Endpoint management compliance	Endpoint team
Uses the password manager and unique passwords	Credential stuffing, reuse	Password manager adoption, breached password checks	Identity team
Keeps secrets and tokens out of code, tickets and chat	Leaked credentials, NHI abuse	Secret scanning in repositories and collaboration tools	Platform engineering

The help desk row is not theoretical. In the Co-op cyber attack, attackers posing as staff obtained a password reset and used it to reach the network. The fix there is a verification process that cannot be talked around, which is a control change first and a training topic second. See the Vishing and Help Desk Social Engineering Awareness Guide for the role-specific content.

Data sources and the human risk score

Pull behaviour events into one place, usually the SIEM or a data platform the security team already runs, keyed to the identity in your IdP. Typical feeds:

Email: user reports from the report button, gateway verdicts on those reports, simulation clicks and reports, and real-phish clicks confirmed by the SOC.
Identity: denied MFA prompts, risky sign-ins, legacy authentication use, password resets and passkey or phishing-resistant MFA enrolment.
Data: DLP policy matches, user overrides with justification, uploads to unsanctioned cloud or AI services.
Endpoint: update compliance, local admin use, blocked executable or macro attempts.
Process: payment verification exceptions, help desk resets without the required check, access review sign-offs left overdue.

A risk score combines three things per person or team: exposure (role, access level, how often they are targeted), behaviour (recent risky and protective events) and protection (controls in place, such as phishing-resistant MFA or no standing admin rights). Keep the model simple and explainable: a weighted sum with published weights beats an opaque score nobody can challenge. Report scores at team or department level by default. Individual scores should drive coaching only, should decay over time (we use 90 days) and should never be the sole basis for disciplinary action.

In the UK, read the ICO's guidance on monitoring workers before building individual scoring, and expect to complete a data protection impact assessment. Other jurisdictions have their own employee monitoring and works council rules; involve local counsel.

Interventions: choosing the right lever

For each behaviour gap, pick the cheapest intervention that changes the outcome. Training is often not it.

Lever	Use when	Example
Engineering control	The risky action can be blocked or made safe without stopping work	Number matching or phishing-resistant MFA instead of push approve; block legacy authentication
Process redesign	A workflow relies on one person spotting fraud	Second-person approval and call-back for supplier bank changes
Just-in-time nudge	The risk happens at a predictable moment	DLP prompt asking for a business justification before upload; external sender banner
Targeted micro-training	A role faces a specific attack the control cannot stop	Five-minute module for payroll staff on payroll diversion lures
Coaching conversation	An individual repeats a high-risk behaviour	Manager and security champion walk through the event, agree a fix
Positive reinforcement	You want more of a protective behaviour	Personal thank-you from the SOC when a report catches a real phish
Consequence management	Wilful, repeated breach of a clear policy after support	HR process under the acceptable use policy

The NCSC phishing guidance makes the same point at the defence level: training is one of four layers and is often overemphasised, because users cannot spot every phish. The Uber breach of 2022 shows why. A contractor accepted a push prompt after repeated requests; the durable fix is phishing-resistant MFA and alerting on repeated denials, with user guidance as backup.

Simulations, reporting and the feedback loop

Simulations are a measurement tool, not a punishment tool. NIST SP 800-50r1 recommends random scheduling, legal review, avoiding real brand or agency names and keeping results non-punitive, and points to the NIST Phish Scale (Technical Note 2276) for rating how hard each simulated email is to detect, so click rates are read in context. The NCSC goes further and warns that punitive simulations erode trust and may create legal risk, so check the design with HR.

Rate every template: record the Phish Scale difficulty or an equivalent internal rating so a rise in clicks on a harder lure is not misread as decline.
Track the report, not just the click: report rate, time to first report and the share of real phishing first reported by a user are the metrics that predict containment.
Close the loop within one working day: every report gets an automated acknowledgement and, for confirmed malicious mail, a human thank-you.
Feed reports to the SOC: clustered user reports should trigger a hunt and purge of matching mail.
Use simulations sparingly for high-risk groups: finance, HR, executive assistants and IT administrators see more realistic scenarios; everyone else gets fewer, easier ones and more nudges.

Design detail for campaigns is in the Phishing Simulation Programme Guide.

Rolling out the programme

Months 0 to 2, baseline: write the charter, agree data use with HR and privacy, pick 8 to 10 behaviours, and measure them for six weeks without intervention. Record current report rate, MFA denial patterns, DLP override rate and help desk check compliance.
Months 2 to 4, pilot: choose two business units with different risk profiles. Turn on the report button feedback loop, two just-in-time nudges and targeted modules for one high-risk role. Keep a control group where you can.
Months 4 to 6, fix the systems: take the top three recurring behaviours and assign engineering or process fixes to their owners. Measure the effect against the baseline.
Months 6 to 9, scale: extend to all units, launch the champions network, and start team-level dashboards for managers.
Months 9 to 12, report and reset: present behaviour trends to the executive committee, retire behaviours that have reached target, and add new ones (for example AI tool use or deepfake voice verification).

Rollback and safety valves: if a nudge creates excessive friction (support tickets spike or a team routes around it), switch it to monitor-only and redesign. If staff relations deteriorate after a simulation, pause the campaign, publish what you learned and restate the non-punitive policy.

Small organisations: skip the score. Track four numbers monthly (report rate, real phish reported first by a user, MFA prompts denied, payment verification exceptions) in a spreadsheet, and spend the budget on phishing-resistant MFA and payment controls. Large organisations: invest in the data pipeline and a part-time analyst before more content.

Metrics that show risk is falling

Metric	Definition	Direction
Report rate	Share of recipients who report a simulated or confirmed malicious email	Up
Median time to first report	Minutes from delivery of a real phishing wave to the first user report	Down
Real phish first detected by a user	Share of confirmed phishing incidents where a user report was the first signal	Up
Repeat risky behaviour rate	Share of people with the same high-risk event twice in 90 days	Down
Control-backed behaviours	Share of catalogue behaviours with an engineering or process control, not only training	Up
DLP override with valid justification	Overrides reviewed and found legitimate, as a share of all overrides	Up

Pair the numbers with an attitude survey twice a year. NIST SP 800-50r1 lists attitude surveys, focus groups and interviews as qualitative measures of culture, and they explain why the numbers move.

Where identity fits

Most of the high-impact behaviours are identity events: approving MFA, resetting credentials, granting OAuth consent, sharing tokens. That makes the identity team a core partner, and it means the strongest interventions are identity controls. Phishing-resistant authentication removes whole classes of risky behaviour. Developers and platform engineers have their own catalogue: keeping API keys, service account credentials and tokens out of code and chat, which is a non-human identity risk created by human behaviour. See the Consent Phishing and Illicit OAuth Grants Guide for one such behaviour in depth.

Framework mapping

Framework	Reference	How the programme supports it
NIST CSF 2.0	PR.AT-01, PR.AT-02	General and role-specific awareness and training
NIST CSF 2.0	GV.RR-04	Cybersecurity built into HR practices, from onboarding to coaching
NIST CSF 2.0	DE.CM-03	Personnel activity monitored for adverse events, within agreed privacy limits
NIST CSF 2.0	ID.IM-01	Improvements identified from evaluations and metrics
NIST SP 800-53 Rev. 5	AT-2, AT-2(2), AT-2(3), AT-3, AT-4	Literacy training, insider threat and social engineering content, role-based training, training records
NIST SP 800-53 Rev. 5	IR-6	Incident reporting by users
CIS Controls v8.1	Control 14	Security awareness and skills training programme

Common failure patterns

Scoring before consent. Individual risk scores launched without HR and privacy agreement trigger grievances and get switched off.
Click rate as the headline KPI. It rewards easy lures and discourages reporting. Lead with report rate and time to report.
Training for a control gap. Teaching finance to spot fraud while one person can still change supplier bank details alone.
No loop back to reporters. Reports vanish into a mailbox, so staff stop sending them.
One catalogue for everyone. Help desk, finance and administrators face different attacks and need different behaviours and data.
Ignoring new channels. Voice, SMS, collaboration tools and AI assistants are now routine lures and data exit points; a programme that only measures email misses them.

Practitioner checklist

Agree a written charter with a CISO sponsor, an HR partner and a named programme owner.
Define 8 to 15 observable behaviours, each with an attack path, a data source and an owner.
Complete the privacy assessment and agree retention, aggregation level and permitted uses of behaviour data.
Baseline each behaviour for at least six weeks before intervening.
Route user reports to the SOC with automated acknowledgement and feedback within one working day.
Rate every simulation for difficulty and report it alongside results.
For the top three recurring behaviours, assign an engineering or process fix, not only content.
Report behaviour trends and report rate to the executive committee each quarter.
Re-score and refresh the catalogue every 12 months, adding AI and voice-based behaviours as needed.

Human Risk Management Programme Guide: Measuring and Reducing Risky Behaviour Beyond Annual Training