*Updated 4 November 2026 by Simon Mestdagh, founder of Caspian.*

**Key takeaways**

- JML gives, changes and removes access when a person joins, moves or leaves.
- Each event touches three layers: laptop apps, SaaS accounts, resources inside each app.
- The template gives each step an owner, a timing and an evidence column.
- Movers keep old access unless each move also removes what the old role needed.
- SCIM automates accounts only in apps that support it on your plan.

Joiner, mover, leaver (JML) is the process that gives, changes and removes a person's access when they join, change role, or leave. This template gives the full process as a table with an owner, a timing and an evidence column per step, plus a policy you can copy with the blanks in brackets.

Caspian publishes this template and sells a product in this space: Caspian, the IT automation platform for scale-ups. Facts were checked on 4 November 2026.

| Stage | Layer | Task | Trigger | Owner | Timing | Evidence |
| --- | --- | --- | --- | --- | --- | --- |
| Joiner | Laptop | Assign and enrol the laptop, install the role's apps | New hire in HR system | IT | Before day one | Device shows owner; app list matches role |
| Joiner | Account | Create the identity account and each app account | Start date set | IT or app owner | Before day one | User list per app |
| Joiner | Resources | Add to the team's channels, groups, drives and repos | Accounts created | Manager | Day one | Membership lists |
| Mover | Laptop | Install the new role's apps, remove the old role's | Move date in HR system | IT | Move date | Device app list |
| Mover | Account | Create new accounts, remove old accounts and admin roles | Move date | IT or app owner | Move date | Old roles gone, new present |
| Mover | Resources | Leave the old team's resources, join the new team's | Move date | Old and new manager | Move date | Membership lists |
| Leaver | Resources | Name the new owner of files, repos and channels, then transfer | Last day set | Manager | Before last day | New owner shown in app |
| Leaver | Account | Suspend the identity account, deactivate each app, revoke tokens | Last working day | IT | End of last day | User list per app |
| Leaver | Laptop | Collect, lock or wipe the laptop | Last working day | IT | Last day | MDM status |
| Leaver | All | Delete accounts, free seats, store the record | Retention ends | IT | Last day plus [retention] | Seat count, record |

## What is joiner mover leaver (JML)?

JML is the practical core of identity lifecycle management. It covers three events. A joiner is a new employee, contractor or intern who needs a laptop and access on day one. A mover is a person who changes role, team, manager or location, and whose access must change with them. A leaver is a person whose contract ends, and whose access must be removed and handed over.

Each event touches three layers: the apps on the laptop, the account in each SaaS app, and the resources inside each app, such as Slack channels, Google groups, shared drives and GitHub repos. A process that only covers accounts misses the first and third layer.

The HR system should start every change. HR owns the dates. IT owns the access changes. Managers and app owners confirm what each role needs. When requests arrive in chat instead, dates drift and nobody can show what happened when.

## What does a joiner mover leaver process template look like?

It is the table at the top of this page: one row per step for joiners, movers and leavers. Each row names the layer (laptop, account or resources inside the app), the trigger, the owner, the timing and the evidence. Copy it and replace the owners with your own names.

To build the checklist for your own apps, with each app's removal steps from vendor docs, use the free [joiner, mover, leaver checklist generator](/resources/tools/jml-generator). For the leaver steps in detail, use the [IT offboarding checklist template](/resources/it-offboarding-checklist-template). In Dutch: [toegangsbeheer bij in-, door- en uitstroom](/nl/resources/toegangsbeheer).

## What goes in a joiner mover leaver policy template?

A JML policy says who starts each change, how fast it must happen, who approves it, and what record is kept. Replace the brackets. This is a starting point, not legal advice.

