Employee Offboarding Checklist: Removing Access Safely

An employee offboarding checklist for IT has one priority and several follow-ups. The priority: disable the person's sign-in at the agreed time — identity account, single sign-on and active sessions — so every connected app is cut off at once. Then transfer what they owned (files, mailbox, requests, admin roles), recover devices, remove access to systems outside single sign-on, rotate any shared secrets they knew, and record it all. Run it as one tracked request triggered by HR, and time the access cut-off with HR rather than discovering the departure later.

Why offboarding fails

Onboarding fails loudly — a new starter with no laptop complains. Offboarding fails silently: a former employee who still has access to a SaaS tool or a shared password doesn't file a ticket. The causes mirror onboarding:

• IT hears about the departure late, or after the fact.
• Access was granted piecemeal over years, and nobody knows its full extent.
• Shared credentials and personal-device logins sit outside central control.

The fixes are the same: an early trigger, a known inventory of access, and a checklist on a tracked request.

The trigger and the timing

HR files an offboarding request as soon as a departure is confirmed, with the last working day, the exact time access should end, the manager, and whether the departure is friendly or sensitive.

Timing depends on the situation:

• Planned, friendly departure: access ends at the close of the last working day. The person can hand over normally until then.
• Sensitive departure (dismissal, dispute): access ends before or during the conversation where the person is told. HR and IT agree the minute in advance.

The request's deadline is the cut-off time, and it should sit at the top of the queue as that time approaches. How deadline-sorted queues work is covered in the SLA tracking guide.

Step 1: disable sign-in first

At the agreed time:

• Disable the identity account (don't delete it yet — you'll need its data and audit history).
• Revoke active sessions and tokens — signing out everywhere, including refresh tokens and app passwords.
• Remove or reset MFA methods registered to their personal phone.
• Remove from privileged groups and admin roles immediately.

With single sign-on, disabling one account cuts access to every connected app. That's why disabling the identity comes first, and why onboarding everyone through SSO pays off here.

Step 2: transfer what they owned

Before anything is deleted:

• Files and folders — transfer ownership to the manager or a named successor.
• Mailbox — forward or delegate for a defined period, with an auto-reply naming a contact.
• Open requests and tasks — reassign in the help desk and task board so nothing silently stalls. If they were an agent, their queue must go to someone today.
• Ownership roles — if they owned an organization account, a team, a shared calendar or a domain, transfer ownership explicitly. In LetRelay, the owner role moves only through a deliberate transfer, and only the owner can add or remove admins — so if the owner is the one leaving, transfer ownership before their last day.
• Scheduled jobs and integrations running under their account — move them to a service account so they don't break when the account is disabled.

Step 3: access outside single sign-on

The dangerous part: everything not behind SSO.

• SaaS tools with local accounts — remove the user in each one. Your access inventory tells you which; without one, check billing records for per-seat tools.
• Shared credentials they knew — rotate them. That includes shared admin logins, Wi-Fi passwords for sensitive networks, door codes, and API keys they created or saw.
• Personal access tokens and SSH keys in code hosts and servers — revoke.
• Their personal devices — remove company data from mail and chat apps where your device management supports selective wipe.
• Physical access — badges, keys, parking.

The CIS Critical Security Controls treat account management as a core control: disable dormant and departed accounts promptly, and keep an inventory of accounts to know what to disable. Microsoft's access reviews guidance makes the same point from the other direction — periodically confirm who still needs access, so departures and role changes don't leave stragglers.

Step 4: devices

• Collect company devices — laptop, phone, tokens, peripherals. For remote staff, send a prepaid return kit before the last day.
• Update the asset record: returned, condition, date.
• Wipe and reprovision after any data retention hold has been decided.

Step 5: record and verify

• Log every step on the request: who disabled what, when. The request's history is your audit trail.
• Verify a day later: try to sign in as the account (should fail), check that transferred files are accessible to the successor, check that no SaaS seats remain billed.
• Delete or archive the account after your retention period.

Role changes are mini-offboardings

When someone moves from finance to marketing, they need marketing access and must lose finance access. Without the second half, long-serving employees accumulate access from every role they've held — a problem security teams call privilege creep. Treat internal moves as an offboarding from the old role plus an onboarding to the new one, using the same role templates as the onboarding checklist.

Run it as one request with a checklist

A single offboarding request with the checklist above gives HR, the manager and IT one shared view, a deadline at the cut-off time, and a permanent record. LetRelay's tasks support checklists added at creation and edited inline, so an offboarding template can be applied in one step. Make the request private to HR and IT if the departure is sensitive; see role-based access for internal tools for how private queues are enforced.

Measure it

• Time from last day to sign-in disabled — should be zero or negative (disabled before or at the end of the last day).
• Stragglers found in quarterly access reviews — accounts that should have been removed. Each one is a gap in the checklist.
• Devices not returned within 14 days.

FAQ

What is the first step when an employee leaves?

Disable their identity account and revoke active sessions at the agreed time, so every system connected through single sign-on is cut off at once.

Should I delete a departing employee's account immediately?

Disable it immediately; delete it later, after transferring files, mail and ownership and after any retention period, so data and audit history aren't lost.

How do I find all the access a departing employee has?

From an access inventory built at onboarding (role templates plus approved exceptions), single sign-on app assignments, and billing records for per-seat SaaS tools.

What about shared passwords the employee knew?

Rotate them. Any shared credential, API key or code a departing person knew should be changed as part of offboarding.

Sources

• CIS Critical Security Controls v8
• Microsoft Entra — Access reviews overview
• NCSC — Passwords guidance
• NIST — Least privilege (glossary)
• Wikipedia — Separation of duties