Joiner, mover, leaver: the identity lifecycle auditors sample first

Nearly every organisation builds a solid joiner process, a passable leaver process, and no mover process at all. That imbalance is why access reviews keep surfacing people who hold entitlements from two roles ago - and why the mover case produces more findings than the other two combined.

Joiner

The part that usually works, because someone complains loudly when it does not. What auditors check:

• Access is requested and approved before it is granted - by the line manager, and by the system owner for anything sensitive.
• Role-based defaults rather than "copy Sarah's access". Cloning an existing user is the fastest way to propagate privilege creep into every new hire, and it is a common finding on its own.
• Least privilege at the start. Adding access on request is cheap; removing it later never happens.
• The request record survives. The ticket is the evidence, months later.

Mover - the one that fails

Someone changes team, gets promoted, covers a colleague's parental leave, or joins a project. New access is granted immediately because they need it to work. Old access is removed... by nobody, because no event triggers it and nobody is inconvenienced by its continued existence.

Over a few years this produces the finance analyst who still has engineering repository access, and the support lead who accumulated administrative rights in four systems while covering absences. Each individually explicable; collectively a segregation-of-duties problem nobody designed.

The fix is unpopular but simple: treat an internal move as a leaver from the old role and a joiner to the new one. Revoke the old set, provision the new set. Not "add the new access and review later" - later does not arrive.

Where a clean revoke is impractical during handover, grant a dated overlap with an explicit end date, and make expiry the default rather than an action someone must remember to take.

Leaver

The highest-risk event, and the one with the tightest expectations:

• A defined timeline - same day for standard departures, immediate and pre-emptive for involuntary ones. State it in policy and meet it, because your own stated timeline is what you are measured against.
• Disable before delete. Deleting an account can destroy evidence, break ownership of files and calendars, and complicate an investigation. Disable, transfer ownership, then delete per retention policy.
• Cover everything, not just the identity provider. The gaps are consistently: systems outside SSO, shared credentials the person knew, VPN certificates, API keys and personal access tokens they created, SaaS tools bought on a card, physical access badges, and MFA devices.
• Credentials they knew. Shared accounts must be rotated on departure, which is a strong practical argument against having any.
• HR is the trigger. If IT hears about departures informally, the control depends on someone remembering.

Non-employees, where it usually breaks

Contractors, consultants, auditors, temporary staff and service accounts frequently sit outside the HR system entirely - so no joiner, mover or leaver event ever fires for them. Two mitigations:

• Set an expiry date at creation for every non-employee account, tied to the contract end. Renewal is a deliberate act.
• Give every service account a named human owner who is accountable for its continued existence, and review the list when that owner leaves.

Orphaned service accounts - created for a project, owned by someone who has left, holding standing privileges - are among the most exploited footholds in real incidents and among the easiest findings for an auditor to produce.

What auditors sample

1. A sample of joiners: was access approved before it was granted, and does it match the role?
2. A sample of leavers: reconcile the HR termination list against account status, and measure the time from departure to disablement.
3. Movers, increasingly: did old access get removed when the role changed?
4. A full account list against the current employee list - anything present in one and absent from the other needs an explanation.

That reconciliation is the test worth running on yourself quarterly. It takes an hour and finds what a policy review never will.

Key takeaways

• Movers are the weak link - treat a role change as a leave-and-join, not an addition.
• Never clone an existing user's access to provision a new one.
• Disable before delete, and cover the systems outside SSO.
• Give every non-employee and service account an expiry date and a named owner.