Offboarding checklists are one of those artefacts that exist in nearly every company and work in nearly none. The reason is structural: the parts that are easy to automate get automated and the parts that require someone to know something get skipped, and the skipped parts are where the actual risk lives.
What follows assumes you already disable the email account. This is about the rest.
(The mirror-image problem, getting someone productive rather than safely removed, is covered in time to productivity for new hires. The two processes tend to be maintained by the same person and to fail in the same way.)
The three-window model
Thinking of offboarding as one event is what causes most of the failures. It has three windows with different risks.
Before notification matters only for high-risk departures — someone going to a competitor, a termination for cause, anyone with production or financial access. For these, revocation is scheduled to precede or coincide with the conversation. The gap between "we told them" and "we revoked it" is where the classic incidents happen, and it is almost always a calendar problem rather than a policy one.
The notice period is the awkward window, because the person is still working and still needs access to hand over. This is where organisations overreact, quietly escalating surveillance on everyone serving notice. That is disproportionate, in several jurisdictions unlawful, and corrosive — departing employees talk to the ones who stay. If a specific departure genuinely warrants heightened scrutiny of data movement, decide it explicitly, scope it narrowly, write down why, and check it against your proportionality obligations. If it does not, treat the notice period normally.
After departure is where the long tail sits: the accounts nobody revoked, the data nobody transferred, the records nobody decided about.
What actually gets missed
Account revocation through the identity provider is a solved problem. Here is what is not.
Applications outside the identity provider. Every organisation has more SaaS than IT knows about, adopted departmentally on a card, never federated. Those accounts survive departure indefinitely because nothing connects them to the leaver. This is the largest offboarding gap in most companies and it is invisible by construction — you cannot revoke what you cannot enumerate. Our piece on shadow IT and SaaS sprawl covers building that inventory, which is worth doing before you need it.
Shared and service credentials. The database password in a password manager, the API key in a runbook, the shared admin account for the billing system. These do not belong to the leaver and therefore do not appear in a leaver's account list, but they knew them. Rotation is the control, and it is the step most consistently skipped because it is inconvenient.
Personal devices. If BYOD is in play, cached company data walks out of the building and there is often no clean recovery path. This is one of the stronger arguments against monitoring or storing work data on personal devices in the first place — the offboarding problem has no good solution once you are in it.
Data ownership. Documents, dashboards, scheduled reports, automations and integrations owned by an individual account. When the account is disabled, these break, sometimes silently and sometimes months later. Transferring ownership is a genuine task and it needs a named recipient.
Third-party and customer-facing access. Client portals, vendor consoles, shared Slack Connect channels, the partner system somebody set up in 2024. These sit outside your tenancy entirely.
Physical and building access. Easy to forget in a remote-first company that nonetheless has an office.
The part almost nobody handles: their data
There is a category that belongs on this checklist and is almost never there. The departing employee generated records about themselves, and those records outlive them.
Monitoring and analytics data is the clearest case. You collected it for a purpose — capacity planning, workflow analysis — and that purpose has ended for this person. Continuing to hold detailed per-person activity records for someone who no longer works there is difficult to justify under any framework that asks you to keep data only as long as necessary.
The defensible position is deletion on a short timer after departure, retaining only what a specific obligation requires: payroll and employment records per your statutory schedule, security audit logs per your incident response policy, anything under a legal hold. Team-level aggregates that no longer identify the individual can generally persist, which is usually what people actually wanted from historical data anyway. The retention guide covers how to set these periods and the trap where small-team aggregates remain re-identifying.
The operational point is that this must be triggered by offboarding rather than left to a periodic sweep. If deletion depends on someone remembering during a quarterly review, it will not happen.
The checklist
Adapt it; the value is in the ordering and in the items people usually omit.
Ahead of the departure date
- Classify the risk level, and for high-risk departures schedule revocation to precede or coincide with notification.
- Identify every system the person has access to, including the ones outside your identity provider. If you cannot produce this list, that is the finding.
- Name the recipient for each piece of owned data, and confirm they accept it.
- Decide explicitly whether any heightened scrutiny applies during notice, and record the reasoning. The default answer is no.
On the day 5. Revoke identity provider access and federated applications. 6. Revoke everything not federated, working from the list in step 2. 7. Rotate shared credentials, service accounts and API keys the person knew. 8. Transfer data ownership per step 3, and confirm scheduled jobs and integrations still run afterwards. 9. Recover devices, and for any personal device confirm what company data remains and how it is removed. 10. Remove from third-party, client and partner systems. 11. Revoke physical access and building credentials.
After 12. Delete or aggregate the person's monitoring and analytics records per your retention policy, triggered by this process rather than a periodic sweep. 13. Confirm mail forwarding and shared mailbox delegation are configured deliberately rather than left open indefinitely. 14. Re-run an access search 30 days later and record what turned up. This is how the checklist improves.
Where ProdView fits
Two things are relevant here. Retention is configurable, so the post-departure deletion in step 12 is a setting rather than a manual exercise. And the collection is narrow to begin with — activity and application metadata, never screen content or keystrokes — which means the records that outlive an employee are considerably less sensitive than they would be with a screenshot-based tool.
ProdView also surfaces application usage across the fleet, which is often the fastest route to the shadow SaaS inventory that step 2 depends on. That is a side effect of measuring app usage rather than a security feature, but it is a useful one.
When not to pick us: you need forensic session records preserved for post-departure investigation. That is a legitimate requirement in some sectors and a UAM tool is the honest answer for the roles it applies to.
Try before you commit
Three seats are free forever. If the immediate need is the application inventory in step 2, a fortnight of usage data across a handful of machines will show you more of your real SaaS footprint than an expense-report audit will.
General information as of August 2026, not legal advice. Retention and employment obligations vary by jurisdiction; confirm yours before setting deletion schedules.