Human Risk Scoring Best Practices: A Data-Driven Program Guide

Ten percent of employees drive 73% of an organization's risky security behavior, according to Living Security's 2025 Human Risk Report. Verizon's 2025 Data Breach Investigations Report finds a similar pattern from the incident side: 8% of employees account for 80% of incidents. Put those two numbers together and you get the fact that makes human risk scoring worth building at all: risk is not spread evenly across a workforce, which means it's concentrated enough to measure, prioritize, and act on.

Most security awareness programs still can't prove whether they're reducing breach risk or just producing completion certificates. A human risk score is how you replace that guesswork with data. This guide walks through how to build one: what to score, how to weight it, what to do with the result, and the mistakes that turn a good scoring model into a spreadsheet nobody trusts.

What a Human Risk Score Actually Measures

A human risk score is a normalized, periodically recalculated number that combines behavioral, access, and contextual signals into a single figure for a person, team, or company. It answers a narrower question than "is this employee good at security": it estimates how likely someone is to be the point of failure in an attack, based on what they've actually done, not what they know in theory.

That distinction matters because roughly 60% of breaches involve a human element, according to Verizon's 2025 DBIR. A score built on real behavior (simulation outcomes, access hygiene, reporting habits) tracks that human element directly, which is a different thing than a score built on training completion, which only tracks attendance.

This guide assumes you already understand the broader category of human risk indicators and want to get straight to building and running a score, so definitions here stay brief. It's the practical, build-first companion to a fuller indicator taxonomy, not a replacement for one.

Two Numbers Your Score Must Keep Separate: Targeting vs. Susceptibility

The single most common design mistake in human risk scoring is collapsing two different probabilities into one number.

Targeting probability is how likely someone is to be attacked in the first place. It's driven by role, access level, and public exposure: a CFO or an accounts-payable clerk with wire authority is a more attractive target than a warehouse employee with no system access, regardless of how well either one would perform under attack.

Susceptibility probability is how likely someone is to fail if they are attacked. It's driven by behavior history: simulation performance, password hygiene, MFA enrollment, and how quickly they report suspicious activity.

Proofpoint's public scoring framework captures this split explicitly, modeling risk as a function of vulnerability, attack likelihood, and privilege rather than a single blended score. The practical reason to keep the two apart: conflate them, and you'll spend remediation budget on people who are rarely targeted and already resilient, while a highly targeted, moderately susceptible employee with privileged access slips through the middle of the distribution. Score both, then combine them deliberately rather than by accident, especially now that AI-generated phishing can personalize targeting at a scale that used to require manual reconnaissance.

Building the Formula: Inputs, Weights, and a Worked Example

A usable score needs four input categories, condensed to what actually moves the needle:

• Behavioral: simulation outcomes (click rate, credential-entry rate, report rate) across every channel you test, not just email

• Identity and access: privilege level, MFA enrollment, password-manager adoption, password hygiene

• Contextual: role, department, public exposure, tenure

• Engagement: training completion, time to complete, and repeat-failure pattern

Weight these against each other, then normalize by role. A person's raw score should never be compared on an absolute scale against someone in a different access tier; normalize within peer groups so the score reflects behavior, not org chart position. Skip normalization and the score just re-derives who has the most access, which you already know without building anything.

One transparent, publicly documented example shows how the math can work: CanIPhish's published human risk formula weights four factors.

Each factor is scored 0-100, multiplied by its weight, and summed. CanIPhish then buckets the result into three tiers: 70-100 is High risk, 40-69 is Medium, and 0-39 is Low. Run a hypothetical employee through it: a Security IQ of 60, a Phish-proneness score of 40 (meaning relatively few simulation failures), no recorded breach history (100), and strong engagement (90) produces (60 × 0.35) + (40 × 0.35) + (100 × 0.15) + (90 × 0.15), or roughly 63.5, landing in the Medium tier. Change the Phish-proneness input to 15 after a string of failed simulations, and the same employee crosses into High without anything else moving. That sensitivity is the point: the formula should react visibly to the input that matters most for your organization, which is usually behavioral.

This is one illustrative model, not a universal standard. Your weights should reflect what your organization has actually measured as predictive, and should shift as you collect more data. But it shows the core mechanic clearly: independently score each input, weight it deliberately, sum it, and tier the result. A score without a published formula behind it is a black box that leadership, and employees, have no reason to trust.

From Score to Action: Risk Tiers and What Each One Triggers

A score that doesn't trigger a specific action is a report, not a program. Once employees are tiered, attach a concrete intervention to each level:

Medium and High are where most programs fall short: a generic "you failed, take this course" response doesn't address why someone failed, and it doesn't account for what they have access to. Tie the intervention to both the failure type and the access level, and reassess on a fixed clock rather than letting a High-tier employee sit at that tier indefinitely.

Running the Program: Assess, Prioritize, Tailor, Track

Scoring is not a one-time project. Treat it as a recurring cycle, commonly abbreviated APTT.

Assess. Run a multi-channel baseline simulation (email, vishing, and where relevant deepfake or hybrid attacks) alongside an access and hygiene audit, before making any changes to training. You need a starting number before you can prove movement.

Prioritize. Apply the concentration finding directly: focus remediation on the roughly 10% of employees driving most of the risk, and within that group, split out who is highly targeted from who is highly susceptible so you're not treating both problems with the same intervention.

Tailor. Route interventions by tier and by channel. Someone who fails vishing simulations but passes email tests needs voice-specific training, not a repeat of the same phishing module.

