Access Management and the Joiner-Mover-Leaver Process

In an office, someone leaving is visible — the desk empties, the badge comes back. Remotely nothing is visible, and accounts survive departures by months or years.

This is the most common serious security gap in distributed organisations and the least interesting to fix, which is why it persists.

The three events

Joiner. Accounts and access created before the start date, tested, matched to the role.

Mover. Someone changes role. New access granted, and — the part that is always skipped — old access removed.

Leaver. All access revoked, devices returned, data recovered.

Most organisations do joiners adequately, movers not at all, and leavers late.

The mover problem

Someone joins in support, moves to operations, then to engineering. Each move grants new access. None removes the old.

After four years they can read everything, and nobody intended it. Multiply by a whole organisation and access bears no relationship to what anyone actually needs.

The fix is procedural. A role change triggers a review of existing access, not just a grant of new access. The question is not "what do they need now" but "what do they still need".

The leaver problem, remotely

Departures are handled by a checklist that runs on the last working day, or later. Common gaps:

Personal devices with company data. Email on a phone, documents downloaded to a home laptop, credentials in a personal password manager.

Third-party services provisioned by a team outside the central process. Every organisation has some, nobody has a complete list, and they are the accounts that survive longest.

Shared credentials. Anything the departing person knew that was not individual to them needs rotating, and usually is not.

Company equipment, which now has to be shipped back rather than handed over. Have a process and a prepaid label, or accept that some of it will not return.

Personal accounts used for work. A domain registrar registered to someone's personal email is a genuine and recurring problem.

What to put in place

A joiners-movers-leavers procedure with a named owner. Not HR and IT each assuming the other does it.

A single source of truth for who works here, from which access derives. Where access is granted by request rather than derived from employment status, it does not get removed.

Role-based access rather than per-person grants. It makes both provisioning and removal tractable.

A list of every service in use, including the ones bought on a team credit card. Build it once, maintain it, and require new services to be registered.

Periodic access review. Quarterly for sensitive systems, annually for everything. Ask each owner to confirm the list of people with access, and remove anyone unconfirmed.

Same-day revocation on departure, with a defined trigger. This is not distrust; it is the standard.

The uncomfortable case

Involuntary departures need a different sequence: access revoked at the point the conversation happens, not afterwards.

This has to be planned in advance with whoever holds the access, and it is awkward to discuss before it is needed. It is considerably more awkward to handle when someone has been told they are leaving and still has administrative rights.

Devices

Know what you own. An asset register with serial numbers and holders. Without one you will not know what is outstanding.

Remote wipe capability, tested rather than assumed.

A returns process that exists before the first departure — prepaid packaging, an address, a deadline, and a decision about what happens if it does not come back.