Access rarely becomes dangerous because one person deliberately grants far too much. It becomes dangerous through ordinary work. A new employee needs to be productive quickly, so a broad group is copied from a colleague. Six months later the employee changes roles and receives more access without losing the old access. A contractor finishes, but the application owner assumes IT closed the account while IT assumes the project manager did. Each decision is understandable. Together they create an estate nobody can explain.

Joiners, movers, and leavers is the useful shorthand for managing those changes. The phrase sounds administrative, but the process protects email, files, payroll, cloud platforms, physical devices, client data, and the authority to approve transactions. It also affects the first and last impression a person has of the company. Done well, a starter can work without chasing ten people, and a departure is handled respectfully without leaving access behind.

The process needs one accountable owner

Human resources or the hiring manager usually knows that a change will happen. IT can execute technical steps. Application owners know which permissions are appropriate. Facilities may control badges and keys. Finance may control cards and purchasing systems. None of those groups can complete the process alone.

Define one process owner who makes sure the event moves from trigger to verified completion. That owner does not need to perform every task. They need authority to chase missing decisions, resolve conflicts, and report exceptions. For each system or access type, record who requests, who approves, who implements, and who verifies. If two groups both believe the other one disables an account, the process has no owner.

Use one authoritative source for a person's identity and status wherever practical. An HR system often fills that role for employees, while a vendor or contractor register may be needed for non-employees. The source should contain a stable identifier, manager, start and end dates, employment or engagement type, role, location, and the approvals needed to create access. Names and email addresses change; the stable identifier prevents an old and new record from being treated as different people.

Design the joiner process from roles, not copies

Copying another employee is quick and quietly reproduces every historical exception that person has accumulated. Instead, define access packages for common job functions. A package can include an identity account, baseline productivity tools, security groups, approved applications, device profile, shared resources, and physical access. Keep the baseline small, then add role-specific access through explicit approval.

A joiner request should answer practical questions before provisioning begins

  • Who is the hiring manager and who approves non-standard access?
  • What role, department, location, and worker type apply?
  • What is the confirmed start time and expected end date, if temporary?
  • Which standard role package applies?
  • Which additions are required, and what business reason supports each one?
  • What device, phone, badge, license, or specialist equipment is needed?
  • Does the role handle regulated, confidential, financial, or client-controlled information?

Provision accounts before the start date, but do not make them usable earlier than necessary. Apply MFA enrollment through a verified process. Deliver initial credentials or activation instructions over a channel that does not expose both the username and secret together. Confirm the device is managed, encrypted, patched, and assigned to the correct person in the asset register.

The manager should verify on the first day that the person can reach what the role requires and cannot reach obviously unrelated sensitive areas. This is a quality check, not a request to click every folder. The completed record should show the package, approved deviations, equipment issued, factor enrollment, policy acknowledgements where required, and the person who verified completion.

Movers are the most neglected event

A mover may change department, responsibility, location, legal entity, employment status, or manager without leaving the company. Promotions and temporary assignments count. So do return from leave, a transfer from contractor to employee, and a material change in what a person is allowed to approve. Treating these as simple additions produces privilege accumulation.

The safe model is replace, then justify exceptions. Compare the person's current access with the new role package. Add what the new role requires and schedule removal of what belonged to the old one. The old manager and new manager should resolve anything that must remain. A temporary overlap can be legitimate for a handover, but it needs an owner and an expiry date. Permanent access should never be created by forgetting to remove temporary access.

Movers also affect controls outside application membership. Review approval limits, group ownership, mailbox delegation, distribution lists, document shares, standing administrative roles, VPN policy, development environments, data classifications, purchasing authority, and physical access. Update recovery contacts and escalation lists. If the person owned a service account, automation, domain, certificate, or vendor relationship, transfer ownership explicitly rather than assuming their old team will remember.

High-risk combinations deserve a separation-of-duties review. A role change might leave someone able both to create a supplier and approve its payment, or to develop code and approve its production release. The aim is not to create bureaucracy around every move. It is to identify combinations where one account could initiate and complete a sensitive action without independent review.

Leavers require timing and context

There is no single correct disablement time for every departure. A planned retirement after a long handover differs from an involuntary termination. The manager, HR, legal advisers where appropriate, and IT should agree the exact time and any preservation needs. IT should not learn about a high-risk departure after the meeting has already ended. Equally, premature disablement can reveal a confidential decision and harm the employee.

At the agreed time, disable interactive sign-in at the authoritative identity source and revoke active sessions. Removing a license or changing a password alone may not end sessions already established on browsers and mobile devices. Remove enrolled factors, application passwords, personal access tokens, API keys, certificates, and recovery methods that belong to the person. Disable remote access and retrieve or remotely contain managed devices according to the approved process.

