What do security teams get wrong about behaviour-based risk programmes?

They often measure completion, not change. A useful programme must show whether risky behaviour declines, whether repeat offenders are resolved, and whether interventions actually reduced exposure. If the metrics only show training attendance or campaign clicks, the programme is producing documentation rather than control improvement.

Why This Matters for Security Teams

Behaviour-based risk programmes are meant to reduce exposure from unsafe actions, not just record that awareness activity happened. That distinction matters because attackers usually succeed when normal users, contractors, or administrators repeat predictable mistakes under pressure. The most useful programmes connect behaviour change to outcomes such as fewer risky approvals, fewer credential-sharing incidents, and faster escalation when something looks suspicious. The NIST Cybersecurity Framework 2.0 is helpful here because it pushes teams to think in terms of governance, detection, response, and improvement rather than isolated awareness events.

Many programmes fail when they are treated as a communications exercise instead of a control system. That usually leads to reports full of completions, clicks, and attendance counts, while the underlying behaviour stays the same. Security leaders also miss the difference between individual learning and systemic risk reduction: a person can remember a message and still work around policy if the workflow makes the unsafe path easier. In practice, many security teams encounter the failure only after repeated exceptions, weak approvals, or credential misuse have already become normalised.

How It Works in Practice

A behaviour-based programme should start by defining the specific risky actions that matter most in the environment. That can include poor password habits, repeated policy overrides, unsafe file sharing, ignoring phishing warnings, over-permissioned access requests, or delayed incident reporting. The key is to tie each behaviour to a measurable control objective, then decide what “better” looks like in operational terms. The goal is not to punish people for mistakes; it is to change the conditions that make those mistakes repeat.

Practitioners usually get better results when they combine telemetry, workflow controls, and targeted intervention. For example, a team might track whether repeated risky actions fall after nudges, whether managers approve exceptions less often, or whether high-risk groups need different guidance. Useful data sources often include identity logs, endpoint alerts, ticketing records, email simulations, and access review outcomes. Where identity and privilege are part of the issue, the same logic should apply to NHI and service accounts, because unmanaged credentials and automation can create the same exposure pattern at higher speed.

• Define the behaviour you want to reduce in observable terms.
• Link each behaviour to a control owner and a remediation path.
• Measure repeat behaviour, not just one-time participation.
• Check whether the intervention changed workflow, approval, or access patterns.
• Separate awareness metrics from risk metrics so reporting stays honest.

Current guidance suggests using trend analysis over time rather than one-off campaign scores. That approach aligns with NIST Cybersecurity Framework 2.0 and with incident-driven operating models that value reduction in exposure, not activity for its own sake. These controls tend to break down when the organisation has fragmented identity data, because the same risky behaviour cannot be traced consistently across systems, roles, and delegated accounts.

Common Variations and Edge Cases

Tighter behaviour monitoring often increases privacy, employee-relations, and operational overhead, requiring organisations to balance visibility against trust and usability. That tradeoff matters because overly aggressive surveillance can cause workarounds, while weak monitoring produces vanity metrics that do not change risk. Best practice is evolving, and there is no universal standard for how much behavioural instrumentation is appropriate in every workplace.

Edge cases appear when the behaviour is driven by process design rather than user carelessness. If a team keeps approving exceptions because the secure path is too slow, the problem is not just user behaviour. If contractors or third parties are involved, accountability becomes even harder because the organisation may not control their training, devices, or access lifecycle. Where AI tools are involved, teams should also watch for prompt-sharing, data leakage, and unsafe use of agent privileges, since those are behaviour issues even when the actor is a system rather than a person.

For programmes to hold up, the metrics should answer three questions: did the risky behaviour decline, did repeat cases get resolved, and did the intervention reduce exposure in a way that defenders can verify? If the answer is no, the programme is likely measuring motion rather than control. The most credible evidence is behavioural change plus lower operational risk, not course completion alone.

Related resources from NHI Mgmt Group

• What do security teams get wrong about risk assessment in identity programmes?
• What do security teams get wrong about spreadsheet-based control evidence?
• What do security teams get wrong about data visibility and NHI risk?
• What do security teams get wrong about passwordless authentication and AI risk?