Who should be accountable for access when an employee transfers to a new team?

Accountability should sit with the current business owner, not only with HR or central IT. HR can trigger the event, but the receiving manager and application owner must confirm the access set matches the new role. Without named ownership, mover events become gaps that nobody closes.

Why This Matters for Security Teams

Accountability for mover access is a control issue, not just an HR workflow issue. When an employee changes teams, access does not fail all at once; it accumulates through shared drives, SaaS roles, API keys, and exception handling. That is why named ownership matters. The current business owner is the only party who can confirm whether access still matches the job function, while HR can only trigger the event and central IT can only execute the change.

This pattern is closely aligned with what NHI Mgmt Group documents in the Ultimate Guide to NHIs: identity risk grows when ownership is diffuse and lifecycle actions are not assigned to a specific accountable party. In practice, teams often discover over-entitlement only after a transfer has already created a new set of permissions that nobody reviewed, not through a clean approval trail or deliberate recertification.

How It Works in Practice

The cleanest operating model is to separate event initiation from access approval. HR or a people system raises the mover event, but the receiving manager and the application or system owner must validate what access is needed in the new role. Central IAM or IT then provisions, adjusts, or removes access based on that decision. In other words, the workflow can be automated, but accountability cannot be automated away.

For human identities, this means access reviews should be tied to role change triggers and time-bound confirmations. For non-human identities, the same principle applies even more strongly because service accounts, API keys, and delegated tokens often outlive the team that created them. The OWASP Non-Human Identity Top 10 makes the same core point: ownership, lifecycle, and entitlement decisions must be explicit, or standing access becomes invisible debt. The 52 NHI Breaches Analysis is useful here because it shows how unmanaged identity sprawl and stale access patterns repeatedly turn into compromise paths.

• HR should trigger the mover event and record the effective date.
• The receiving manager should confirm the minimum access required for the new team.
• The application owner should approve exceptions and remove obsolete access.
• IAM should enforce removal of old entitlements before or at cutover.
• Access recertification should follow the transfer, not wait for the next annual review.

Good practice is to define one accountable owner per application or entitlement set, with a named approver for mover cases and an auditable SLA for completion. The OWASP NHI guidance and the Ultimate Guide to NHIs — Key Challenges and Risks both reinforce that unclear ownership is a recurring control failure. These controls tend to break down in federated organisations with matrix reporting lines because no single manager feels responsible for approving access removal.

Common Variations and Edge Cases

Tighter mover controls often increase operational overhead, requiring organisations to balance speed of transfer against the risk of residual access. That tradeoff becomes sharper in matrix organisations, shared-services models, and fast-moving engineering teams where job scope changes before the paperwork does.

There is no universal standard for this yet, but current guidance suggests the accountable party should be the one best positioned to judge business need at the time of access change. In practice, that is usually the receiving manager for standard entitlements and the application owner for privileged, sensitive, or exception-based access. For shared accounts, bot credentials, or delegated automation, the accountable owner should be the system owner rather than the employee’s former manager. If the organisation uses a central IAM team, it should be treated as the control operator, not the business owner.

The main edge case is temporary dual access during a handover period. That can be valid, but it should be explicitly time-boxed and reviewed. Another common failure mode is assuming HR approval equals access approval. It does not. HR can validate employment status; only the business side can validate operational need. The same principle is captured in NHI governance guidance from NHI Mgmt Group and in the OWASP Non-Human Identity Top 10, which both emphasize explicit ownership and lifecycle control over standing access.

Related resources from NHI Mgmt Group

• Who is accountable when a former employee still has access after offboarding?
• Who is accountable when offboarding leaves access behind?
• Who is accountable when access workflows sit in ITSM but enforcement sits elsewhere?
• Who is accountable when automated deprovisioning does not happen after access review?