IT Offboarding Checklist
An IT offboarding checklist for small teams: disable SSO, revoke tokens, rotate shared secrets, transfer data, recover devices and record every step.
- Typical schedule per leaver
- The checklist 5 sections, 25 items
- Variables
{{employee_name}}{{last_day}}{{manager}} - Start from CI
Use this checklist every time someone leaves the company, whether they resign, retire or are let go. It covers the IT side only: accounts, access, data and devices. The HR side (contract, final pay, exit interview) belongs in a separate checklist that runs in parallel.
Who owns it
IT or the person who administers your identity provider owns the run. The leaver's manager owns the data handover decisions: which mailbox, files and projects go to whom. Agree the timing with HR first. For a friendly departure, access usually ends at close of business on the last day. For an involuntary exit, it ends while the conversation is happening.
Common pitfalls
- Disabling SSO and stopping there. Personal API tokens, SSH keys, OAuth app grants and accounts created outside SSO keep working. Check each system that has its own login.
- Forgetting shared secrets. If the leaver knew a shared admin password, a Wi-Fi key or a vault recovery code, rotate it. Disabling their account does not change what they remember.
- Deleting the account too early. Deletion can destroy mail and files you still need. Suspend first, transfer data, and delete later according to your retention policy.
- Owner-only resources. Domains, cloud billing accounts, app store listings and social media pages often have exactly one owner. Find them before the last day, not after.
- No record. Months later, someone will ask when access ended. Write it down.
Starting the run from your HR system or a webhook means no leaver is missed, and the run itself becomes the record of who revoked what and when.
The checklist: Revoke IT access for {{employee_name}}
Before the last day
-
Leave date
{{last_day}}and the exact cut-off time are confirmed with HR and{{manager}} -
Systems the leaver can access are listed from the identity provider and the app inventory
Include apps outside SSO: cloud consoles, domain registrar, payment providers, social media, app stores.
-
Resources where the leaver is the only owner or admin are identified and reassigned
Typical examples: DNS and domain accounts, cloud billing, GitHub or GitLab organisations, shared calendars.
-
{{manager}}has decided who receives the leaver's mailbox, files and open tickets -
Return of laptop, phone, keys, badges and hardware tokens is arranged
-
Recent bulk downloads, mail forwarding rules and external shares checked in the audit logs optional
Most useful for involuntary exits. A forwarding rule to a private address is easy to miss, and in some mail systems it keeps working after sign-in is blocked.
On the last day
-
Identity provider account suspended and all active sessions revoked
For example in Okta, Google Workspace or Entra ID. Revoking sessions matters, because a suspended user can stay logged in on existing sessions.
-
MFA factors and registered devices removed from the account
-
Accounts in systems outside SSO disabled one by one
-
Personal API tokens, SSH keys and deploy keys revoked
-
Third-party OAuth app grants removed from the account optional
-
VPN, remote access and Wi-Fi certificates revoked
-
Removed from password manager vaults and shared folders
-
Physical access badges and door codes deactivated
Shared secrets
-
Shared passwords and keys the leaver had access to are rotated
Use the password manager's access log to see which shared items the leaver could open.
-
CI/CD secrets and service account keys the leaver created or viewed are rotated optional
-
Break-glass and recovery codes the leaver held are regenerated optional
Data and devices
-
Email forwarding or an auto-reply is set up as agreed with
{{manager}} -
Files and documents are transferred to the new owner
-
Laptop and other devices are returned and checked against the asset register
-
Returned devices are wiped or locked in the MDM before reuse
Close out
-
Paid licences are reassigned or cancelled
-
Leaver removed from on-call rotations, distribution lists and group chats
-
Date for final account deletion is set according to the retention policy
-
HR and
{{manager}}are told that IT offboarding is complete
Checklist as Markdown
Start this checklist from your pipeline
When HR marks a leaver in the HR system, POST /api/v1/runs with template "Revoke IT access for {{employee_name}}" and the leave date as last_day.
curl -X POST https://runbook.metastic.ch/api/v1/runs \
-H "Authorization: Bearer $RUNBOOK_TOKEN" \
-H "Content-Type: application/json" \
-d '{"template": "Revoke IT access for {{employee_name}}", "variables": {"employee_name": "…", "last_day": "…", "manager": "…"}}'Frequently asked questions
When should IT revoke a leaver's access?
For a normal resignation, revoke access at the agreed cut-off time on the last working day. For a dismissal or any departure with risk, revoke access at the moment the person is told. Agree the exact time with HR in advance so nobody improvises.
Should I delete or suspend the account of a former employee?
Suspend it first. Deleting an account in most identity providers and office suites can delete mail, files and calendars with it. Transfer the data, keep the suspended account for the period your retention policy defines, and then delete it. Adapt retention periods to your jurisdiction; this is a practical checklist, not legal advice.
How do I find all the systems a leaver had access to?
Start with the app list in your identity provider, then add the systems that have their own logins. A shared app inventory or a password manager's access log helps a lot here. Every time you find a system that was missed, add it to the template so the next run includes it.
Updated