Who is accountable for keeping access changes aligned when employees change roles?

Why This Matters for Security Teams

When employees change roles, access drift is rarely caused by one missed approval. It usually comes from split accountability across HR, identity governance, application owners, and managers, each assuming another system will catch the change. That gap turns mover events into privilege creep events, especially where entitlements, SaaS licenses, and group membership are managed separately.

For non-human identities, the same failure pattern is amplified because service accounts, API keys, and automation roles often sit outside standard joiner-mover-leaver workflows. The Ultimate Guide to NHIs notes that only 20% of organisations have formal processes for offboarding and revoking API keys, which shows how often lifecycle ownership is still incomplete. OWASP also treats entitlement drift as a core identity risk in the OWASP Non-Human Identity Top 10.

Security teams should treat mover handling as an accountability problem, not just a ticketing problem. In practice, many organisations discover stale access only after a role change has already widened the blast radius.

How It Works in Practice

Accountability should be explicit and operational, not implied. HR normally owns the authoritative job-change event, identity teams own the access orchestration, and application owners own the entitlement decision for their systems. Managers typically approve business need, but they should not be the only control. The goal is to make every mover event trigger a defined review of access, with a named owner for each step.

A practical workflow usually starts when HR updates the employee record, which then feeds identity governance or PAM processes. The access review should check role-based entitlements, direct app permissions, group membership, privileged roles, and any linked secrets or automation accounts. Where mature controls exist, the review is policy-driven and time-bound, not manual and open-ended. NIST describes this kind of access governance through security controls in NIST SP 800-53 Rev. 5, especially around least privilege, access enforcement, and account management.

• HR confirms the move and sends the change event.
• Identity governance recalculates baseline access for the new role.
• Application owners approve exceptions where role templates do not fit.
• PAM or privilege workflows remove temporary elevation that is no longer needed.
• Audit teams verify that approvals, revocations, and timestamps are recorded.

For NHIs, the same pattern needs a stronger lifecycle boundary. The Ultimate Guide to NHIs highlights how excessive privilege and weak visibility make unmanaged access persist far longer than teams expect. These controls tend to break down when role changes are handled in spreadsheets or email because no system owns the final revocation step.

Common Variations and Edge Cases

Tighter mover controls often increase administrative overhead, requiring organisations to balance faster employee transitions against stronger entitlement review. There is no universal standard for this yet, especially where the same person splits time across functions, subsidiaries, or regulated environments.

One common variation is role mapping by department versus by actual duty. Department-level mappings are easier to maintain, but they often overgrant access when job scope changes within the same team. Another edge case is shared or inherited access, where a mover event should not only remove direct permissions but also evaluate nested group membership, delegated admin rights, and linked service accounts. Best practice is evolving toward continuous verification rather than annual cleanup.

For agentic or automated workloads, the accountability model becomes stricter because access may be tied to a process owner rather than a human manager. In those cases, current guidance suggests pairing business ownership with technical ownership so that approval, revocation, and exception handling are all traceable. The NHI community has documented how often blind spots persist in real systems, and the broader breach evidence in 52 NHI Breaches Analysis shows why mover-like lifecycle failures deserve formal ownership.

Related resources from NHI Mgmt Group

• Who is accountable for keeping RBAC aligned with job changes and compliance requirements?
• Who should be accountable for SSH access when employees leave or change roles?
• Who is accountable for keeping authorization approvals current when policy changes after a request is submitted?
• Who is accountable when privileged ERP access allows an inappropriate change to financial or supplier data?