How should organisations handle identity lifecycle changes when employees move across roles or business units?

What changes when an employee moves between roles or business units?

An internal move changes what that person should be able to do, not just where they report. Access that was appropriate in the old role can become excessive in the new one, and new responsibilities may require different systems, data, or approval paths. The lifecycle event matters because permissions, ownership, and review cadence all need to follow the person’s current job function.

That is why move management should be treated as part of identity governance, with a clear rule for when access is transferred, revoked, or temporarily retained under documented exception.

How should the review and change decision work?

The practical decision is to compare the new role against the old access profile and remove anything that no longer has a current business need. In some cases, the right answer is to preserve a subset of access for a transition period, but that should be time-bound and justified. The point is to avoid leaving the identity in a half-mapped state where nobody owns the residual entitlements.

Automation helps because it can trigger the review at the moment of change, route decisions to the right approver, and close the gap between the HR event and the access update. A NHI Lifecycle Management Guide can be useful here because the same lifecycle discipline applies when identities, roles, and entitlements change together.

For teams managing both people and system access, the same lifecycle problem shows up in related identity patterns, and NHIMG’s Ultimate Guide to NHIs, Lifecycle Processes for Managing NHIs is a good reference point for the underlying governance logic. The underlying issue is not the job title change itself, but whether entitlement changes are executed fast enough to prevent stale access.

What does good role-change governance look like in practice?

Good practice is to make role change handling deterministic. The receiving manager, the former manager, and the access owner should all understand who approves the new access set, who removes legacy access, and what gets reviewed after the move. If the organisation cannot answer those ownership questions, the process will drift into manual exceptions and delayed cleanup.

It also helps to distinguish between access that is genuinely needed during transition and access that is merely convenient to keep. Cross-functional moves often expose inherited entitlements that were never revalidated, especially shared tools, reporting views, and privileged workflows. Key Challenges and Risks is relevant because entitlement drift, overprivilege, and visibility gaps are common failure modes whenever lifecycle changes are not tightly governed.

When organisations want a broader control baseline, the ISO/IEC 27002:2022 Information Security Controls guidance is a useful external reference for access review and privilege management, while the NIST SP 800-53 Rev 5 Security and Privacy Controls catalog provides a control-led way to express the same governance expectation.

Risk and Threat Considerations

Role changes create a short but important exposure window where old access may still work after the employee has moved. That window is where orphaned privileges, privilege creep, and misuse of inherited entitlements are most likely to appear, especially if changes are handled as administrative paperwork rather than enforced lifecycle control.

Failure mechanism: The identity keeps access from the prior role because revocation, transfer, and recertification are not tied tightly to the move event, leaving stale permissions active longer than intended.

Impact: The organisation can end up with excessive access, inappropriate data exposure, and a larger blast radius if the account is misused, compromised, or simply used for unintended cross-unit activity.

Practitioner Guidance

What to verify: Confirm that role-change events trigger an access decision, not just an HR record update. The test is whether the former permissions are explicitly re-justified or removed against the new job function.

Decision rule: If access is not clearly required in the new role, remove it immediately; if it is temporarily needed, set a time limit and a named owner for the exception.

What to measure: Track the time between role change and access revalidation, plus the number of identities carrying stale entitlements after the move. Those two signals tell you whether the lifecycle control is actually working.

Practitioner takeaway: The safest move process is the one that treats every transfer as a forced entitlement review, because delay, ambiguity, and informal retention are what turn a routine organisational change into access drift.

Related resources from NHI Mgmt Group

• How should organisations govern identity lifecycle changes across users and non-human accounts?
• What breaks when organisations manage identity separately across multiple business units and platforms?
• How should organisations improve identity visibility when IAM environments are fragmented across business units and cloud systems?
• How should organisations handle multi-affiliation access when employees move between roles or contracts?