Start by correlating three data sets: behaviour, identity and access, and threat intelligence. That gives you a baseline that is operationally useful because it ties risk to who can act, how they behave, and whether adversaries are actively targeting them.
How to build the baseline before you score people
The first move is to make the benchmark operational, not theoretical. Correlate behaviour, identity and access, and threat intelligence into one baseline so you can see which users, accounts, and entitlements actually create risk, rather than measuring activity in isolation. That is the point where a human cyber risk benchmark becomes decision-useful.
A useful baseline should answer three questions at once: what the person did, what they could do, and whether the environment suggests adversary interest. If any of those dimensions is missing, the result is usually a partial view that overstates noise or understates exposure. For a baseline to matter, it must connect observable behaviour to the access path that makes harm possible.
That correlation also forces teams to normalise the data before they interpret it. Behavioural events, identity records, and threat feeds often use different naming, timestamps, and asset references, so the benchmark should reconcile them to a common user, account, and system model. Without that alignment, the output looks precise but cannot support defensible prioritisation.
Why identity and access have to be part of the first pass
Human cyber risk is not just about suspicious conduct. It also depends on whether the person has privileged access, excessive access, access to sensitive workflows, or a path into high-value systems. If the benchmark ignores identity and access, it cannot distinguish a noisy user from one whose permissions make a minor anomaly materially important.
That is why access context belongs in the opening layer of the benchmark, not as a later enrichment step. A login from a normal device means something different when the account can approve payments, administer cloud resources, or reset credentials. The benchmark should therefore be built around effective authority, not just event frequency.
For teams already working on identity governance, this is where the method should connect to access review, entitlement visibility, and account ownership. NHIMG’s CISA contractor GitHub leak case is a good reminder that exposed credentials become far more serious when they map to real administrative reach, and the benchmark should surface that relationship early.
How threat intelligence changes the benchmark from descriptive to actionable
Threat intelligence gives the benchmark external context. It tells you whether the behaviour you are seeing is merely unusual or part of a pattern that adversaries actively exploit, such as phishing, credential theft, or targeting of specific roles and departments. That context prevents teams from treating all deviations as equal.
The practical value is prioritisation. A user with moderate anomalies but no threat pressure may warrant monitoring, while a user with similar behaviour and a current threat campaign against their sector, geography, or function may need faster review. The benchmark should therefore combine internal telemetry with threat signals that explain why some users move up the queue.
That same logic is what makes the output useful to SOC, IAM, and risk teams together. Behaviour alone can tell you what happened, identity and access can tell you what could be done, and threat intelligence can tell you how urgently to act. Used together, they create a baseline that supports investigation instead of producing another dashboard.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK addresses the attack and risk surface, while NIST SP 800-53 Rev 5, NIST CSF 2.0 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | IA-2 — Identification and Authentication (Organizational Users) | Human risk benchmarking depends on knowing which user/account performed the activity. |
| AC-6 — Least Privilege | Access breadth changes whether a user's behaviour is operationally risky. | |
| Recommendation — Tie behavioural signals to authenticated user identities before scoring risk. Prioritise users whose access exceeds their job need. | ||
| NIST CSF 2.0 | ID.AM-01 — Physical devices and systems within the organization are inventoried | A benchmark needs a reliable inventory of actors and assets to correlate signals. |
| Recommendation — Maintain a current inventory that links users, accounts, and systems. | ||
| MITRE ATT&CK | T1110 — Brute Force | Threat intelligence often flags the credential-abuse patterns that shape human risk. |
| Recommendation — Map observed account abuse to credential attack techniques in detection logic. | ||
| CIS Controls v8 | CIS-5 — Account Management | Human cyber risk benchmarking depends on accountable, current account and entitlement data. |
| Recommendation — Review and clean account ownership and access rights before scoring individuals. | ||
Practitioner Guidance
What to prioritise: Start with the few data sets that change the decision, not the most data sets available. If behaviour cannot be tied to identity and effective access, the benchmark will not separate genuine human risk from routine activity.
What to verify: Confirm that every scored person or account has an owned identity, current entitlement view, and a threat context source that updates often enough to matter. If any one of those is stale, the benchmark will drift toward false confidence.
Decision rule: If an account combines unusual behaviour with privileged access or current threat interest, escalate it ahead of users who only score high on one dimension. The benchmark should reward converging signals, not isolated ones.
Practitioner takeaway: The first benchmark should not try to rank everyone perfectly, it should make risk explainable enough that teams can see who can act, what they did, and why the threat environment makes that combination matter.
Related resources from NHI Mgmt Group
- What should teams do first when building a defense against future cyber attacks driven by human manipulation?
- How should security teams govern non-human identities at scale?
- How should security teams govern non-human identities for compliance?
- Why do non-human identities create more audit risk than human accounts?