Build in extra scrutiny around known risk-spike periods: mergers and acquisitions, layoffs or restructuring, quarter-end financial pressure, and open-enrollment benefits season all create windows where attackers lean on urgency and organizational disruption, and where baseline scores tend to understate real susceptibility. Treat these as scheduled re-baseline points rather than waiting for the monthly cycle to catch the spike after the fact.

Track. Review trends monthly, not annually. Watch mean time to report, the repeat-offender cohort specifically rather than just the overall average, and risk-score movement by department, and roll a summary up to leadership on a fixed cadence.

Run this as a monthly operating rhythm and the score stays current. Run it as an annual audit and it's stale before you finish training the first cohort.

KPIs That Prove the Program Is Reducing Breach Risk

Completion rate, seat count, and module pass rate measure attendance, not risk reduction. Replace them with outcome metrics:

• Report rate: the percentage of simulated (and real) phishing attempts employees actually report. This is widely considered the single highest-value behavior KPI because it's a positive signal, not just an absence of failure.

• Mean time to report (MTTR): how fast employees flag a suspicious message once it lands. Faster MTTR shortens the window attackers have to act on a real credential.

• Repeat-offender rate: the share of failures coming from employees who have already failed before. A shrinking repeat-offender cohort means interventions are working; a stable one means they aren't.

• Risk-score movement by department: track the trend, not just the snapshot, so you can show leadership the score is actually moving in response to the program.

• High-risk-employee velocity: how quickly people move out of High and Critical tiers once flagged.

Track leading indicators, like MFA gaps, password-manager adoption, and repeat-failure trend, alongside lagging ones like click rate and incident count. Leading indicators predict future failure; lagging indicators only confirm it already happened. A program that reports on lagging indicators exclusively is always a step behind, which is the same gap covered in more depth when measuring security awareness training effectiveness.

For the business case, IBM's 2025 Cost of a Data Breach Report found that organizations with strong employee training programs lowered average breach costs meaningfully compared to those without, which gives you a defensible, if illustrative, way to frame the program's ROI to leadership: fewer high-risk employees and a shrinking repeat-offender cohort translate directly into a lower probability of the kind of incident that drives that average cost up.

A simple version of this math, useful for a board slide rather than a precise forecast: take the average breach cost from a source like IBM's report, multiply by your organization's estimated annual likelihood of a human-error-driven incident, and compare that figure before and after a defined period of scored, continuous training. You're not claiming the program caused a specific dollar amount of avoided loss. You're showing that the leading indicators feeding the estimate (repeat-offender rate, report rate, high-risk-employee count) moved in the right direction, and pricing that movement in terms leadership already uses to evaluate risk.

Why Continuous Scoring Beats Annual Training

A widely cited UChicago/UCSD study presented at IEEE S&P and Black Hat 2025 found no meaningful correlation between generic annual training and reduced phishing failure rates. That finding gets used to argue training doesn't work, but a closer look at why phishing simulations fail points to a narrower reading: the criticism lands on annual, generic, completion-focused programs, not on continuous, adaptive, scored ones. KnowBe4's 2025 benchmark, drawn from over 67 million simulations across more than 62,000 organizations, found phish-prone rates dropping from a 33.1% baseline to 4.1% after 12 months of continuous simulation and training, an 86% relative reduction. A separate controlled study (arXiv:2510.27298, October 2025, 13,000 simulations across 1,300+ employees over 12 months) found continuous simulation and training roughly halved phishing susceptibility. How the program is designed, continuous and adaptive versus annual and generic, predicts the outcome far more than whether training exists at all.

Keeping the Score a Coaching Tool, Not Surveillance

Individual-level risk scoring carries a real governance risk: it can slide into surveillance, produce false positives, or push employees to game the metric by over-reporting or avoiding tests rather than genuinely improving.

Build guardrails in from the start:

• Report scores to leadership at the aggregate or department level, not as a ranked list of named individuals.

• Frame individual feedback as coaching, not punishment. Punitive framing is one of the fastest ways to suppress honest reporting.

• Publish a policy that draws a clear line between security measurement and behavioral surveillance, and hold the program to it.

Governance isn't a side issue here: it directly affects data quality. A program employees trust generates more honest reporting, which makes the score more accurate; a program employees fear generates gamed data, which makes the score worthless.

There's also growing external pressure to get this right. Regulations like NIS2 increasingly expect behavioral evidence of a working program, not just training-completion paperwork, and cyber insurers are starting to factor human risk program maturity into renewal terms. A governed, well-documented scoring approach satisfies that scrutiny; an ungoverned one that surfaces named individuals to non-security stakeholders creates its own liability.

Mistakes That Undermine a Human Risk Scoring Program

A few recurring failure patterns show up across programs that never get real traction:

• Scoring only lagging indicators. Click rate and incident count tell you what already happened. Without leading indicators like MFA gaps or repeat-failure trend, the program can't get ahead of the next incident.

• Skipping role normalization. Scoring everyone on the same absolute scale just reproduces the org chart instead of measuring behavior.

• Punitive framing. Score people to punish them and they learn to game the metric instead of improving; score them to coach them and the data stays honest.

• Single-channel scoring. Email-only simulation misses vishing and deepfake attack simulations, plus hybrid attacks, that are now a material part of the threat landscape. A score that only tests one channel systematically underestimates susceptibility.

• Treating the score as a one-time project. A score calculated once and never revisited is a snapshot, not a program.

• Tiers with no attached action. If High and Critical tiers don't trigger a specific, different intervention than Low, the tiering exercise is cosmetic.

Each of these traces back to the same root cause: building the score as a reporting exercise instead of an operating mechanism.