They should prioritise both together, because neither explains severity on its own. Behaviour shows what happened, while access context shows how damaging it could be. A low-risk action by a privileged user can matter more than a repeated minor mistake by a standard user, so the programme has to score the combination.
Why behaviour and access context should be scored together
Human risk programmes work best when they combine behaviour and access context into a single judgement. Behaviour tells you whether an action was unusual, careless, or potentially malicious. Access context tells you how much authority the person had at the moment, which is what determines whether the same behaviour is merely noisy or genuinely dangerous.
That distinction matters because risk is rarely proportional to the behaviour alone. A routine mistake from a user with no meaningful access may be annoying but contained, while the same action by someone with elevated privileges, broad data reach, or production control can become a material security event.
Programs that score only behaviour tend to overreact to frequent low-impact events and underweight high-impact ones. Programs that score only access tend to assume every privileged actor is equally risky, which misses whether the current behaviour is actually suspicious, accidental, or consistent with legitimate work.
What each signal contributes to the risk picture
Behaviour is the signal that something changed. It can show policy drift, account takeover, unsafe shortcuts, or patterns that deserve review. Access context is the signal that a change could matter, because it tells you what systems, data, or control paths were exposed to the actor at the time.
The practical question is not which signal is “better”, but which one changes the severity decision when combined with the other. A minor policy violation becomes more serious if the user can approve payments, modify security settings, or export sensitive data. A privileged session becomes more concerning if the behaviour shows unfamiliar timing, destination, volume, or sequence.
This is why strong programmes treat behaviour and access as mutually reinforcing dimensions. Behaviour helps find the event, and access context helps estimate blast radius. If either dimension is missing, the score can be directionally useful but incomplete.
How practitioners should apply the combined model
Prioritise the combination whenever the programme is deciding what to review first, what to escalate, or what to suppress. The most useful model is usually a weighted one: start with the observed action, then adjust for current privilege, resource sensitivity, and whether the identity can perform the same action repeatedly or at scale.
One useful rule is to treat access context as the multiplier and behaviour as the trigger. That keeps teams from ignoring subtle events performed by powerful users, while still preventing every privilege assignment from being treated as an incident on its own.
In practice, this also improves triage quality. It helps analysts separate a harmless anomaly from a real exposure, and it gives managers a more defensible way to explain why some events are escalated even when the observable behaviour looked small on its face.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5 sets the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | AC-2 — Account Management | Accounts and assigned access shape the severity of human-risk events. |
| AC-6 — Least Privilege | Least privilege is central to judging whether behaviour can cause material harm. | |
| AU-6 — Audit Review, Analysis, and Reporting | Behavioural signals need review and context to drive triage decisions. | |
| Recommendation — Review assigned access and revoke or reduce unnecessary permissions. Limit user permissions so suspicious actions have a smaller blast radius. Correlate audit events with privilege context before escalating cases. | ||
| ISO/IEC 27001:2022 | A.5.15 — Access control | Access control determines who can do what and changes event severity. |
| A.8.2 — Privileged access rights | Privileged rights are the main context variable that amplifies human risk. | |
| Recommendation — Align access decisions with business need and review exceptions promptly. Tighten privileged access and review it more frequently than standard access. | ||
Practitioner Guidance
What to prioritise: Start with the combination of event and entitlement, not either one in isolation. If the behaviour is unusual and the access path is powerful, treat the case as higher priority even before proving intent.
What to verify: Confirm whether the user could have reached sensitive systems, approved actions, or exposed data at the time of the event. Also check whether the behaviour matches the person’s normal role, working pattern, and history.
Decision rule: If the behaviour is low-signal but the access is high-impact, escalate for review. If the behaviour is noisy but the access is low-impact, keep it in a lower-priority queue unless there is evidence of repetition, coordination, or privilege creep.
Practitioner takeaway: Behaviour finds the signal, but access context determines whether that signal should change the organisation’s response. The best programmes score both together so severity reflects real blast radius, not just visible oddness.
Related resources from NHI Mgmt Group
- Why do human risk programmes need to include AI agents in access and behaviour analysis?
- Why do non-human identities create more audit risk than human accounts?
- How should security teams run access reviews for non-human identities?
- How should security teams govern non-human identities that have persistent access?