Joiner–Mover–Leaver for Access Management: Automating Employee Permissions

What's the problem with access during hiring, transfers and terminations

In many companies access rights are still granted manually. HR sends an email to IT, a manager adds the person to chats, and an admin “from memory” ticks boxes across different systems. Some requests get lost in conversations, while others are done “just in case” so a new hire can definitely start working on day one.

Then it gets worse. When someone transfers, their tasks change, but old rights often remain because nobody remembers where and when they were granted. During termination access might be disabled in one system, but email, files, CRM, VPN, remote access, shared folders or cloud accounts get forgotten. That creates direct risks of data leaks, errors and audit issues.

You usually notice the problem through simple symptoms: shared department accounts appear, people accumulate extra roles “because it was needed once,” and contractors keep access for months after their work ends. And one day nobody can quickly answer: “Who has access to this system and why?”.

A clear Joiner–Mover–Leaver (JML) process changes this. It speeds up onboarding, makes transfers predictable and reduces risks at termination. The key is that decisions stop depending on email chains and human memory.

Joiner, Mover, Leaver in plain language

JML are three employee lifecycle events that should change permissions in systems: someone joined, changed role, or left. If these events are described differently (or not at all), access rights start living their own life: needed rights are delayed, unnecessary ones remain for years, and accountability blurs.

Joiner (new hire) — the moment to grant the minimum required for the person to start on day one: corporate email, workstation sign-in, access to basic services and relevant work chats. Everything else is better added as needed after the role and tasks are confirmed.

Mover (transfer) — not just “add another access,” but review the old ones. Changing department, project or position means some previous rights are no longer needed and new ones must appear quickly. A common mistake is to “hoard” accesses after each role change until the employee has rights to “almost everything.”

Leaver (termination) — the most sensitive stage. It helps to split actions into three layers:

• Immediately: close sign-in (account, email, VPN, remote access, tokens and keys).
• Within hours: block access to critical systems (finance, HR, CRM, source code).
• After handover: reassign owners of shared mailboxes, files, tasks and external service accounts.

If HR, IT and security speak the same language (what counts as an event, who initiates, who approves, what exactly changes), the process becomes repeatable and easier to automate.

What data and systems participate in the JML process

To make JML work without manual touch-ups, define in advance where events come from and where changes should be applied. The clearer the “data -> decision -> action” chain, the fewer mistakes and disputes.

Event source is usually HR: the HR system or a personnel order (hire, transfer, termination). What matters is not an “email,” but a formal signal with the change type, date and clear employee identification.

Employee directory (single record) must contain a stable identifier and current attributes: status, division, position, manager, location, employment type. Without a single ID it’s easy to end up with duplicate accounts or revoke rights from the wrong Ivanov.

Target systems that hold actual access typically include corporate email and calendar, VPN and remote access, file shares, business systems (ERP/CRM, accounting, EDMS), and the service desk.

Logs and audit are mandatory even with full automation. It must always be possible to see who initiated, who approved and when changes were applied. At minimum record: the event and source, what rights were granted/removed and by which rule, who approved, who executed (system/admin), and any manual exceptions with reasons.

If infrastructure is on-premises, the set of systems may be wider, but the principle is the same: one reliable data source, one directory and transparent audit at every step.

Roles and responsibilities: who is in charge of what

JML usually breaks down not because of technology, but because of unclear roles. When it’s unclear who records the event, who selects accesses and who monitors risks, unnecessary rights, delays and disputed exceptions appear.

HR: event source and accurate data

HR starts the process (hire, transfer, termination) and provides the minimum attributes without which automation will “guess.” Usually this is position and division, start/transfer/termination date, employment type (employee/contractor) and location when it affects access.

Manager: confirms role by tasks

The manager is responsible for ensuring access matches actual work. They don’t need to list systems manually; their job is to select the role (profile) and approve exceptions when truly needed.

IT and security set rules and boundaries: which roles map to which groups, which rights are risky, which require special approval and time limits (e.g., admin rights or access to financial data). They also control exceptions: who requested, who approved, for how long and what happens on the next transfer.

