Who should be accountable when employee impersonation creates access risk across HR, IT, and security?

Why This Matters for Security Teams

Employee impersonation is not just an HR fraud issue or an IT provisioning mistake. It becomes a security problem when one false identity event can trigger account creation, role assignment, payroll changes, or privileged access before anyone confirms the request. That is why accountability must be shared across the entire identity lifecycle, not isolated inside a single function. NHI Management Group’s research shows how quickly identity control gaps become operational risk, especially when access is granted before validation is complete. See Ultimate Guide to NHIs — Why NHI Security Matters Now and the NIST Cybersecurity Framework 2.0 for the broader governance pattern.

In practice, impersonation often succeeds because no single team owns the full chain from identity proofing to access revocation, so each team assumes another has already validated the request.

How Accountability Should Be Divided in Practice

Accountability should be assigned by control point, with one coordinating owner for the overall program. HR is accountable for employment-status validation, onboarding triggers, and identity proofing evidence. IT is accountable for account lifecycle actions, directory changes, and access provisioning. Security is accountable for detection, monitoring, escalation, and review of suspicious access patterns. Legal and compliance should define evidence retention, approval thresholds, and audit requirements. This structure matches the way identity risk actually moves across systems, rather than pretending one department can manage all of it.

A practical model is to use shared workflows with explicit handoffs. For example, HR should not directly request privileged access, and IT should not provision accounts on verbal confirmation alone. Instead, requests should flow through documented checks, with stronger validation for remote hires, urgent exceptions, and changes to banking, payroll, or executive account data. Guidance from OWASP Non-Human Identity Top 10 and NIST control baselines reinforce the same principle: sensitive access changes need traceable authorization, not informal trust.

NHIMG’s 52 NHI Breaches Analysis also shows how identity misuse becomes a breach path when controls are fragmented. The right accountability model gives one owner for orchestration, but each team still owns its own control outcomes. These controls tend to break down in fast-moving HR environments, merger integrations, and outsourced service desks because exception handling becomes more trusted than verification.

Common Variations and Edge Cases

Tighter identity controls often increase onboarding friction, requiring organisations to balance speed against assurance. That tradeoff becomes more visible when contractors, executives, temporary workers, or third-party administrators need access quickly. Best practice is evolving, but current guidance suggests that the answer is not to weaken controls for convenience. It is to predefine exception paths, require stronger evidence for high-risk requests, and make the approver accountable for the risk they accept.

One important edge case is the shared-service model. When HR operations, IT service desk work, or security monitoring are outsourced, accountability cannot be outsourced with them. The internal organisation still owns the risk, even if a vendor performs the task. Another edge case is impersonation that starts as a human issue and becomes a broader identity compromise, especially when the attacker pivots into password resets, mailbox access, or privileged system changes. In those cases, the control question is not only who approved the access, but who owned the monitoring and revocation path after approval.

For identity governance programs, the practical answer is to measure end-to-end outcomes: validated requests, denied impersonation attempts, time to revoke bad access, and cross-team escalation speed. The Ultimate Guide to NHIs and Top 10 NHI Issues are useful references for mapping those responsibilities into operational controls.

Related resources from NHI Mgmt Group

• Who is accountable for access certification when business roles span finance, HR, IT, and contractors?
• How should security teams structure SAP ABAP access to reduce the risk of unauthorized changes in production systems?
• Who is accountable when AI gateway policy drift causes inconsistent security or performance across clouds?
• Who is accountable for deciding how access tokens are requested and refreshed across heterogeneous API providers?