Why do human risk programs need data from behavior, identity, and threats instead of behavior alone?

Why This Matters for Security Teams

Human risk programs become unreliable when they treat a click, a login, or a policy violation as a full story. Behaviour data shows what happened, but not who the person is in the business, what they can reach, or whether a live threat campaign is shaping the event. A single risky action matters far more when it involves privileged access, sensitive data, or an account already in an attack path. That is why correlation across behaviour, identity, and threats is essential.

This is also where many programmes overfit to awareness training and miss exposure management. If risk scores do not account for identity context such as role, privileges, device trust, or service ownership, they can drive noisy coaching while ignoring the accounts that would create the most damage if compromised. Current guidance in NIST Cybersecurity Framework 2.0 supports this broader view by tying governance, protective controls, and detection together rather than isolating one signal source.

Threat context matters as well. A user who is being targeted by credential phishing, a token theft campaign, or an adversary using AI-assisted lures should not be scored the same way as a user generating an isolated policy exception. In practice, many security teams encounter the real cost of behaviour-only scoring only after a high-risk account has already been misused, rather than through intentional exposure-based prioritisation.

How It Works in Practice

Effective human risk analytics combine three layers of evidence. Behaviour tells you whether a person is interacting safely with email, web, SaaS, endpoints, and collaboration tools. Identity tells you what that person can access, how sensitive that access is, whether the account is privileged, and whether the identity is human, delegated, or tightly linked to an automated workflow. Threat data tells you whether current campaigns, known adversary tactics, or sector-specific lures are active against the organisation.

In operational terms, the program should enrich each event with context before assigning a risk score. That usually means joining telemetry from IAM, PAM, endpoint, SIEM, email security, and threat intelligence, then weighting the result by business impact. A failed login is not equal to a failed login if one user has access to source code, finance systems, or production admin paths. This is also where CISA cyber threat advisories become useful, because current campaigns help distinguish background noise from actionable exposure.

• Use behaviour signals for baseline activity and anomalies.
• Use identity signals for role, privilege, authentication strength, and account type.
• Use threat signals for active campaigns, lures, and adversary tactics.
• Weight the combined score by asset criticality and data sensitivity.
• Trigger different actions for coaching, step-up authentication, access review, or incident response.

This is especially important where human accounts intersect with agentic AI, service accounts, or delegated access. A person may authorise an AI workflow, approve a secret, or trigger a privileged action indirectly, so the program must reflect effective control, not just direct keyboard activity. When this linkage is missing, human risk scoring tends to break down in heavily federated SaaS environments and remote-first estates because identity ownership, session context, and threat telemetry are fragmented across too many tools.

Common Variations and Edge Cases

Tighter correlation often increases operational overhead, requiring organisations to balance richer risk decisions against data quality, privacy, and integration cost. There is no universal standard for this yet, so best practice is evolving around the minimum context needed to avoid false confidence rather than around one fixed scoring model.

Some organisations only have reliable behaviour telemetry and limited identity or threat enrichment. In that case, the program can still function, but it should be described as behavioural monitoring rather than true human risk management. Others have strong identity data but weak threat intelligence, which can overstate internal risk while missing live campaigns. The strongest programs usually start with high-value identities, critical business processes, and active threat scenarios, then expand coverage.

AI-driven phishing and social engineering also complicate the picture. The relevant question is not just whether a person clicked, but whether the content was part of an adversary pattern, whether the account had privilege, and whether the organisation had compensating controls in place. Reports such as Anthropic — first AI-orchestrated cyber espionage campaign report and the MITRE ATLAS adversarial AI threat matrix show why context now has to include both human and machine-mediated attack paths. Teams that ignore that shift usually end up reacting to incidents after the account, not the behaviour, has become the true risk.

Related resources from NHI Mgmt Group

• Why do secrets alone not solve non-human identity risk?
• How should security teams use human risk management instead of awareness training alone?
• What should identity and PAM teams do with human risk data?
• What breaks when identity data is not included in human risk scoring?