One exit coordinator should own the employee handover checklist. Assign the access changes and unfinished client work to named people before the technician leaves. The coordinator verifies both; a returned laptop doesn't establish either result.
I'd keep the authorized departure timing with that shared work record. Use knowledge transfer where it is available, but don't delay access changes until a departing person finishes a document. The people decision and the technical execution need their own authorized owners.
Confirm the Instructions Before Assigning Changes
The owner or people manager gives the coordinator the approved departure instructions. Record when access must change and who may authorize a timing change. Limit sensitive employment information to the people who need it.
Build the plan without assuming the departing technician will remain available. In a planned handover, use their authorized work time to check the records. Otherwise, the receiving owners reconstruct what they need from the approved systems and retain any gap as an assigned action.
When Monday morning's board opens, who owns every live task that previously belonged to this technician? Check the receiving person and the next action. An unmonitored queue isn't a replacement owner.
Use One Record With Separate Completion Checks
Keep the workstreams together while storing detailed evidence in its appropriate system. The coordinator checks results with each owner. Give the live record actual names rather than leaving responsibility at a department label.
| Workstream | Owner | Completion Evidence |
|---|---|---|
| Departure instructions | Owner or people manager | Approved timing and communication instructions received |
| Open tickets and projects | Service lead and receiving technicians | Task state, client commitments, and next actions accepted |
| Client contact continuity | Account owner | Appropriate client introductions and support route confirmed |
| Knowledge and configuration history | Technical lead | Required records checked for use and gaps assigned |
| Identity and privileged access | Assigned identity and system owners | Scoped access changes verified on the actual systems |
| Devices and physical access | Asset or facilities owner | Property reconciled and physical-access changes recorded |
| Data and workflow ownership | Authorized data and system owners | Required business information and ongoing processes have approved owners |
| Final reconciliation | Exit coordinator | Evidence checked and unresolved exceptions have explicit treatment |
Permission to see the checklist isn't authority to perform every sensitive change. Link to the controlled credential system without putting secrets into a general task record. The receiving person needs authorized access of their own.
Transfer the Client Commitment With the Task
Have the service lead and receiving technician inspect open work together. Keep its real state and next commitment with the next action. Preserve the existing history instead of making the replacement treat an unresolved issue as a new request.
Check work waiting for a vendor or client too. Change contact and notification details where needed so the next update reaches the receiving owner. Scheduled work still needs an assignment after the person who created it leaves.
The account owner handles the client introduction separately from the technical reassignment. Explain the appropriate contact and how to request support. A personal contact list shouldn't become the only map of the ongoing relationship.
Nick Clift recommends naming accountability for the managed-service relationship and renewal experience. That is his role-design advice. Use the established account responsibility for the conversation while the service lead transfers the technical work.
Check That the Next Person Can Use the Knowledge
Have the technical lead identify the records needed for current work and important environment exceptions. Ask the receiving technician to locate the material and explain the next step. An exported folder is a starting point, not a usability check.
Brenton Johnson proposes curating configuration history with the change, its reason, ticket references, and approvals, then asking knowledgeable people where the explanation is missing. That is his documentation method. Apply it to the important unresolved configuration instead of requesting a polished account of everything a technician ever touched.
Give each unknown an owner and an investigation route. Keep the source and approval history with the eventual explanation. The model aims for a business that doesn't rely on its owner; I'd apply the same continuity test to the work of any key person leaving.
Verify Access on the Actual Systems
The identity owner works with system owners to inventory normal and administrative identities. Include the authorized direct client and vendor routes, not only the MSP email account. An incomplete account list makes an apparently finished checklist misleading.
Follow the current procedure for the identity arrangement in use and check its result. Don't assume a clicked control immediately ends every session. Give an uncertain route or failed removal to the security owner with the evidence needed for a decision.
Have each system owner check separately issued credentials and relevant integrations. Where an approved shared secret must change, plan the dependent service work and verify it. Don't leave a person's access active merely because the team hasn't checked which process depends on it.
A laptop box doesn't revoke a vendor login. The asset and access workstreams need separate results. Keep the failure visible rather than using recovered property as a substitute for checking authorization.
Preserve the Business Work That Still Has an Owner
The authorized data owner decides what information must remain available and who may use it. Work from actual retention and access requirements. Deleting first and investigating afterward isn't a handover plan.
Check ongoing processes for dependencies on the departing identity. Transfer them through the approved change process and verify the replacement's required permissions. Don't maintain continuity by sharing the former employee's password.
Handle equipment return and any permitted personal-device work under the applicable arrangement and approved instructions. Record what was recovered and what remains open. An asset label can't decide how business data should be handled.
Reconcile Evidence Before Closing the Workflow
The coordinator reviews the workstreams with system owners and the service lead. Record what was checked and where its evidence lives. Give each remaining exception a responsible person and an explicit treatment.
Skip knowledge-transition language that hides an untested handoff. Name the missing procedure or unresolved service action instead. The next technician needs an assignment they can perform, not a growth-hack label for lost knowledge.
Close the departure workflow when the checklist explains who now carries the service and how any remaining access issue is being handled. Have the receiving owners accept their work before sign-off. Keep the coordinator's completion decision separate from a claim that every unknown has disappeared.
mspoutpost.com/articles/employee-handover-checklist-for-a-departing-msp-tech
Written by Megan Friesen
MSP Outpost publishes information, not legal, financial, insurance, tax or compliance advice, and reading it creates no professional relationship. For decisions about your business, talk to a qualified professional.