What should organisations do when a human risk dashboard shows persistent risk in one department?

Why This Matters for Security Teams

A persistent risk hotspot in one department is usually a signal that the problem is structural, not just behavioral. Security teams should treat the dashboard as an operational diagnostic: recurring risk can point to overloaded workflows, unclear ownership, weak manager enforcement, or access models that force people into unsafe workarounds. The right response is not a broad awareness campaign, but a focused review of the local control environment, informed by NIST Cybersecurity Framework 2.0 and the broader identity patterns described in Ultimate Guide to NHIs — Key Challenges and Risks. NHI Management Group research shows that 97% of NHIs carry excessive privileges, which is a useful reminder that repeated risk often reflects design failure, not individual neglect.

When the same department keeps surfacing, teams should ask whether the process itself is creating repeated exceptions, whether access is broader than the role requires, and whether local leadership is reinforcing the policy in practice. In practice, many security teams encounter the real source of persistent risk only after an audit finding, a policy exception backlog, or a control failure has already become normalised in that department.

How It Works in Practice

The practical response starts with narrowing the scope. Review the specific behaviors, systems, and approval paths linked to the department’s risk score, then separate people issues from process issues. If the dashboard flags recurring phishing susceptibility, for example, look at message volume, task pressure, and whether staff are expected to move quickly through risky workflows. If it flags access misuse, inspect role definitions, entitlement creep, and whether managers are approving exceptions without a clear business need.

A targeted response usually combines three actions:

• Reset the local workflow so the risky behavior is less likely to happen, rather than only warning users not to repeat it.
• Re-check access against the actual role, using least privilege and manager accountability to remove unnecessary friction and excess access.
• Use the dashboard to confirm whether the intervention changes the pattern over time, then escalate only if the same failure mode persists.

For access-heavy departments, NIST SP 800-53 Rev. 5 Security and Privacy Controls is a useful reference point for aligning local controls with broader governance requirements. The pattern also maps well to The 2024 ESG Report: Managing Non-Human Identities, which shows how repeated exposure often reflects weak governance and over-privileged identity design. Where the department’s work depends on shared accounts, long-lived credentials, or frequent exceptions, control tuning matters more than repeat training. These controls tend to break down when the department relies on informal approvals and exception-driven access, because the dashboard then measures a broken process rather than individual risk.

Common Variations and Edge Cases

Tighter intervention often increases coordination overhead, requiring organisations to balance faster remediation against local productivity and manager bandwidth. That tradeoff matters because not every persistent risk score means the same thing. Current guidance suggests that repeated low-severity findings may indicate a process issue, while repeated high-severity findings should trigger management review and possibly access restriction. There is no universal standard for when to move from coaching to control redesign, so teams should use severity, recurrence, and business impact together.

Some departments also generate false confidence because the work is highly visible but the real risk sits elsewhere, such as in a shared service team, a system admin group, or an embedded automation process. In those cases, the dashboard may point at the wrong user population while the root cause is actually an upstream control gap. NHI Management Group’s Top 10 NHI Issues is a helpful reminder that identity problems often cascade across teams when privileges, secrets, and ownership are not clearly bounded.

If the department is operating under heavy compliance pressure, leaders should avoid turning every repeat event into disciplinary action. The better test is whether the control environment is forcing predictable failure. If it is, the correct response is redesign, not blame.

Related resources from NHI Mgmt Group

• Why do non-human identities create more audit risk than human accounts?
• How should security teams govern non-human identities that have persistent access?
• Why do non-human identities create audit risk in modern environments?
• Why do non-human identities create compliance risk even when policies exist?