Quick answer: Offboarding is complete when the departing person can no longer use the business account, another named owner can continue the work, and the records you decided to keep are still available. Preserve and transfer the work before destructive deletion, revoke access on an agreed timetable, and verify both outcomes. If access must end immediately, use the approved suspension or revocation route first; do not delay it while the handover is unfinished. A disabled login is not the same thing as a finished handover.
Jump to: Five-step sequence · Decision table · Worked example · Offboarding record
For: small businesses and lean teams removing an employee, contractor or outside partner from SaaS tools. This is an owner-facing operating checklist, not legal advice, an HR process or a product-specific guarantee. Use each vendor’s current admin instructions for the actual account changes.
Stop condition: If you cannot name the destination owner or predict what deletion removes, hold the destructive step and investigate.
- Start with the business outcome
- Build one access-and-work inventory
- Use a five-step offboarding sequence
- Choose suspend, transfer, remove or investigate
- Worked example: one person, six systems
- Test with evidence, not confidence
- Check the bill separately from the login
- Avoid the shared-password trap
- Copy this offboarding record
- Useful detail: Check the app after the person leaves
- Sources and scope
Start with the business outcome
Do not begin with a list of delete buttons. Begin with the work that must continue tomorrow: open enquiries, customer accounts, scheduled messages, shared documents, reports, automations and billing administration. Name the person responsible for each area after the departure.
The UK’s National Cyber Security Centre recommends a joiners, movers and leavers process for SaaS access, including external users. NIST guidance for personnel termination includes disabling system access within an organisation-defined time and revoking authenticators and credentials. Those sources establish the need for a controlled access lifecycle. The detailed sequence below is a Practical SaaS Lab operating proposal for a small team.
Coordinate the timetable with the responsible business, HR, legal and technical people where those functions exist. A planned contractor finish, a sudden termination and a change of role can require different timing. Do not let this checklist override employment obligations, evidence-preservation requirements or an incident-response plan.
Build one access-and-work inventory
Use the person’s job, browser bookmarks, approved password manager, identity provider, expense records and team knowledge to find the relevant services. Do not ask them to send passwords. Record the business account, their role, the business owner, the work stored there, connected applications and the intended action.
Include access that is easy to miss:
- accounts created with a personal email address;
- guest access to a customer or partner workspace;
- shared inboxes, calendars and booking tools;
- API tokens, app connections and automation ownership;
- recovery addresses, trusted devices and active sessions;
- domain, hosting, analytics, advertising and payment administration;
- files or reports stored in the person’s private workspace rather than a team-owned area.
An inventory is not a demand to retain everything. It is the evidence needed to choose what the business must transfer, archive, restrict or remove.
Use a five-step offboarding sequence
- Set the authority and time. Record who approved the offboarding, the effective time and who may change the plan. Separate a planned transfer window from the moment access must end.
- Transfer operational ownership. Reassign open work, shared assets, billing contacts, integrations and customer responsibilities using supported product features. Keep a list of exceptions.
- Preserve required records. Retain only what the business is authorised and required to keep. Document where it is stored, who can access it and how long it should remain. An export is evidence, not automatic permission to keep every record forever.
- Revoke access. Disable or remove the user’s account as the approved timetable requires. End sessions and review authenticators, recovery routes, guest access, shared credentials and connected apps. Use the vendor’s current instructions rather than guessing what “delete” means.
- Verify continuity and denial. Confirm the former route no longer works and the successor can complete a real, low-risk task. Check that records, ownership, notifications and automations behave as intended.
Keep the execution list access-controlled. It may reveal system names, owners and weaknesses that do not belong in a public project board.
Choose suspend, transfer, remove or investigate
On a small screen, swipe the table sideways to see all columns.
| Situation | Likely next action | Check before acting |
|---|---|---|
| Immediate access must stop, but ownership is still being resolved | Use the supported suspension or disable route if appropriate | What remains accessible to admins, what still runs and what the licence costs. |
| Customer files and open work have a named successor | Transfer using supported ownership tools, then test | Folder permissions, record owners, notifications and unfinished tasks. |
| The person used a shared credential | Replace the shared route and review where it was reused | Sessions, recovery methods, integrations and every authorised remaining user. |
| A vendor’s delete action may remove data or automations | Hold deletion and inspect current vendor documentation | Retention period, transfer options, reversibility and downstream effects. |
| A contractor still needs one narrow handover task | Time-box the smallest supported access, if approved | Exact task, role, expiry, reviewer and evidence of completion. |
These are planning prompts, not instructions for a particular product. “Suspend”, “archive”, “remove” and “delete” can have materially different effects across services and plans. Check the current account-specific behaviour before committing to a destructive action.
Worked example: one person, six systems
Fictional example: a four-person consultancy is offboarding a coordinator. The inventory finds a CRM, shared inbox, booking tool, file store, automation platform and website account.
- The CRM contains 14 open enquiries. They are reassigned to two named owners, and both owners can open their new queues.
- The shared inbox is team-owned. The coordinator’s individual access and active sessions are removed; the shared address itself remains.
- The booking tool has three future meetings. The team confirms the host, calendar and customer notification for each one before removing the old user.
- Two automations run under the coordinator’s connection. A named operator reviews and reauthorises them through the supported product flow, then sends one labelled test through each route.
- The file store contains a private folder with an approved proposal and a personal draft. The proposal moves to the controlled client folder; the personal draft is not copied merely because it exists.
- The website account is removed after another maintainer completes an ordinary edit and confirms the correct role boundary.
The team records six systems reviewed, not “six tasks completed”. Each system has several acceptance checks. If one automation test fails, the offboarding remains open for that item even if the former user can no longer sign in.
A later audit should be able to answer who approved the changes, when access ended, where the work went and what was actually tested. “We changed the password” is a weak substitute for all four.
Test with evidence, not confidence
Use low-risk, labelled test data where a live workflow needs verification. Do not impersonate the departing person or send real customer messages simply to prove the route works. For each critical system, record:
- the admin console shows the old user or guest disabled or removed, with sessions and other access routes revoked as supported; verify through authorised admin checks, not by using their password;
- the new owner can find the expected records and complete the normal task;
- unfinished work keeps the correct customer, status, value and next action;
- notifications and connected automations reach the intended owner;
- billing, recovery and administrator ownership do not depend on the former user;
- an unresolved exception has an owner, due date and containment step.
For high-risk or disputed departures, follow the organisation’s legal, HR and incident-response direction. Evidence collection and device handling may need specialist control; a generic SaaS checklist should not decide that on the fly.
Check the bill separately from the login
Removing a person and reducing a subscription are separate checks. After access ends, record whether a paid seat remains assigned or available, who now owns billing, and whether the agreement permits a seat reduction for the current or next term. An unused seat is a review item; it is not a confirmed saving.
Use the SaaS renewal calendar to record the verified action deadline and owner. If the team is reviewing the whole tool rather than one person’s access, use the subscription audit before deciding to retire it. Retain the account confirmation and inspect the next invoice. Keep an unresolved billing check open even when access revocation has passed.
Avoid the shared-password trap
A shared password turns one person’s departure into an account-wide mystery. You may need to change the credential, end existing sessions, update approved integrations and redistribute access securely. That still does not prove the work is owned correctly.
Prefer named accounts and task-based roles where the service supports them. Keep a business-controlled administrator and recovery route. For WordPress, use the task-based user-role checklist. For a wider site transition, use the website handover tests.
Copy this offboarding record
Person / company and relationship:
Approved by / effective time / executor:
Systems and guest workspaces found:
Business owner after departure:
Open work and customer responsibilities transferred:
Files and records retained, location and retention basis:
Account action: suspend / transfer / remove / hold:
Sessions, authenticators, recovery routes and connections reviewed:
Billing and administrator ownership checked:
Continuity test and result:
Access-denial check and result:
Exceptions, containment, owner and due date:
Final reviewer and completion time:
Use the software onboarding guide to define the task and owner before the next person joins. If the tool itself is being removed, use the data export checklist and SaaS cancellation checklist instead of treating user offboarding as product cancellation.
Useful detail: Check the app after the person leaves
Slack notes that some integrations remain active after member deactivation while member-dependent apps or permissions may stop.
The offboarding acceptance check should ask two questions: did personal access end, and did the approved operating integration still work? Neither answer establishes the other.
Try this:
- Record which alerts or workflows depend on the departing account.
- Prepare an authorized replacement owner where the product supports it.
- After deactivation, test the intended alert and inspect the remaining integration access without reviving the person’s account.
Source: Slack: deactivated members and integrations. Checked October 3, 2026. The practical check is a PSL suggestion.
Sources and scope
UK National Cyber Security Centre: Using Software as a Service securely (user onboarding and offboarding), checked September 30, 2026. NIST SP 800-53 Rev. 5, Update 1, including PS-4 Personnel Termination, checked September 30, 2026. The five-step sequence, decision table, worked example and record are Practical SaaS Lab editorial recommendations. Vendor actions and retention rules vary by product, plan, contract and jurisdiction.
