Managing Client User Leaver Requests in an MSP | 4KM Tech

Updated 14 August 2026

A staff departure can trigger several technical actions across accounts, devices and services. For an MSP, the challenge is to act at the correct time and on authorised instructions without making assumptions about employment circumstances. A structured leaver request keeps the provider focused on the client's approved technical requirements.

Use the agreed service request route

Ask clients to submit leaver instructions through the provider's approved channel. A traceable ticket helps the MSP coordinate work and avoids important access changes being left in a technician's personal inbox or informal message thread.

Confirm that the requester is authorised

Follow the existing client-authorisation process before changing user access. A message that appears urgent should not bypass established controls. The MSP does not need details about why the person is leaving unless they are genuinely relevant to the technical instruction.

Record the effective timing clearly

Some changes are required immediately, while others must occur at a specified handover point. Record the client's authorised timing precisely enough for the technical team to act correctly and avoid disabling access earlier or later than requested.

Identify the services in scope

A user may have access to several client systems, managed applications or devices. Work from the MSP's current service and account records rather than assuming one account represents the whole user footprint. Client-owned systems outside the provider's remit should remain clearly distinguished.

Separate access removal from data decisions

Disabling a user's ability to sign in is not the same as deciding what happens to business data, mail or files. Follow the client's authorised instructions and the provider's established processes for each action instead of making retention or transfer decisions independently.

Track devices and other assigned assets

If the MSP manages client equipment, update the relevant asset record when responsibility changes. The client's physical collection process may sit outside the MSP's role, so record only the technical or asset-management actions the provider is responsible for.

Verify completion across the requested scope

Before closing the ticket, check that each authorised technical action has reached its intended state. Avoid closing the request after completing the first visible account change when other managed services remain outstanding.

Keep the final record factual

Document what the MSP changed, when it acted and any authorised outstanding action. Avoid including workplace gossip or unnecessary employment information. A concise technical record is more useful for future support and audit than a narrative about the departure.

Turn the client's instruction into a scoped action register

ART1 establishes that leaver work begins with authorised instructions, not workplace assumptions. For every request, capture the verified submitting contact, affected account identity, effective date and time with its time zone, client service scope, and the precise actions requested. Separate immediate access restrictions from later mailbox, data and equipment activities. This avoids treating one disablement as the complete departure process.

Use a controlled checklist with columns for service, approved action, implementer, evidence, result and next owner. A directory account, stand-alone SaaS login, privileged account, VPN entitlement and application-specific access may require different owners. The MSP should only claim the systems it can verify under the client agreement.

Review the timing and dependencies before acting

A scheduled departure may require disabling access at a specific moment while preserving business continuity through an authorised handover. A security-sensitive request may require a separate incident response route. Confirm the business instruction and avoid inventing reasons for departure. If the client instruction is ambiguous, refer the timing or scope question to the authorised decision maker before undertaking consequential changes.

For critical applications, determine whether the departing person owns a scheduled job, integration or shared workflow. Disabling a personal account should not silently break an unattended process; equally, an operational dependency is not a reason to leave unnecessary access open indefinitely. Assign a competent owner to resolve the dependency under appropriate controls.

Distinguish account access from business information

Revocation, licence recovery, data retention, mailbox delegation and file transfer are separate operations. Record the client's approved recipient and any relevant policy requirements before making business information available to someone else. Do not use the general leaver ticket as blanket permission to inspect private communications or move sensitive records.

Where applications offer session revocation or token management, follow the provider's documented and authorised process. Record what was verified in the target system rather than claiming that a main-directory change automatically terminated every independent session.

Coordinate devices and custody

Identify managed laptops, phones, authenticators and other assets associated with the user. Distinguish the MSP's technical responsibilities from the client's physical return arrangements. If a device is recovered, record custody, condition, approved data handling and whether it will be stored, repaired or redeployed. Do not wipe or reassign equipment before applicable retention and business approvals have been checked.

For equipment not yet recovered, keep the exception visible with a client owner and agreed next step. The absence of a return receipt should not be converted into an unsupported accusation or a completed asset action.

Verify each completed control

After applying an authorised change, confirm the resulting account or device state using approved administration evidence. For a failed automation job, identify which target systems succeeded and which require follow-up. A job accepted by a queue is not always proof that the final service applied it. Retain the minimum verification details necessary for accountable support.

Use restricted records for sensitive evidence, with the main ticket pointing to them as necessary. Avoid copying tokens, passwords or extensive personal data into general support notes.

Close the request without hiding residual work

Give the client a concise factual summary of completed actions, effective times and items still awaiting their decision or a supplier response. Keep a named owner and next check for each unresolved item. Do not label the entire leaver workflow complete merely because the first login has been disabled.

Afterwards, inspect repeated leaver requests for missed standalone applications, unclear authority or outdated asset assignments. Improve onboarding and access-review records where those omissions begin. This extends ART1's premise: a good leaver request is an authorised, auditable coordination of access, data and assets within clear client and MSP boundaries.