A departure should end access cleanly, not leave quiet openings behind.
An account can look closed while a browser session still works, an API token remains active, or a team password lives in an old spreadsheet. Those small leftovers are easy to miss—and they can turn an ordinary departure into an avoidable security gap.
A disciplined offboarding routine is not about mistrust or punishment. It is a calm transfer of control: disable individual logins, revoke active sessions and tokens, rotate shared credentials, and confirm that company devices and recovery methods are no longer tied to the former employee. With a clear owner and a recorded checklist, the handoff becomes routine, respectful, and far easier to verify.
- Include SaaS accounts, VPN, password managers, cloud consoles, support tools, and shared inboxes—not only the main company login.
Set the clock and assign owners
An offboarding request should start as soon as a departure is confirmed—not when someone remembers on the final afternoon. HR records the final working time, time zone, employment type, and whether the exit is routine or sensitive. That timestamp becomes the cutoff used by every team.
Give each function a clear deliverable
Ambiguous handoffs leave accounts open. Name a coordinator and assign responsibility:
- HR: sends the verified departure notice and updates.
- Manager: lists systems, shared mailboxes, projects, and company property.
- IT: disables identity access, sessions, devices, and recovery methods.
- Security: sets the order for privileged or high-risk access and checks completion.
- Legal: flags retention, litigation holds, or regulated records before data is removed.
For ordinary exits, access can end at the recorded cutoff. For involuntary, privileged, or suspected-risk departures, security should revoke critical access at notification—or before the conversation begins. Record who approved any delay, its end time, and the reason. A named checklist makes a tense handoff controlled and auditable.
Build an Access Map From the Work Actually Done
-
Start with recent work, not the app catalog
Review the employee’s job title, current projects, ticket queue, calendar, and last 60–90 days of activity. Ask the manager which systems, client spaces, repositories, and shared inboxes the person used in practice; this catches tools that never appeared in a standard role template.
-
Trace every identity and sign-in route
List the primary work account plus aliases, contractor identities, admin accounts, local computer profiles, browser profiles, VPN accounts, and single-sign-on connections. Record direct logins separately from apps reached through SSO, since either path may survive a partial shutdown.
-
Look for authority that was delegated or shared
Check mailbox and calendar delegation, shared-drive ownership, approval queues, payment permissions, support-console roles, social media managers, and emergency or break-glass accounts. Ownership transfers matter as much as removal: work should not become inaccessible when the account is closed.
-
Include devices, recovery methods, and quiet credentials
Inventory managed and personal-device enrollment, authenticator apps, hardware security keys, saved passwords, recovery email addresses, phone numbers, SSH keys, API tokens, service-account secrets, and developer-platform keys. These are common gaps in otherwise careful offboarding.
-
Confirm the map with evidence
Have the manager and IT owner review the list against audit logs and recent sign-ins, then mark an owner and cutoff action for each entry. This role-based record supports the business data security guide and gives the revocation team a clear, defensible checklist.
If uncertainty remains, revoke first where business continuity permits, then restore only the access a named owner can justify.
Shut Down the Identity Control Plane
-
Disable the primary identity at the cutoff
Block sign-in in the central directory or SSO provider at the agreed time. This is the fastest way to stop access across connected applications.
-
Terminate live sessions and revoke tokens
Force sign-out, revoke refresh tokens, and invalidate personal access tokens, API keys, and app passwords tied to the identity. A disabled account alone may leave an already-authenticated browser or script running.
-
Remove recovery routes
Delete alternate email addresses, phone numbers, backup codes, security keys, trusted devices, and delegated password-reset rights. Recovery settings can quietly reopen a closed account.
-
Review privileged access before ordinary apps
Treat cloud consoles, production systems, finance tools, domain administration, and password vaults as an immediate review queue. MFA-enabled administrator access must be revoked even when the main account has already been disabled.
-
Check indirect and break-glass paths
Remove group-based roles, impersonation rights, service-account delegation, and emergency accounts known to the departing worker. Record what was removed and have the assigned owner confirm the result.
For high-risk departures, complete privileged revocation before announcing the departure or starting routine application cleanup.
Remove Permissions and Settle Account Ownership
-
Strip direct access from every application
Remove the departing employee from each app, workspace, project, shared drive, database, CRM view, and support queue identified in the access map. End active external invitations too; a guest seat can remain useful long after the main login is gone.
-
Remove group and role inheritance
Check identity-provider groups, application teams, mailing lists, and nested groups. Role-based access removal matters here: deleting a direct assignment does not help if a group still grants the same permission.
-
Review records with individual ownership
Transfer ownership of files, calendars, automations, dashboards, repositories, domains, and customer records to an active business owner. Confirm that the recipient can edit, administer, and recover the asset before removing the former owner.
-
Close collaboration routes outside the company
Remove the person from client portals, vendor consoles, partner workspaces, shared channels, and external distribution lists. Reassign relationship contacts so replies, renewals, and security notices do not disappear into an unattended account.
-
Choose disable, transfer, or delete deliberately
Disable an account first when records, audit history, or a short retention period may be needed. Transfer business content before deletion. Delete only after legal, retention, billing, and ownership checks show nothing must remain; document the decision and date.
A brief second review catches permissions granted through groups or external tenants.
A disabled work account does not stop a badge from opening the office, a laptop from retaining files, or a hardware key from approving a login. The access map should now be checked against the real-world tools the person handled.
Collect, disable, and verify
Cancel building badges, parking access, visitor-system privileges, alarm codes, locker access, and data-center entry. Retrieve company phones, laptops, tablets, headsets, removable drives, and loaned equipment; record serial numbers and confirm remote management or wipe status where available.
Also remove registered hardware security keys, smart cards, and authenticator devices. A key that is not recovered should be removed from every identity it could unlock, rather than simply marked as missing.
Rotate what was shared
Shared credentials are a common loose end. Change every password, PIN, API secret, Wi-Fi passphrase, vault entry, and emergency code known to the former employee—even if the account remains needed. Update dependent automations after rotating service-account secrets, then test that scheduled jobs still run.
Finally, remove the person from client portals, vendor dashboards, support consoles, banking tools, and partner systems. Ask each outside administrator for written confirmation when internal teams cannot directly revoke access.
Removing a name from a password vault is not enough. If a shared secret was viewed, copied, or used, treat it as exposed and replace it.
Preserve the work, prove the closure
Removing access is only half the job. Before deleting an account or wiping a device, transfer ownership of active projects, shared folders, calendars, dashboards, and customer conversations to a named employee. Confirm that the new owner can open the material—not merely that a transfer request was sent.
Handle email and retained records
Decide how the mailbox will be handled: temporary forwarding, an approved auto-reply, delegation to a manager, or archival. Capture records that belong to the business, including key files, approvals, and case notes, using the organization’s normal retention location. If a legal, HR, audit, or investigation hold applies, do not delete relevant mail, files, chat, or device data; preserve it and notify the responsible team.
Leave a dated trail
Record each completed action with the date, time, system, owner, and evidence reference, such as a ticket number or screenshot location. This audit trail for departing employee access makes later questions far easier to resolve: it shows what was transferred, what was retained, and when access actually ended. A short, factual log turns a rushed departure into a defensible, repeatable process.
Verify Every Closure
-
Test that sign-in fails
Using an approved test method, confirm that both direct sign-in and single sign-on are denied. Record the time, system, and result.
-
Confirm old sessions are gone
Check that active browser sessions, mobile sessions, API tokens, and remembered devices no longer reach company data.
-
Verify groups and handoffs
Review key groups, shared drives, project spaces, and customer records. The replacement owner should be able to open and manage each transferred item.
-
Check devices and privileged systems
Confirm device unenrollment and wipe status where applicable. Recheck admin consoles, password vaults, code hosting, finance tools, backups, and emergency accounts.
-
Run a short closeout review
Capture missed accounts, idle SaaS licenses, and delays or unclear handoffs. Turn recurring misses into a checklist update before the next departure.
Keep the validation record with the offboarding evidence.
Turn Each Departure Into a Better Checklist
- Assign a named owner and due date to every action—especially the final verification.
- Keep the completed checklist with departure records, including exceptions and evidence.
- After each offboarding, note the missed account, unclear handoff, or delayed step and update the template.
A strong offboarding process is not a one-time scramble. It is a dated, owner-assigned checklist used for every departure, whether the exit is planned, urgent, or routine. Each item needs a clear result: completed, not applicable, or escalated.
Once the departure is closed, spend a few minutes reviewing what slowed the process or surfaced unexpectedly. A forgotten vendor portal or unclear device owner is not merely a mistake; it is the next checklist improvement. Small updates after every cycle steadily turn a workable process into a dependable one.