Then work outward from the identity provider

  • Remove application assignments, privileged roles, groups, and shared vault access.
  • Transfer ownership of files, mailboxes, calendars, automations, dashboards, code repositories, and cloud resources.
  • Remove mailbox delegates, forwarding rules, shared links, and guest access.
  • Close or transfer vendor portals, social accounts, domains, advertising accounts, and purchasing authority.
  • Recover badges, keys, hardware, authentication tokens, cards, and paper records.
  • Rotate genuinely shared credentials the person could reveal, even if vault access has been removed.
  • Preserve business records under the organization's retention and legal requirements instead of deleting everything reflexively.

An automatic reply and mailbox forwarding should have a named business owner, an approved message, a review date, and an end date. Indefinite forwarding is not offboarding; it is an invisible continuing access arrangement. The same applies to retaining an account in a disabled state. Record why it remains, what data is preserved, who can reach it, and when it will be reviewed or removed.

Contractors, vendors, and guests belong in the same process

Non-employees are often the largest blind spot because no payroll event signals that they have gone. Every external identity should have a sponsor inside the business, a defined purpose, an expiry date, and access no broader than the engagement requires. Systems that support guest identities should use them rather than creating an employee-like account that conceals the relationship.

Require sponsors to renew access before expiry, not merely respond after it has continued. Review inactive guest accounts, but do not use inactivity as the only test; an annual auditor may legitimately sign in once a year while a departed consultant's automated token remains active every day. Inventory integrations and machine credentials alongside human accounts because contract end dates affect both.

Temporary staff can move as well as leave. If a vendor changes the engineer assigned to your account, do not let its shared login make the swap invisible. Named access, strong authentication, and sponsor review provide the accountability a generic vendor credential cannot.

Automation helps only when the source data is sound

Connecting HR events to the identity platform can create accounts, assign groups, and disable sign-in consistently. That is valuable, but automation reproduces bad data at speed. Test how it handles future-dated starts, rescinded offers, name changes, rehires, simultaneous roles, leave, delayed terminations, and contractors who do not exist in HR. Decide which system wins if records conflict.

Automate standard, reversible actions first. Keep human approval for unusual privileged access and ambiguous transfers. Log every action and route failures to a monitored queue; a failed offboarding workflow cannot simply wait for someone to notice a dashboard. Use idempotent steps where possible so a task can be retried without creating duplicate accounts or assignments.

Do not let an automated completion flag substitute for verification. Periodically select a sample of joiners, movers, and leavers and trace the evidence across identity, key applications, devices, and physical access. The test is whether reality matches the event record, not whether the workflow engine produced a green check.

Access reviews should test the process, not replace it

Periodic review catches mistakes, but it is too slow to be the main control for a departure. Review privileged roles and high-impact applications more frequently than low-risk tools. Give reviewers enough context to decide: current role, manager, last use, access granted, original reason, and resource owner. A list of unfamiliar usernames with approve-all buttons is ceremony, not assurance.

Ask resource owners to confirm that users still need access and that the access level remains appropriate. Ask managers to confirm their people, including contractors and people on leave. Reconcile the results with the authoritative identity source and investigate orphaned accounts that have no current person or sponsor. Track overdue decisions and verify that removals actually occurred.

The review should include standing administrators, break-glass accounts, service identities, shared mailboxes, delegated access, API tokens, and external guests. These are precisely the identities omitted when a review begins and ends with the employee directory.

Operational evidence worth keeping

The strongest records are simple and traceable

  • Every active identity maps to a current person, service, or approved external party.
  • Every external identity and service account has a business owner and review date.
  • Joiners receive a defined package plus recorded exceptions rather than a copied colleague.
  • Movers lose old-role access or have a documented, expiring overlap.
  • Leaver records show the effective time, session revocation, device disposition, ownership transfers, and verification.
  • Workflow failures and overdue approvals create owned work, not silent reports.
  • A sample review confirms that application and device state matches the completed ticket.

Useful measures include completion before start, removal at the agreed departure time, aged temporary exceptions, orphaned accounts found, and elapsed time to correct failed tasks. Use the measures to improve the workflow, not to punish teams for reporting gaps. A sudden drop in exceptions may mean the process improved, or it may mean people stopped recording them.

Where programs fail

Common failure modes are predictable: HR sends an email with no required fields; managers request access by naming a colleague; movers only gain permissions; termination tickets are scheduled for the wrong time zone; session tokens stay active; cloud and vendor accounts sit outside central identity; shared credentials are never rotated; equipment return is recorded but not reconciled; and an access review approves everything because the reviewer lacks context.

Another failure is designing the workflow only for ordinary employees. The first urgent contractor, acquisition, intern, or leave case then bypasses it and becomes a permanent exception. Build explicit paths for common variants and a controlled exception path for the rest. The exception should capture an approver, reason, scope, compensating control, and expiry.

A durable standard

The technology involved is rarely exotic. The hard part is moving a business decision across teams without losing timing, context, or accountability. A good joiners, movers, and leavers process treats access as something granted for a current purpose, not property a person accumulates. It gives new people what they need, changes access when work changes, and closes every relevant path when the relationship ends.

The durable standard is clear ownership, respectful handling, evidence that the work finished, and a process that does not depend on one person's memory. When the lifecycle is routine, the access register becomes explainable again, and forgotten doors stop being an accepted cost of growth.