Joiner, mover, leaver: why movers keep old access

Six months ago, an analyst moved from finance to sales operations. HR updated her department and manager the same day. IT added her to the CRM and the sales tools. Nobody removed anything, so she can still post journals in the ERP, approve supplier payments and open the payroll reports. Nobody asked for that access to be removed, so it never was.

Role changes are stage seven of the employee lifecycle. Identity teams call the whole cycle joiner, mover, leaver. The joiner and leaver parts usually have a process. The mover part usually doesn’t.

What is joiner, mover, leaver?

Joiner, mover, leaver (JML) is the identity and access lifecycle of an employee: access granted when someone joins, changed when they move role, team or location, and removed when they leave. Each event starts in the HRIS and has to reach the identity provider and every application.

Why movers keep their old access

1. A move is treated as an addition. The new manager requests what the new role needs. Nobody files a request to lose access.
2. The HRIS change doesn’t reach identity. HR updates the department and manager, and nothing tells the identity provider or the apps.
3. Old access is removed on the day of the move, or never. Removing it on day one breaks the handover. Leaving it “for a while” means forever.
4. Requested access and role access are mixed up. Access granted for a project looks the same as access that comes with the role, so nobody knows which to remove.
5. Access reviews come once a year. By then, nobody remembers why the access was granted.

What it costs

Access piles up with every move. Someone with five years and three roles at the company holds the access of all three. That is a security risk, and a separation-of-duties problem when finance access and sales access sit with the same person.

It also costs audit time. Every access review turns into a list of exceptions that each need someone to explain them.

What to fix first

1. Trigger on the HRIS change. A new department, manager, title or location starts the move process automatically.
2. Compare the old role with the new one. Keep what both roles need, add what’s new, and list what should go.
3. Give old access a fixed handover window. Remove it on a set date, two weeks after the move for example, instead of when someone remembers.
4. Keep requested access separate. Review access granted by request on its own, and give every request an expiry date.
5. Report access that doesn’t match the role. Send it to the person’s manager and the system owner every month.

The guide to building a role change access update has the prompts for each step.

Where it fits

A move is the middle of the lifecycle, between access before day one and offboarding. The same role profiles drive all three, and the same weekly comparison between the HRIS and each system catches what any of them missed.

For all eight stages, see the hire-to-retire process.