What breaks when organisations use average risk scores to manage human risk?

Average scores hide outliers. A low organisational average can mask a small group of high-risk users or a team with dangerous behaviours, which creates blind spots for GRC and security teams. Effective programmes focus on individual and team-level signals so they can intervene where the actual risk sits, rather than treating the whole workforce as one uniform population.

Why This Matters for Security Teams

Average human risk scores are attractive because they simplify reporting, but simplification can become loss of signal. A single organisational number can obscure concentrated risk in privileged roles, repeat policy offenders, contractors, or one team with weak control adherence. That matters because security and GRC decisions depend on where exposure is actually accumulating, not on a blended score that looks acceptable in aggregate. The NIST Cybersecurity Framework 2.0 reinforces that governance should support risk-informed action, not just measurement.

The practical issue is that average scores encourage misplaced confidence. Leaders may conclude that training, monitoring, and access controls are working, when in reality the highest-risk users remain untreated. That can distort exception handling, control prioritisation, and incident readiness. It also creates a reporting trap: teams optimise for the metric rather than the underlying behaviour, especially when the score is used as a board-level proxy for workforce risk.

In practice, many security teams encounter the real problem only after a targeted misuse event has already exposed that the average was never a good indicator of who needed intervention.

How It Works in Practice

Human risk programmes work better when they combine population-level reporting with segment-level and individual-level analysis. Averages can still be useful for trend lines, but they should never be the only decision input. Practitioners usually need to separate users by role, privilege, geography, business unit, contractor status, and behaviour patterns, then compare risk distributions rather than just central tendency.

Operationally, this means looking at the tail of the distribution, not only the mean. A handful of users with repeated risky actions can drive material exposure even if 95 percent of the workforce looks well controlled. This is especially important where identity, privilege, and behaviour intersect: users with elevated access, sensitive data reach, or exception-based workflows can change the organisation’s actual risk posture much more than their score contribution suggests. In broader cyber terms, this is closer to control effectiveness analysis than simple workforce sentiment reporting.

• Track median, percentile bands, and outlier counts alongside the average.
• Break scores down by team, role, and entitlement tier.
• Correlate human risk with phishing susceptibility, policy breaches, access anomalies, and training non-completion.
• Use thresholds to trigger review, but validate them against real operational context.
• Treat score movements as indicators, not proof of risk reduction.

Current guidance suggests that a useful programme should be able to explain why a user or group is high risk, not merely that the overall score improved. For identity-heavy environments, that is where NIST thinking on governance and the NIST Cybersecurity Framework 2.0 align with practical workforce risk management. These controls tend to break down when scores are calculated across mixed populations with very different access levels, because the mean hides the users whose behaviour would actually drive loss.

Common Variations and Edge Cases

Tighter risk scoring often increases reporting complexity, requiring organisations to balance analytical accuracy against executive simplicity. That tradeoff is real: more granular views can create more questions, more remediation paths, and less neat dashboards. Still, that complexity is usually preferable to a false sense of control.

There is no universal standard for this yet. Some organisations weight privileged users more heavily, while others use separate scoring models for contractors, third parties, and employees. That approach is usually better than one blended average, but it introduces model governance questions: how are weights set, who approves them, and how often are they recalibrated? If the model is opaque, the programme can become difficult to defend in audit or board review. The most mature teams document the assumptions behind each segment and keep the score operationally tied to control actions, such as targeted coaching, access review, or enhanced monitoring. The NIST Cybersecurity Framework 2.0 is useful here because it supports governance, measurement, and continual improvement rather than one-off scoring.

The main exception is a very small organisation with a uniform user population and limited privilege diversity, where averages may be directionally useful for early trend spotting. Even there, they should remain a starting point, not the decision rule.

Related resources from NHI Mgmt Group

• What breaks when organisations only use password policy to manage credential risk?
• What breaks when organisations use human IGA for non-human identities?
• What breaks when organisations manage service accounts like human users?
• What breaks when organisations use one IAM model for humans and non-human identities?