An IT offboarding checklist exists to lock down company data, recover every asset, and leave a paper trail proving each step happened. The single most critical control is disabling accounts, revoking sessions, and killing active tokens by the employee's departure day. IT or Security should own this process, coordinating closely with HR rather than inheriting a checklist built for paperwork alone.
TL;DR:
- Disabling accounts and revoking all sessions must be completed on the departure day, including revoking API keys, SSH keys, and cloud access tokens.
- Verification of offboarding steps should occur within 24 to 72 hours by someone other than the original executor, with evidence stored for audit compliance.
- Physical assets such as devices, badges, and security keys must be collected and verified before or on the employee’s last day, with drives wiped or destroyed if necessary.
- High-risk or immediate-term departures require urgent, same-hour revocation procedures, while standard resignations can follow scheduled deadlines with independent confirmation.
- Building a structured, ticket-based checklist with clear ownership, deadlines, and evidence links ensures consistent, verified offboarding instead of manual, error-prone processes.
Table of Contents
- Building a step-by-step offboarding checklist that works
- Revoking accounts, sessions, and tokens the right way
- Recovering devices, badges, and hardware credentials
- Setting SLAs for planned exits versus terminations
- Proving offboarding actually worked
- Handing off data and institutional knowledge cleanly
- Turning this into a copyable template
- What SMBs consistently get wrong about offboarding
- Getting help operationalizing your offboarding checklist
- FAQ
- Sources
Building a step-by-step offboarding checklist that works
A checklist only earns its name when it has owners, deadlines, and proof of completion attached to every line. Treat offboarding as three phases: the trigger, departure day, and the days that follow. Each phase needs a named owner, a deadline, and a way to verify the work actually happened, not just that someone said it did.
Phase 1: Trigger. The moment HR learns of a resignation, termination decision, or contract end date, notify IT and Security immediately. Build a standard distribution list so nobody has to remember who needs the heads-up.
- HR notifies IT/Security, the employee's manager, and Legal (for contested or high-risk departures) promptly after confirming the departure.
- IT/Security logs the employee's full access footprint: SSO, email, SaaS apps, VPN, shared drives, physical badges, and any admin or service accounts tied to their name.
- For planned departures, IT schedules departure-day actions in advance. For terminations or security-flagged exits, IT moves to immediate revocation.
Phase 2: Departure day. This is where the real security work happens.
- Disable the identity at the IdP level (Okta, Entra ID, Google Workspace) rather than deleting it, which preserves the audit trail.
- Block remote access: VPN, RDP, and any direct SSH paths into company infrastructure.
- Rotate or revoke API keys, SSH keys, and service credentials tied to the individual.
- Reclaim software licenses tied to their seat so the subscription doesn't keep billing a ghost account.
- Collect devices, badges, and hardware tokens per the asset inventory, detailed further below.
Phase 3: Post-departure follow-up. Within 24 to 72 hours, someone other than the person who executed the checklist should confirm every item actually closed out. Reassign any transferred assets in the inventory system, confirm license reclamation posted correctly in billing, and file the audit evidence (more on that shortly) somewhere retrievable.
CISA's Cybersecurity Performance Goals call for exactly this kind of same-day revocation paired with recovery of physical credentials like badges and key cards, with logging in place to catch failed login attempts that might signal a miss.
Pro Tip: Build the checklist as a ticketing system template with required fields, not a shared document; a ticket that can't close without evidence attached forces the verification step to actually happen.
Contractors and third-party workers need their own version of this checklist since their access often lives outside the standard HR system entirely, tracked instead through vendor management or a spreadsheet nobody owns.
Revoking accounts, sessions, and tokens the right way
Disabling someone's SSO login feels like the job is done. It usually isn't. A departing employee can still hold live cloud access keys, OAuth refresh tokens, or an active session token that an SSO disable never touches.
- Sync deprovisioning through SCIM or your identity provider wherever your SaaS stack supports it, so one disable action propagates everywhere instead of requiring a dozen manual logins.
- Disable accounts rather than delete them in the first pass; deletion destroys the logs you'll need later for verification or an audit.
- Force a session revocation across every connected app, not just the IdP, since an open browser tab can outlive the password reset.
- Rotate or disable API keys and SSH keys tied to the person, and rotate any cloud access keys (AWS, Azure, GCP) they could have generated independently of SSO.
- Audit every non-human identity, meaning service accounts and automation credentials, tied to their name or role. OWASP's guidance on non-human identities flags these as the category most commonly missed during offboarding, recommending they get recertified, rotated, or decommissioned rather than quietly left active.
- Pull MFA factors registered to their devices and reassign any privileged or admin roles to a named successor before closing the ticket.
CIS Control 16 reinforces the same point from the inventory side: organizations need a running account of who holds access to what, with a standing process to disable or remove anything unneeded on a regular schedule, not just when someone leaves.
Pro Tip: A disabled SSO account with a live, unrotated AWS access key is still a breach waiting to happen. Treat cloud keys and OAuth tokens as separate checklist items, never as covered by the IdP disable.
Recovering devices, badges, and hardware credentials
Physical assets need the same rigor as digital access, with a deadline attached to every item.
- Track each device, badge, token, and SIM card in an inventory with serial number, assigned date, condition, and a hard return deadline tied to the departure date.
- Wipe and reimage laptops and phones before reassignment; destroy drives instead when the device held highly sensitive data or can't be verified clean.
- Collect hardware security keys (YubiKeys, smart cards) and badges on departure day itself, since these often bypass software-based MFA entirely.
- Escalate missing or damaged items to the employee's manager and Legal immediately rather than letting it slide as a minor loose end.
Pro Tip: Keep a bootable sanitization toolkit on hand, a ready reference like this cybersecurity USB toolkit checklist helps standardize wipe procedures across whoever handles IT that week.
Setting SLAs for planned exits versus terminations
Not every departure carries the same risk, so the checklist needs a tiered response built in.
- Resignation with notice: Standard phased revocation, with full access shutdown on the agreed last day.
- Termination or security incident: Immediate revocation, same hour if possible, no waiting for end of day.
- Contract or vendor end date: Scheduled revocation tied to the contract's expiration, verified independently afterward.
Set measurable SLAs: immediate action for privileged or high-risk roles, same-day action for standard employees, and an independent verification window within a few days after departure for every case. Privileged accounts, admin roles, and anyone with financial system access should always escalate to the immediate tier regardless of how the departure itself is categorized.
Proving offboarding actually worked
A checklist that nobody verifies is a checklist that fails quietly. Capture evidence at every step, not just a checked box.
- Save IdP and SCIM disable event logs with timestamps.
- Record API key and credential rotation confirmations.
- File signed asset return receipts.
- Have someone outside the original executor independently re-check active sessions and tokens 24 to 72 hours after departure.
Mandatory independent re-verification within 24 to 72 hours is a core recommendation from CISA's Cybersecurity Performance Goals, which treat timestamped IdP and SCIM evidence as the standard proof for high-risk departures. Store this evidence long enough to satisfy SOC 2 or SOX retention requirements, and feed disable events into a SIEM where one exists so a missed revocation triggers an alert instead of surfacing months later in an audit.
Handing off data and institutional knowledge cleanly
Access revocation protects the company. Knowledge transfer protects the work. Before the departure date, map every business-critical item the person owns and assign a successor in writing.
- Identify inbox contents, shared drive folders, and repository ownership that need a new named owner.
- Reassign cloud resource ownership (billing accounts, DNS, registrar logins) so nothing sits tied to a disabled identity.
- Transfer password-safe entries and vendor account credentials to the successor, not to a shared password left in Slack.
- Decide what gets retained versus deleted with HR and Legal, particularly where NDAs or record-keeping rules apply.
- Leave a short handover runbook and contact list behind, even a one-page document saves the next person hours of guesswork.
Turning this into a copyable template
Translate the checklist above into fields any ticketing system or spreadsheet can hold.
- Phase: trigger, departure day, or post-departure.
- Action: the specific task (disable SSO, rotate API key, collect badge).
- Owner: the named person responsible, not a department.
- Deadline: tied to the departure date or SLA tier.
- Verification method: log, receipt, or independent check.
- Evidence link: where the proof lives.
| Field | Example value |
|---|---|
| Phase | Departure day |
| Action | Disable SSO and revoke sessions |
| Owner | IT Security lead |
| Deadline | End of departure day |
| Verification | SCIM disable event log |
Map these fields directly to your ticketing system's custom fields and, where possible, to SCIM webhook triggers so the evidence link populates automatically. Export the template as a living runbook, not a one-time PDF, and update it every time a new SaaS tool or access type enters the environment.
What SMBs consistently get wrong about offboarding
Most small and mid-sized businesses treat offboarding as an HR task with an IT footnote, which is backward. HR knows the person is leaving; IT and Security know what that person could still touch. The recurring gaps we see are unmanaged personal devices still holding business credentials, service accounts nobody remembers creating, and zero independent verification after the fact. Three fixes cost almost nothing: enforce MFA everywhere, run a standing asset inventory cadence, and automate IdP disable events through SCIM so revocation doesn't depend on someone remembering a Tuesday afternoon task.
, Dustin Collett
Getting help operationalizing your offboarding checklist
Writing the checklist is the easy part. Running it the same way every single time, for every departure, without a dedicated IT team watching the logs, is where most SMBs fall short. Managed IT services built around standing operational discipline: fixed per-user pricing, 24/7 monitoring, and a defined process instead of a checklist that quietly skips steps when the week gets busy.
- Our IT & Security Assessment reviews your current offboarding process against the gaps covered here: identity governance, asset tracking, and independent verification.
- Ongoing clients get offboarding built into our Managed IT Services stack, so revocation and evidence capture run as a standard part of the account, not a special request.
- Our Cybersecurity Risk Assessment can flag unmanaged devices and dormant service accounts before they become the item you find during an audit instead of before one.
If your offboarding checklist depends on one person remembering every step, consider scheduling an assessment to help turn it into a process that runs the same way every time.
FAQ
What should be included on an IT onboarding checklist?
An IT onboarding checklist should cover identity creation (SSO, email, core SaaS), device provisioning, license assignment, and documentation of every account created so it has a clean record to reference during that person's eventual offboarding. Our IT onboarding checklist walks through the full setup sequence in detail.
What are the standard offboarding process steps?
The standard steps are notification, access revocation, asset recovery, data handover, and verification, each with a named owner and a deadline. For high-risk departures, revocation happens immediately rather than waiting for the employee's last day, per CISA's Cybersecurity Performance Goals.
What are offboarding documents?
Offboarding documents are the records that prove each step happened: IdP and SCIM disable logs, signed asset return receipts, API key rotation confirmations, and any handover runbooks transferring ownership of accounts or data. These get retained to satisfy audit requirements like SOC 2 or SOX.
Who in the company is responsible for IT offboarding?
IT or Security should own the offboarding process, coordinating with HR rather than leaving it as an HR-only checklist. An FTC Office of Inspector General audit found that offboarding gaps commonly trace back to a lack of single-point coordination, and recommended designating one clear owner to prevent partial offboards.
How soon should access be revoked after an employee leaves?
High-risk or terminated departures should see access revoked immediately, while standard resignations with notice can follow a same-day revocation on the agreed last day. An independent check of active sessions and tokens should follow within a few days to confirm nothing was missed.