Security & Risk
Offboarding and access recovery checklist for small MSPs
A practical offboarding checklist for small MSPs closing a client relationship without leaving unmanaged access, unclear ownership, open backup risk, or undocumented exceptions.
Short answer: Offboarding is a security workflow, not only an account closure task. A small MSP needs to remove or transfer access, document open risk, and leave evidence that the operating responsibility ended cleanly.
Offboarding starts before the last day
Client offboarding gets messy when it starts after the final invoice, cancellation notice, or replacement provider request. By then, the MSP may be trying to recover access, explain old exceptions, and close tickets under pressure.
The CISA advisory for managed service providers and customers is a useful reminder that MSP access carries real risk. Offboarding should therefore treat access cleanup as security work, not as a favor performed after the commercial relationship ends.
Treat offboarding as the reverse side of the client onboarding checklist: what was granted, connected, monitored, documented, and billed now needs a clean owner.
Name the end state
Before removing anything, define what clean means:
- who owns admin accounts after the MSP leaves;
- whether RMM agents are removed or transferred;
- who controls backups and restore history;
- what documentation is exported;
- what open tickets remain;
- what risks are accepted by the client;
- what vendors must be notified.
The goal is not to punish the client. The goal is to stop hidden access from becoming hidden risk.
The NIST Cybersecurity Framework 2.0 helps frame that end state: governance, identification, protection, detection, response, and recovery all need a clear owner after the MSP exits. The offboarding record should make that ownership visible.
Access inventory
Review at least these surfaces:
- identity provider and global admin roles;
- Microsoft 365 or Google Workspace delegated access;
- RMM, PSA, documentation, backup, EDR, DNS, domain registrar, firewall, and hosting portals;
- shared passwords and secrets;
- vendor portals where the MSP is a listed contact;
- monitoring alerts that still notify the MSP;
- client-owned break-glass accounts.
For Microsoft tenants, the GDAP introduction and least-privileged role guidance are useful references because delegated admin access should be intentional, limited, and reviewable. Offboarding should remove or transfer that access deliberately, not leave it as a forgotten relationship.
Tie this back to the security baseline. Offboarding is part of access control.
Backup and restore ownership
Backups are the most dangerous place to leave ambiguity. Confirm:
- what data is still protected;
- who can restore it;
- who receives backup failure alerts;
- whether retention continues after the contract ends;
- whether the client has credentials and billing ownership;
- what restore test evidence exists.
If backups stop, say so plainly. If they continue under the client or another provider, record the handoff.
The FTC cybersecurity guidance for small businesses points small organizations toward practical recovery preparation. During offboarding, backup ownership and restore responsibility should be explicit before the MSP stops receiving alerts or holding credentials.
Vendor and documentation handoff
Vendor coordination should not become an endless free project after cancellation. List the vendors, contacts, active cases, renewal dates, and known blockers. Then identify what the MSP will do during offboarding and what requires separate approval.
Documentation should be exported in a usable form when the contract allows it. Do not leave the client with screenshots of a system they cannot access.
Open tickets and exceptions
Each open item needs a final state:
- closed before offboarding;
- transferred to the client;
- transferred to the new provider;
- converted to a project;
- recorded as accepted risk;
- blocked by missing approval or access.
Use the service desk model to keep the closeout factual.
Final evidence packet
The final packet can be simple:
- offboarding date;
- access removed or transferred;
- vendors notified;
- documentation exported;
- backups transferred or ended;
- open risks and tickets listed;
- client decisions recorded;
- remaining exclusions stated.
This evidence protects both sides. It shows the MSP did not leave silent control behind, and it shows where responsibility moved.
Common mistake
The common mistake is mixing security offboarding with the commercial argument. A cancellation may be frustrating, but access cleanup should stay disciplined.
When to change level
If offboarding takes days of detective work, onboarding and documentation were probably too weak. Use the closeout to improve the next client intake, access register, and monthly review.
FAQ
When should MSP offboarding start?
Offboarding should start as soon as the end date is known, not on the last day. Access, ownership, backups, open tickets, vendors, and risk decisions need time.
What should be removed during client offboarding?
Remove or transfer MSP-owned admin access, RMM agents, documentation access, backup admin rights, delegated cloud access, vendor portals, shared secrets, and ticket system access where applicable.
Should billing disputes control security offboarding?
No. Security offboarding should protect access, evidence, and client continuity. Commercial disputes need a separate process.
What evidence should a small MSP keep after offboarding?
Keep a dated closeout record showing access removed or transferred, exports delivered, open risks disclosed, pending tickets listed, and any client decisions recorded.
