Start by auditing the current security stack and mapping which tools generate useful behavioral, identity, and threat data. Then identify integration points and establish governance for data sharing before building dashboards or risk scores. If the input data is fragmented or poorly governed, any downstream human risk model will be incomplete and hard to trust.
Why the data inventory comes before the risk score
A centralized human risk programme lives or dies on the quality of its inputs. If teams start with dashboards or scoring logic before they know which sources contain useful behavioural, identity, and threat data, they usually end up encoding gaps rather than insight. The first job is to understand what telemetry exists, who owns it, and whether it can be shared lawfully and consistently across security, HR, and IT. The NIST Cybersecurity Framework 2.0 is useful here because it emphasises governance and outcome-driven risk management before tooling decisions.
Many organisations underestimate how much “human risk” is actually a data integration problem, not an analytics problem. In practice, many security teams encounter flawed risk scoring only after fragmented logging, inconsistent identity records, and unclear data ownership have already distorted the model.
How the programme should be built in practice
The most reliable sequence is to treat the programme as a data-and-governance foundation first, then layer analytics on top. Start by cataloguing the security tools already in use, such as email security, endpoint detection, IAM, PAM, SIEM, training platforms, and incident response systems. For each one, decide what human-risk signal it can actually produce, whether that signal is current enough to be useful, and whether it is trustworthy enough to support a decision. A tool that generates a lot of alerts is not automatically a good source for human-risk scoring if it lacks consistent identifiers or produces noisy events.
Next, map the integration points. The key question is not simply “can we connect it?” but “can we correlate it to a person, role, or access pattern without creating ambiguity?” That usually requires agreement on identity matching, event taxonomy, and data retention. Without those basics, one system may count a behaviour as a policy violation while another records it as normal activity, which makes the resulting programme hard to defend.
Governance should be established before dashboards are published. That means defining who can approve new data sources, who can consume the outputs, how often the programme will be reviewed, and what happens when a source becomes unavailable or unreliable. The strongest programmes also define the minimum evidence required before any score is operationalised. If the scoring model cannot be traced back to clear source data and agreed handling rules, it should be treated as exploratory rather than authoritative.
- Inventory the sources first, then decide which ones deserve inclusion.
- Standardise identities and event labels before building correlation logic.
- Set ownership and approval rules for every data feed.
- Keep low-confidence or stale sources out of operational scoring.
This approach aligns the programme to actual operating reality, not to a hoped-for data model. It also reduces the chance that a polished dashboard obscures weak source governance. The guidance breaks down when an organisation cannot establish shared ownership of the underlying data, because without that agreement the programme becomes a reporting exercise rather than a risk-control function.
Where human risk programmes go wrong at the start
Centralising risk data often increases coordination overhead, so organisations must balance analytic ambition against governance discipline. The biggest early mistake is treating every available feed as equally valuable and then trying to fix quality later. Another common error is collapsing behavioural data, identity data, and threat data into one score without preserving the differences in source reliability or meaning.
There is also a genuine tradeoff between speed and trust. Fast deployment can deliver an initial view of risk, but it can also lock in weak assumptions about attribution, access context, and data completeness. The better practice is to accept a narrower programme at first, because a smaller set of well-governed signals is usually more defensible than a broader model built on inconsistent inputs.
Where there is disagreement in the industry, it is usually not about whether data matters but about how much standardisation is enough before scoring begins. Our view is that the threshold should be set by decision impact: if the programme will drive manager escalation, access review, or disciplinary action, then the source data and governance model need to be substantially stronger than if the output is only used for internal exploration.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST CSF 2.0 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | GV.RM — Risk Management Strategy | Centralised human risk programmes depend on governed risk data and decision scope. |
| GV.OV — Oversight | The programme needs accountable ownership for data sources and approvals. | |
| ID.IM — Identity Management, Authentication, and Access Control | Human-risk scoring often relies on reliable identity correlation and access context. | |
| Recommendation — Define the risk inputs and decision uses before you operationalise scoring. Assign accountable oversight for source approval and model changes. Standardise identity correlation so behavioural signals map to the right person. | ||
| CIS Controls v8 | 5 — Account Management | Human-risk programmes depend on accurate account-to-person mapping and ownership. |
| 8 — Audit Log Management | The programme depends on trustworthy logs and consistent event sources. | |
| 14 — Security Awareness and Skills Training | Behavioural risk programmes often incorporate training and user-interaction data. | |
| Recommendation — Maintain authoritative account ownership before using activity in risk scoring. Collect and validate log sources before trusting human-risk analytics. Use training evidence as one input, not as a substitute for telemetry. | ||
Practitioner Guidance
What to prioritise: Establish source ownership, identity correlation rules, and data-sharing approvals before any attempt to automate scoring. If those three items are not clear, the programme should stay in discovery mode.
What to verify: Confirm that each intended input source produces a signal that is both timely and attributable to a specific person or role. If attribution is fuzzy, keep the feed out of the operational model until the mapping is fixed.
What good looks like: Security, IT, and HR can all explain why a data source is included, what it contributes, and who can change its use. That shared explanation is a better sign of maturity than the first dashboard release.
Practitioner takeaway: The first build step is not modelling; it is deciding which data is trustworthy enough to govern human risk decisions at all.
Related resources from NHI Mgmt Group
- Who is accountable for building a proactive human risk mitigation programme?
- How do organisations know whether a people-centric security programme is actually reducing human risk?
- How should organisations operationalise human risk management without turning it into another awareness programme?
- What should organisations do first when building a cloud security automation programme?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 9, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