The service desk is useful as a single entry for requests and SLA control. Even with automation it remains the dispatcher: tracking SLA, recording workarounds and closing the process only when access is actually granted or revoked.

Access model: roles, groups and approval rules

For automation you first need a simple access model: what rights are normal for each role and who can approve exceptions. Without that, the process becomes endless one-off requests.

Start with standard roles understandable by HR and IT (purchaser, HR specialist, sales manager, engineer, department head, call-center operator). Assign specific groups (in AD/IAM) and permissions in key systems to each role. It’s important to grant access via groups, not per user, otherwise transfers and terminations leave leftovers.

Divide permissions into four levels: basic (email, chats, Wi‑Fi, shared folders), extended (departmental systems), privileged (admin roles, financial reports, personal data, infrastructure settings) and temporary (project or cover with an expiry date).

Basic access can often be granted automatically by role and division. Extended access typically needs manager approval, and privileged access requires a separate approval from the system owner or security. Exceptions are better issued as temporary access: who requested, who approved, who renews and what happens after expiry.

Step-by-step: how to automate access provisioning for hires

Automating the Joiner stage follows a simple principle: access is granted not by emails and requests, but by an HR event and clear rules.

1) Trigger the process from an HR event

As soon as HR records the hire and the start date, a task for access should be created. The task needs an owner (usually IT or security) and a deadline, for example “by 10:00 on the first working day.”

2) Verify data and assign a role

Before granting rights check key fields: division, position, manager, location and employment type. Use them to select a role template.

3) Basic access automatically, exceptions via approval

Automation should cover most needs: account, email, standard groups and basic corporate systems. Anything non-standard (financial access, admin rights, critical servers) should go through a short approval by the manager and security.

A practical minimum at this step: create the account, apply the role and groups, grant standard accesses, send readiness notifications and write the result to the audit log.

4) Notify the employee and manager

Provide the employee a simple guide: what’s already working, how to sign in and where to report problems. Send the manager confirmation that the person is “ready to work.”

5) Confirm access and record audit

Finish with a short check: the employee signed in, access matches the role, exceptions are recorded and visible in the log.

Step-by-step: how to manage access on transfers (Mover)

Transfer is a tricky stage: rights already exist and some of them quietly become unnecessary.

1) Record precisely what changed

You need a clear trigger: change of department, position, project or access level. Ideally the HR event includes the new role, division, manager and effective date.

2) Remove the old, then add the new

Follow the principle of least privilege. A practical scenario: compare current groups and roles with the target profile, remove old-role access (systems, folders, mail groups, chats), grant new-role access and verify they work, recalculate licenses and get confirmation from the new manager.

After changes check the “gray areas”: shared folders, mailing lists, team chats and calendar permissions. Those are where the widest access commonly remains.

3) Respect timing: immediately or on transfer date

If a transfer becomes effective in a week, schedule changes for that date. A common practice is to enable the new role on the effective date and remove old rights at the end of the last working day in the previous team.

4) Keep a history and “who confirmed”

Save the record: what was before, what became after, who approved and when it was applied. This helps with disputes and audits.

Step-by-step: how to safely revoke access on termination (Leaver)

The goal of Leaver is simple: the person must no longer be able to sign in, and the business must not lose emails, documents and access to necessary data.

1) What to disable immediately (on termination day)

First close sign-in, then handle handover. Usually you should immediately: disable the domain/SSO account and local accounts in key systems, disable VPN and remote access, revoke active sessions and tokens in mail and messengers, block admin panels, cloud access, code repositories, data marts and BI, and remove any privileged and temporary rights.

Don’t stop at “disable the user.” If active sessions and tokens are not revoked, access may persist until the session ends.

2) What to close afterwards (after handover)

After initial disabling, coordinate with the manager and data owners what to keep and who to transfer to: ownership of folders and projects, tasks and tickets, archive email and chats according to retention rules, temporary email forwarding or autoresponder for a limited time, and cleanup of contractor services (licenses, subscriptions, external accounts).

3) Devices and physical media

Handle laptop, phone, tokens, smart cards and badges separately. Make asset return part of the same process: accept, check completeness, remove work data, and if needed securely wipe and reinstall.

4) Contractors and temporary staff

