Why do human risk programmes need identity and access data, not just phishing results?

Phishing outcomes show exposure, but they do not show impact. Identity and access data tells you whether a risky action came from a low-privilege user or someone with access to sensitive systems. That context is essential for prioritising response. Without it, security teams overreact to low-impact mistakes and miss the people whose access turns small errors into serious incidents.

Why This Matters for Security Teams

Phishing results only tell part of the story. A click, credential submission, or MFA prompt fatigue event is a useful signal, but it does not say whether the user had access to finance systems, admin consoles, or sensitive customer data. Human risk programmes need identity and access data because impact depends on privilege, not just exposure. That context helps security teams separate noisy behaviour from the accounts that can actually move risk.

This is also where identity telemetry connects human risk to business risk. The NIST Cybersecurity Framework 2.0 emphasizes governance and risk prioritisation, while the OWASP Non-Human Identity Top 10 shows how access sprawl and poor credential hygiene create outsized exposure. NHIMG research also shows why context matters: the Ultimate Guide to NHIs reports that 97% of NHIs carry excessive privileges, a reminder that access level often determines whether a mistake becomes an incident.

Without identity and access data, risk scores tend to flatten everyone into the same bucket. In practice, many security teams discover the real blast radius only after a low-severity phishing event reaches a privileged mailbox, a cloud admin role, or a service account chain that should never have been reachable in the first place.

How It Works in Practice

Effective human risk programmes enrich phishing outcomes with identity, entitlement, and access-path data. The workflow is straightforward: start with the event, identify the user, map that user to roles, groups, applications, and privileged entitlements, then score the event based on reachable assets. A click on a training account is not the same as a click by a payroll administrator with delegated access to payroll export tools.

This is where identity governance and access analytics make the programme operational. Teams commonly combine mail telemetry, SSO logs, IAM data, PAM records, and directory attributes to answer four questions: who acted, what they can reach, whether the access is privileged or sensitive, and whether the account is already over-entitled. That approach aligns with the control logic behind NIST SP 800-53 Rev. 5 Security and Privacy Controls, especially the principle that access decisions should reflect role, need, and monitoring expectations.

• Use phishing as a trigger, not the full risk model.
• Enrich each event with directory, SSO, and PAM data.
• Prioritise users with admin, finance, legal, customer data, or production access.
• Escalate when the account has standing privilege, weak MFA posture, or broad group membership.
• Feed outcomes into coaching, access review, and privilege reduction.

NHIMG’s Top 10 NHI Issues highlights how excessive privilege and poor visibility consistently drive exposure, and the same pattern applies to human accounts. These controls tend to break down in hybrid environments where identity data is fragmented across multiple directories, SaaS platforms, and legacy PAM systems because no single control plane sees the full access path.

Common Variations and Edge Cases

Tighter identity enrichment often increases data integration and governance overhead, requiring organisations to balance sharper prioritisation against privacy, tooling, and operations constraints. There is no universal standard for how much identity context a human risk score must include, so current guidance suggests starting with the access that changes incident impact most: privileged roles, sensitive applications, and accounts with standing admin rights.

Some programmes overfocus on phishing severity and ignore account context until after a breach review. Others collect too much identity data without a clear action model, which creates reporting noise instead of usable prioritisation. Best practice is evolving toward risk tiers that reflect exposure plus privilege, rather than click rates alone. That makes the programme more defensible to leadership because it explains why one careless click deserves immediate response while another merits coaching only.

Edge cases matter. Shared accounts, contractor identities, dormant access, and service-linked human workflows can distort scoring if the programme assumes one person equals one risk profile. NHIMG’s 52 NHI Breaches Analysis is a useful reminder that hidden access paths often drive the worst outcomes. In practice, the model works best when identity context is refreshed continuously, and when security teams treat access removal or privilege reduction as a response option, not just awareness training.

Related resources from NHI Mgmt Group

• Why do identity and privilege data matter in human risk programmes?
• Why do phishing simulations need to be linked with identity and access data to be useful for risk reduction?
• Why do non-human identities create more audit risk than human accounts?
• How should security teams run access reviews for non-human identities?