What are the key mover process best practices?

A mover process should remove old access before or at the time new access is granted, so role changes do not accumulate excess privilege. Teams should recalculate entitlements from the new position or function, review privileged and third-party access, and confirm that shared mailboxes, groups, and application roles match the new duties.

What makes mover processing different from simple provisioning?

A mover event is not a fresh start. The core best practice is to treat it as a privilege transition, not just a title change, so the old access set is removed before or at the moment the new access is granted. That prevents access creep, keeps entitlements aligned to the person’s current function, and reduces the chance that legacy privileges survive indefinitely.

Good mover handling starts from the new role, then rebuilds access from that baseline instead of layering the new role on top of the old one. That is why teams should recalculate entitlements from the destination position or function, rather than manually preserving whatever happened to work before.

This is especially important for access paths that are easy to overlook, such as shared mailboxes, groups, delegated administration, application roles, and third-party access. A mover process should verify each of those separately because they often sit outside the obvious HR or directory workflow and can survive role changes if nobody checks them deliberately.

Which access rights should be reviewed first?

The highest-value review is the access that carries the most consequence if it remains active after the move. Privileged access should be checked first, followed by external and third-party access, then application roles and group memberships that may still grant the previous job function. The practical goal is to remove standing access that no longer matches the new duties, especially where the old role had broader authority than the new one.

For the same reason, mover processing should include both direct assignments and inherited entitlements. A user may look clean at the account level while still retaining access through a group, mailbox delegation, app role, or shared credential path. If you only review the obvious account record, you will miss the privileges that most often cause drift.

The strongest mover processes also distinguish between what must be removed immediately and what can be re-approved under the new role. That prevents organizations from re-granting old access by habit, or keeping it temporarily without a clear expiry and owner.

How should mover handling be operationalised?

Best practice is to anchor mover workflows to an authoritative source of job change, then make access recalculation deterministic. That means the new role or function should drive the target access profile, and any exceptions should be visible, approved, and time-bound. Manual cleanup alone is usually too slow and too inconsistent to keep pace with role changes.

• Compare current access with the destination role and remove anything not justified by the new function.
• Review privileged roles, shared resources, and external access separately from standard business access.
• Confirm that the new role does not inherit obsolete groups, mailbox access, or app permissions from the previous role.
• Record exceptions with an owner and an expiry so temporary overlap does not become permanent drift.

For organizations with high role churn, the more important control is not the review itself but the speed of removal. The longer old access remains in place after a move, the more likely it is to be used accidentally, retained by inertia, or abused later.

Risk and Threat Considerations

Movers create a concentrated access-risk window because the same person may briefly hold both the old and new privilege set. If old access is not removed promptly, the result can be privilege creep, unauthorized data access, or unintended administrative reach that outlives the business need.

Failure mechanism: Old entitlements remain active across directory groups, application roles, shared mailboxes, or third-party accounts while the new role is added, so the user accumulates access instead of transitioning cleanly.

Impact: The organization increases the blast radius of a compromised or inattentive account, and it may also fail audits because the effective access no longer matches the approved job function.

Practitioner Guidance

What to verify: Confirm that the mover workflow is removing access from the old role set, not only granting the new one. The check that matters is whether effective access after the move matches the destination function, including indirect access through groups and delegated permissions.

Common mistake: Teams often approve the new role quickly and defer cleanup of the old role, assuming the overlap is temporary. In practice, that overlap is where excess privilege persists, especially when shared mailboxes, third-party access, or application roles are managed outside the main workflow.

Practitioner takeaway: A strong mover process is judged by how completely and quickly it resets access to the new role baseline, not by how smoothly it adds new permissions.

Related resources from NHI Mgmt Group

• Guide: Joiner-Mover-Leaver (JML) Guide
• What are the key Process Explorer best practices?
• What are the key Process Monitor best practices?
• What are the key Process Hazard Analysis (PHA) best practices?
• What are the key G7 Hiroshima Process best practices?