Joiner, mover, leaver: the offboarding checklist

Joiner, mover, leaver (often shortened to JML) describes the three moments in a person's time at your organisation when their access must change. Joiners need access quickly so they can work. Movers need some access added and, importantly, some removed.

Leavers need everything ended, completely and promptly.

Most audit findings and most incidents involving former staff come from the last two. Joiners complain loudly when it goes wrong, so they get fixed. Movers and leavers fail silently.

Start with a source of truth

Every JML process needs one authoritative record of who works here, what their role, department, manager and dates are. Usually that is the HR system. If that record is late or wrong, every downstream step is wrong too.

Agree these facts in writing:

• Which system is authoritative for employment status and dates.
• How soon after a decision (resignation, termination, transfer) the record is updated.
• Who can backdate a change, and who reviews backdating.

A rule of thumb we find useful: the HR record should change before the access change is needed, not after. A last working day that is entered on the last working day leaves no time to act.

Joiner checklist

Before day one:

1. Create the identity from the HR record, not from an email request.
2. Assign access by role: a base bundle for everyone, plus a bundle for the department.
3. Issue authentication methods through a controlled first-login process, such as a time-limited enrolment link, rather than a shared initial password.
4. Pre-stage devices and confirm they are enrolled in whatever endpoint management you use.

On day one:

1. The person registers at least two ways to sign in (see Passkeys explained).
2. Their manager confirms the starting set of access is right and nothing extra is needed.
3. Acceptable-use and data-handling acknowledgements are recorded.

Within the first month:

1. Extra access requests go through an approver who owns the application, and each approval is recorded.

Mover checklist

Movers are where "access creep" builds up. A person who has worked in four teams over six years can end up holding the combined rights of all four.

1. Treat any change of department, manager, location or job family as a trigger.
2. Compute the new role bundle and compare it with the current access.
3. Remove what the old role granted and the new role does not. Do this by a set date, often thirty days after the move, to allow a handover period.
4. Ask the new manager to confirm any access that was granted individually rather than by role.
5. Re-check privileged access separately. Admin rights rarely transfer with a role change.
6. Record the date and the approver of every retained exception.

Moves that are really temporary (acting roles, project secondments) need an end date at the time of granting, not an intention to clean up later.

Leaver checklist

Do the sequencing deliberately. Some steps are urgent and some can wait.

At the moment of departure (or earlier if the situation requires):

1. Disable the person in the central identity provider. This blocks every sign-in that goes through single sign-on.
2. End all active sessions and revoke refresh tokens, so a laptop that is still open does not stay signed in.
3. Remove or reset authentication methods: passkeys, authenticator-app registrations and any recovery contact details.
4. Disable the email account, or convert it to a forwarded or shared mailbox according to your policy.

Within the first day:

1. Revoke access in applications that do not use single sign-on or do not follow your identity provider's status. Check for local passwords, personal access tokens and API keys the person created.
2. Recover devices and revoke any certificates, VPN profiles and remote-access credentials.
3. Reassign ownership of shared documents, scheduled jobs, automation and repositories, so that nothing breaks or sits orphaned.
4. Remove the person from distribution lists, chat groups and meeting series.
5. Update on-call rosters and escalation paths.

Within the first week:

1. Transfer or archive data following your retention policy. See What the DPDP Act means for employee data for retention thinking.
2. Review the leaver's last thirty days of activity for unusual downloads or forwarding rules, particularly if they left on poor terms.
3. Confirm in writing that every step is done, with the name of the person confirming.

The gaps that trip people up

• Disabled in the directory, still alive in the app. Single sign-on stops new logins, but an existing session, a local password or a long-lived token can still work. Automatic de-provisioning to applications closes this. SCIM 2.0 in plain English explains how, and why setting active to false matters.
• Service accounts and API keys created by the leaver. If a person owned a key, find it. See Service accounts and API keys.
• Contractors and interns who never appear in the HR system. Give them an owner and an end date in the identity system.
• Shared mailbox and shared passwords. If a shared credential was known to the leaver, rotate it.
• Personal devices with company data or signed-in apps.
• Rehires. Decide whether to re-enable the old identity or create a new one; reusing identifiers by accident can bring back old permissions.

Measure it

Pick three numbers and track them monthly:

• Time from the leaver's last working moment to all central access being disabled.
• Number of accounts still active in applications for people who have left.
• Number of people holding access that does not match their role.

If you cannot compute these today, that is your first finding.

Automating the flow

You can run all of this manually with a spreadsheet and discipline, and many small teams do. The failure mode is volume and timing: a checklist works for five leavers a month and fails at fifty.

AuthMantra can receive employee records from an HR system over inbound SCIM 2.0, and push changes out to applications through outbound SCIM provisioning, so that a status change in the HR record flows to the apps it reaches.

It does not include a workflow designer; for ordering and approvals, you would keep your existing ticketing process. The joiner-mover-leaver use case shows the pieces.

What to do this week

• Pull the list of employees who left in the last ninety days and check that none still has an active account in your top five applications.
• Write down the HR field that triggers a leaver, and who is responsible for updating it, and by when.
• Make a list of applications that are not behind single sign-on; these need manual steps.
• Pick one mover from the last year and compare their access with their current role.
• Assign a named owner to the leaver checklist, and a backup.