Joiners, movers and leavers

Access management goes wrong at three moments, and they are the same three moments in every organisation. Someone joins and gets access that was never properly specified. Someone changes role and accumulates the new access on top of the old. Someone leaves and something is missed.

Each has a different failure mode and a different fix. Treating them as one process is why they are usually all handled badly.

Joiners: the problem is that nobody specified it

The typical joiner process starts with a request that says "same access as" an existing employee. This is understandable. It is fast, and the requester genuinely does not know what the role needs.

It is also how permissions propagate. The person being copied has accumulated access over years, including things they no longer need and things they should never have had. Copying them inherits all of it, and the next joiner copies the copy.

The fix is role-based access defined in advance. For each role, a defined set of systems and permission levels, agreed with the people who own those systems.

This is more work up front and it resolves several problems at once. Onboarding becomes faster because nobody is deciding case by case. Access is consistent, so reviews are meaningful. And exceptions become visible: anything requested beyond the role's standard set is an explicit decision rather than a quiet addition.

Start with the roles that hire most frequently rather than trying to define every role in the organisation. Fifteen roles usually cover the large majority of hiring.

The other joiner failure is timing. Access granted late means a new employee spends their first days unable to work. Access granted early, before the start date, is a genuine security exposure. Trigger provisioning from the confirmed start date, and time it to be complete on the morning of day one.

Movers: the problem nobody owns

This is the weakest of the three in almost every organisation, for a structural reason: nobody has an interest in removing the old access.

The employee does not want to lose something they might need. The new manager is focused on getting them productive. The old manager has moved on. HR records the change but does not usually trigger an access removal. So access accumulates, and after several moves an employee has permissions spanning multiple roles they no longer perform.

This is how the most over-privileged accounts in an organisation are created: not through malice or error, but through movement.

The fix is to treat a move as a leaver followed by a joiner. Remove the previous role's access, grant the new role's access. Where there is a genuine handover requirement, retain specific access for a defined period with an expiry date attached at the moment it is granted.

That last point is what makes it work. "Keep it for now" without an expiry means keeping it forever.

Make it triggered, not requested. A role change in the HR system should generate the access review automatically. Relying on someone to remember to raise a ticket means it happens sometimes.

Leavers: the problem is coverage, not process

Most organisations have a leaver process and most leaver processes work for the systems they cover. The failures are in the systems the process does not know about.

The core systems are usually fine. Directory account disabled, email suspended, laptop returned.

What gets missed:

• Applications outside the identity provider. Anything with its own local login, particularly departmental tools adopted without central involvement.
• Shared and service accounts whose credentials the person knew. Disabling their personal account does nothing about these.
• Third-party systems: supplier portals, customer platforms, cloud consoles belonging to partners.
• Physical access: building passes, keys, site access lists.
• Mobile and remote access: VPN certificates, device enrolment, MFA tokens registered to them.
• API keys and personal access tokens they created, which continue to function after the account is gone.
• Forwarding and delegation: mail rules, calendar delegation, shared mailbox access.

The fix is a coverage list rather than a better process. Derive it from your application inventory: every system that holds accounts, with a named owner and how access is removed. Then the leaver checklist is generated from a list that is maintained, rather than from someone's memory of what exists.

Time matters most for involuntary departures. Have a process that can execute immediately, in coordination with the conversation, for the cases that require it.

The review that catches what the processes miss

All three processes will have gaps. A periodic access review is what finds them.

What makes reviews effective rather than a formality:

Review by system, with the system's owner. Asking a manager to confirm their team's access across thirty systems produces approval of everything. Asking a system owner to review who has access to their system produces genuine challenge.

Show useful context. When access was granted, when it was last used, and what changed since the last review. Unused access is the easiest to remove and the most likely to be unnecessary.

Start with privileged access. Administrative rights, access to systems holding sensitive data, anything that can grant further access. Reviewing everything quarterly is unsustainable; reviewing what matters is not.

Make removal the default for unused access. Anything not used in a defined period is removed unless someone actively justifies it. Requiring justification to keep, rather than to remove, changes the outcome substantially.

The measure that tells you whether it works

One number: the count of active accounts belonging to people who have left, found by reconciling your identity systems against the HR leaver list.

It should be zero. It rarely is on the first run, and the gap tells you exactly which systems your leaver process does not cover. Run it monthly, and the number both stays low and identifies each new gap as it appears.