| Section | Policy text |
| --- | --- |
| Scope | This policy covers all employees, contractors and interns of [Company], and every company laptop, SaaS app and shared resource. |
| Source of truth | [HR system] holds start dates, role, team, manager and last working day. IT acts on changes recorded there. |
| Joiners | HR records a new hire at least [5] working days before the start date. IT gives the laptop and the role's standard access before day one. |
| Movers | On the move date, IT adds access for the new role and removes access the new role does not need. The old manager confirms removals. |
| Leavers | IT removes app access by the end of the last working day. For a dismissal, IT removes access when the person is told. |
| Contractors | HR records an end date at the start. Access ends on that date unless [role] extends it in writing. |
| Handover | The manager names who takes over files, channels and repositories before the last day. |
| Approvals | A named person approves every access removal. Admin access needs the app owner's approval. |
| Reviews | App owners review access to their app every [quarter]. IT reviews admin accounts every [quarter]. |
| Records | IT keeps the date, the approver and evidence per app for each change, for [3] years. |

NIST SP 800-53 control PS-4 sets a similar bar for leavers: disable access within a defined time, revoke credentials, retrieve company property ([NIST via csf.tools, checked 4 November 2026](https://csf.tools/reference/nist-sp-800-53/r5/ps/ps-4/)).

## What does IT close in each identity lifecycle event?

Most templates cover the standard case. Four cases break it.

**Movers keep old access.** Most mover processes only add. Over a few moves, a person collects access from three teams; this is called privilege creep. Treat every move as two changes on the same date: the old manager removes what the old role needed, the new manager adds what the new role needs.

**Movers who need overlap.** A mover who hands over work may need the old access for a week. Give that access an end date when it is granted, so it expires on its own. A removal scheduled "after the handover" tends not to happen.

**Contractors and interns.** Record the end date when they start. The leaver steps then run on that date without anyone asking.

**Dismissals.** Remove access at the moment the person is told. Start with admin roles, shared logins and API tokens, then suspend the identity account.

The Evidence column is what an ISO 27001 or SOC 2 auditor asks for. A ticket marked done proves a change was sent. A user list from the app proves it happened.

## How can small IT teams automate JML?

JML automation means the HR system starts each change and software carries it out in each app. SCIM lets an identity provider create and deactivate accounts in apps that support it, but vendors often sell it on top plans only. Slack offers SCIM on Business+ and Enterprise Grid ([Slack help, checked 4 November 2026](https://slack.com/help/articles/212572638)). Notion offers it on Enterprise only ([Notion help, checked 4 November 2026](https://www.notion.com/help/provision-users-and-groups-with-scim)). SCIM stops at the account: it does not install apps on the laptop or move channel memberships.

The manual step a small IT team repeats for every event is filling the Evidence column: opening each app and checking. Caspian starts each joiner, mover and leaver change from the HR system, makes it in each app by API, SCIM or an auditable browser script, and reads the app back. A person approves every removal. Caspian is not an identity provider, so sign-in stays with Google Workspace, Entra or Okta. It costs €10 per active user per month, excluding VAT. [Start for free](/start).

## What does Caspian read, and with which rights?

Caspian reads metadata and settings, not content. It reads which apps exist, who has an account, which role that account has, and the state of each laptop. It does not read file contents, email bodies or chat messages. Connections are read-only by default; Caspian asks for write rights only for the steps you switch on, such as removing a leaver's account. Customer data is stored with AWS in the EU (Frankfurt). An independent pen test is planned, and ISO 27001 and SOC 2 are in progress.

*Simon Mestdagh, founder of Caspian, wrote this page. We make Caspian, one of the tools discussed here.*

## FAQ

### What is a JML policy?

A short document that says who starts each joiner, mover and leaver change, how fast it must happen, who approves it, and what record IT keeps.

### What is the difference between JML and identity lifecycle management?

Identity lifecycle management covers an identity from creation to deletion, including reviews and audits. JML is the three events that drive it.

### Why are movers the hardest part of JML?

Most processes add the new role's access and never remove the old. Each move should remove the old team's access on the move date.

### How fast should a leaver's access be removed?

By the end of the last working day. For a dismissal, when the person is told.

### Does SCIM automate JML?

Partly. SCIM creates and deactivates accounts in apps that support it on your plan. It does not cover apps without SCIM, the laptop, or the resources inside each app.