For contractors keep a separate rule: access only for the contract term, no permanent exceptions, with automatic expiry. If work is irregular, it can be justified to disable access at the end of each working day.

5) Security checks and reporting

The final step is a checklist across systems: what was disabled, what transferred, what archived and who confirmed. A short report reduces the risk of forgotten access and helps with audits.

Common mistakes and traps that break JML

Major failures usually come from discipline issues rather than a “bad tool”: somewhere rights were given faster than paperwork, somewhere they forgot to remove them, and somewhere an account split into two or three.

A typical problem is granting rights “by request in chat.” It seems faster at first, but later it’s impossible to answer basic questions: who approved, for how long and why.

During transfers inertia often wins: old rights are kept “just in case” and new ones are added. That creates dangerous overlaps (for example, procurement and finance). It’s better each time to compare actual rights with the target profile and remove excess.

Another trap is the lack of a single employee identifier. Different name formats in HR, email and domain lead to duplicate accounts. Then they terminate “Ivanov I.I.” but the active account “ivanov.i” remains with critical access.

Permanent exceptions are dangerous: temporary access without expiry and without an owner to confirm necessity. After six months nobody remembers why it was issued, but it still works.

Finally, absence of a closing check. Formally termination is complete, but in practice no one verified that everything was disabled: account, email, VPN, tokens, business-system rights and cloud access. A minimal useful ritual is a short checklist across key systems and recording the result.

Short readiness checklist for JML automation

Before automation, make sure processes and data are ready. Otherwise automation will only speed up the chaos.

First check the basics: is there a single list of systems with accounts and are owners of access assigned? The owner is not always IT; often it’s a business manager or a system administrator who understands which rights are actually needed.

Next — role templates. For key positions there should be clear sets of rights: what to give on day one, what to add later, what is forbidden by default.

Then check controls and security: deadlines for disabling on termination and responsible parties, recorded approvals and auditability. If decisions are made in messengers or verbally, first define a clear approval path and preserve traces.

To prevent the process from becoming overgrown with excess rights, implement regular access reviews and reports for security. Track employees with rights above the norm for their role, access for long-absent employees, unused permissions and exceptions with named approvers.

Practical example: hiring, transfer and termination of one employee

Anna is hired in a regional branch as a procurement specialist. After three months she transfers to the head office, and six months later she is dismissed.

On her start day (Joiner) the system takes data from HR (name, role, division, location, manager, start date) and automatically issues the basic set: corporate account and workstation login, email and calendar, corporate messenger, basic folders and, if necessary, a license request tied to the role.

Some rights are logical to add later (for example, access to financial registries, contract approvals, extended reports in accounting). This reduces the risk of granting too much if the employee doesn’t stay.

After three months Anna transfers (Mover). The trigger is a change of division and location in HR. The process does two things: removes access tied to the branch and adds access needed at the head office. Access groups, folders and workspaces change, as do profile system rights and licenses. If access to a branch project folder must be kept for two weeks, issue it as a temporary exception with an expiry date.

On the termination day (Leaver) the account is blocked immediately, active sessions end, tokens and critical-system access are revoked in priority. Email and files usually get an owner assigned (the manager), a limited auto-reply is enabled and archives are created according to company rules.

To verify the process works, measure: onboarding time (from HR record to ready access), number of manual exceptions per employee, share of access outside role, percentage of overdue disablements and time to clean up after transfers (old groups, extra licenses).

Next steps: how to launch JML without stopping work

To launch JML without disrupting operations, move in small iterations. At the first stage predictability matters more than perfection: who creates the request, who approves, what and when is issued, and how it’s checked.

Start with a list of systems that have accounts (email, AD, 1C, CRM, file storage, industry services) and identify the 10–20 most common roles. Then define one intake channel for requests (for example, the service desk) and clear statuses, document approval rules, set deadlines (ready by day one and fast disablement on termination), enable minimal automation (account creation, group assignment, removal of standard rights) and run a pilot in one division.

If you need external help, GSE.kz (gse.kz) as a systems integrator can assist with role and rule descriptions, linking HR and IT and organizing support. This is especially useful when there are many accesses and stable 24/7 operation is critical.