IT Offboarding Checklist: The Complete Security Guide (2026)

An IT offboarding checklist is the ordered list of steps IT takes when someone leaves: block sign-in and revoke sessions, remove access in every app, revoke API keys and tokens, recover and wipe devices, hand over data, reclaim licences and keep a dated record of each step. For a dismissal, cut access before the person is told.

IT teams spend days onboarding a new hire — provisioning accounts, deploying devices, and setting up access to 30 or more systems. When that person leaves, the same access footprint needs to be dismantled completely, in a few hours, often under pressure. When it isn't, the cost is significant. A 2014 study by Intermedia and Osterman Research found that 89% of former employees still had access to at least one corporate application after leaving. Ponemon Institute's 2022 Cost of Insider Threats report puts the average cost of an insider threat incident at $15.38 million. This guide covers every phase of IT offboarding from a security perspective — what to do, in what order, and how to verify it's complete.

The IT Offboarding Checklist at a Glance

Before the last day

As soon as notice is accepted. For a dismissal, when HR books the meeting.

• HR confirms the last working day, the leaver type and an access cut-off time with IT
• IT lists the leaver's accounts, devices, admin roles and the shared passwords they can see
• The manager names the tools the team uses outside single sign-on and who takes over the work
• The leaver moves working files to shared locations and writes up what only they know

At the cut-off

The end of the last working day. During the meeting for a dismissal.

• IT blocks sign-in, revokes sessions and removes MFA methods
• IT disables VPN and remote access
• The manager or IT collects the laptop, phone, security keys and badge

Within 48 hours

• IT disables accounts in apps outside single sign-on
• IT revokes API keys, personal access tokens, SSH keys and OAuth grants, and rotates shared passwords
• IT moves files, the mailbox and admin roles to a named successor

Within two weeks

• IT wipes the devices and updates the asset register
• IT reclaims licences and removes group memberships
• IT runs a final access review and records the sign-off

Every phase below expands one of these lines.

This is CheckFlow's free IT offboarding checklist template as a live checklist: seven phases, each step with an owner and a due date counted from the last working day. Try the live checklist.

Need it on paper? Add the template to a free trial, start a checklist for the leaver and print it, or save it as a PDF, from your browser's print dialog.

Why IT Offboarding Is a Security Problem

Offboarding is not an HR admin task — it is a security control point. The departing employee has legitimate credentials that security tools won't flag as anomalous. They know where the sensitive data is. They may be motivated. The numbers reflect the scale of the problem:

• 89% of ex-employees retained access to at least one app (Intermedia and Osterman Research, 2014)
• The average company ran 323 SaaS applications, and IT directly managed only 23% of them (Zylo SaaS Management Index, 2022)
• 71% of HR workers who offboarded someone in the past year had at least one leaver keep company equipment (Capterra, 2022)

The departing employee doesn't need to be malicious. A former colleague who can still log into Slack or read customer data in Salesforce represents an uncontrolled access risk — and an audit finding waiting to happen.

Voluntary vs. Involuntary: The Timing Difference

This is one of the most practically important distinctions in IT offboarding and is frequently absent from generic checklists. The process is structurally different depending on departure type — and treating them the same way is a security failure.

Voluntary departure (resignation with notice period)

You have time to plan. Use the notice period for phased access reduction: begin removing admin rights and non-essential system access gradually while the employee is still working. Don't disable core working access until the last day.

A practical schedule: week one of notice — remove elevated and admin privileges; final week — restrict to read-only on sensitive systems; final day — full deprovisioning. The advantage is that knowledge transfer can happen, passwords for shared accounts can be captured, and documentation can be written. The employee is generally cooperative.

Watch for: data exfiltration during the notice period increases significantly. Monitor for large file downloads, emails to personal accounts, unusual after-hours access, and unexpected large data transfers. This is not about distrust — it is standard security posture for anyone with a confirmed departure date. Revoke full access at end of last working day, or when they hand in equipment, whichever comes first.

Involuntary termination (redundancy, dismissal, layoff)

The access revocation window is minutes, not days. The IT team must act before or simultaneously with the employee being informed. If the employee still has system access when they receive the news, the risk window is open.

The practical protocol: HR notifies IT 15–30 minutes before the termination meeting. IT blocks sign-in and revokes sessions the moment the meeting begins. The employee should not be able to log in by the time they return to their desk. Collect equipment immediately — do not allow a dismissed employee to return to their desk unsupervised after being informed.

Mass layoffs require coordination: if 50 people are being let go simultaneously, IT needs automated tooling to revoke access at scale, not a manual click-through for each account.

Who Does What: HR, IT and the Manager

Most gaps sit between these three. HR knows the date but not the systems; IT knows the systems but not the date; the manager knows which tools the team really uses. A checklist that gives each of them their own tasks, with due dates counted from the same last day, closes those gaps.

Phase 1: Immediate Actions (Within the First Hour)

These steps must happen in the first 60 minutes regardless of departure type.

Phase 2: Identity & Access Revocation

With sign-in blocked and sessions revoked, the next phase is the systematic removal of access across all identity systems.

Directory services (AD / Entra ID / Okta / Google Workspace)

• Remove from all security groups and distribution lists — this removes access to shared mailboxes, SharePoint sites, Teams channels, and any group-based role assignments
• Remove all role assignments: check Azure AD roles, Okta group memberships, Google Workspace admin roles
• Remove from shared drives, shared mailboxes, and delegated access configurations
• Check for any guest account access (B2B invites) — these exist separately from the primary identity and are often missed

Microsoft 365 specific

• Convert the mailbox to a shared mailbox — preserves data without consuming a licence after the user licence is removed
• Remove all assigned licences including Copilot, Power Platform, and any add-ons
• Remove from all Teams channels, SharePoint sites, and OneDrive shared folders
• Review Power Automate flows owned by the user — flows break when their creator's account is disabled; reassign critical flows to a service account
• Review Copilot Studio agents if the employee created any — these can keep running after account deletion, accessing SharePoint data with no named owner (a 2026 blind spot most checklists miss)
• Submit a data subject request through Microsoft Purview if Copilot interaction history needs to be cleared (required under GDPR data minimisation)

Google Workspace specific

• Transfer ownership of all Google Drive content before the account is deleted — a deleted Google Workspace user can be restored for only 20 days
• Reset recovery email and phone to remove the employee's personal contact details
• Remove from Google Groups

VPN and remote access

• Revoke VPN certificates and remove VPN user from access lists — VPN clients often cache credentials locally, separate from directory
• Remove from any zero-trust network access (ZTNA) policies
• Delete remote desktop / RDP access permissions

Phase 3: SaaS Application Audit

This is where offboarding most commonly fails. Zylo's 2022 SaaS Management Index found the average company ran 323 SaaS applications, and IT directly managed only 23% of them. The rest — marketing tools, design platforms, project management apps, AI tools, developer utilities — are bought and run by business units, often with no IT visibility. Intermedia and Osterman Research found 89% of ex-employees retained access to at least one app.

Tier 1 — SSO-connected apps

When the IdP account is disabled, SSO-connected apps should refuse new logins. However: SCIM provisioning can take hours to propagate deactivation to downstream systems, and some apps cache sessions independently. Verify by checking each app's admin console directly, not just the IdP. High-priority SSO apps to verify explicitly: Salesforce, GitHub and GitLab, AWS / GCP / Azure, Slack and Microsoft Teams, Zendesk and Freshdesk, Jira and Linear, HubSpot and marketing platforms.

Tier 2 — Apps with local accounts bypassing SSO

These are the real risk. Even when SSO is enabled, many SaaS apps allow local login with an email and password as a fallback. The employee may have created an account before SSO was enforced, used a personal email address, or maintained a local password for convenience. Explicitly check and disable local accounts in: GitHub (check for personal accounts linked to org repos), AWS IAM console (IAM users are completely separate from SSO federation), Cloudflare and registrars, DNS providers, billing and payment platforms (Stripe, Paddle), and any tool where the employee held an admin role.

Tier 3 — Shadow IT (unknown apps)

Survey the manager and team about tools the employee used. Check expense reports for SaaS subscription charges. Review browser bookmarks if equipment is being returned. For high-risk departures, review SSO authentication logs for the past 90 days to see every app the user authenticated with — this gives you the most accurate access map of any approach available.

To run this phase for each leaver, with an app table, token revocation, data handover and licence reclaim in one record, use the free SaaS access offboarding checklist.

Phase 4: API Keys, Tokens & Privileged Credentials

This section often surprises non-technical managers: disabling an account does not revoke API tokens and keys. These are machine credentials that authenticate independently of the user's login session. If an employee created API keys, personal access tokens, or OAuth grants, those continue to work after the account is disabled unless explicitly revoked.

Personal access tokens (PATs)

GitHub, GitLab, Bitbucket, Jira, and most developer tools allow users to create PATs that authenticate API calls. These tokens never expire unless the creator sets an expiry date — and most don't. Revocation requires going into each platform's admin area and explicitly revoking each token. For GitHub, use the REST API to enumerate tokens owned by the user's account. For GitLab: Admin Area → Users → Access Tokens → revoke all. For Bitbucket: Admin → Users → App passwords → revoke.

SSH keys

SSH public keys registered in ~/.ssh/authorized_keys on servers, or in git hosting platforms, give direct shell access. They are completely unaffected by account disablement. Remove the employee's public key from authorized_keys on all servers they accessed. Check GitHub and GitLab admin user SSH key settings and remove. Review infrastructure automation tools — Ansible inventory files, Terraform state — for embedded keys.

AWS IAM access keys

AWS IAM users can have up to two long-lived access key pairs. These are completely independent of SSO federation and continue to work after the federated identity is disabled. Use aws iam list-access-keys --user-name [username] to find them, then aws iam delete-access-key to revoke. Also check IAM roles the user had permission to assume and any EC2 key pairs associated with the account.

OAuth grants and refresh tokens

When employees connect third-party apps to corporate systems, OAuth grants are created that persist beyond the user session. In Google Workspace: Admin Console → Security → API controls → App Access Control. In Microsoft 365: Entra ID → Enterprise Applications → review OAuth grants tied to the user.

Service accounts and shared credentials

If the employee created service accounts in their name, or knew passwords to shared accounts — database passwords, test environment credentials, shared admin accounts — rotate those immediately. Never assume the employee won't remember or reuse credentials they previously had access to.

Webhooks

Webhooks tied to a user's identity (Stripe, Segment, HubSpot) may use signing secrets that need to be rotated. If the employee managed integrations, audit and regenerate webhook secrets.

Phase 5: Device Recovery & Physical Access

Company-owned devices

Collect all hardware before the employee leaves the premises: laptop, mobile phone, tablet, hardware tokens (YubiKeys, RSA SecureID), USB drives, external drives, company-issued headsets and peripherals. Remote wipe via MDM (Microsoft Intune, Jamf, Workspace ONE) if equipment cannot be immediately retrieved — for remote employees, this is often the primary tool. For in-office employees: do not allow unsupervised return to desk after the termination meeting. Document serial numbers and asset tags at return, update the asset register, and wipe and reimage before reassignment.

Agree a return date with the leaver, check each item against the asset register when it comes back, and note any damage or missing kit in the offboarding record. A monthly IT asset management checklist then checks every leaver's returns against the register, so missing kit is chased while it can still be recovered.

BYOD (personal devices)

Personal devices hold corporate data but belong to the employee. Best practice: use MDM container or selective wipe to remove the corporate data container without touching personal data, revoke the device's MDM enrolment, and remove the corporate email profile. This should be covered in the employee's BYOD agreement signed at onboarding. In Capterra's 2022 survey, 71% of HR workers who offboarded someone in the past year had at least one leaver keep company equipment — a proactive asset register maintained throughout the employment lifecycle is the only reliable defence.

Physical access

• Deactivate access cards, key fobs, and building access codes immediately — this is often forgotten when the focus is on digital access
• Change any lock combinations or alarm codes the employee knew
• Retrieve any physical keys (server room, office, filing cabinets)
• Notify building security and reception to not admit the individual

Phase 6: Data Ownership Transfer

Departing employees often hold business-critical data in personal storage areas: Google Drive "My Drive", OneDrive, project repos, customer records. If not transferred before the account is deleted, this data can be lost permanently.

Email and calendar

• Convert mailbox to shared mailbox (Microsoft 365) or transfer to manager (Google Workspace) before removing licence — preserves access for continuity without consuming a licence
• Set up an out-of-office reply directing contact to the manager or designated successor
• Apply litigation hold if the employee's communications may be relevant to legal proceedings
• Google Workspace: use the data transfer tool to move Drive content and calendar ownership before account deletion

Files and documents

• Google Drive: use the admin data transfer tool to reassign all owned files to the manager
• OneDrive: grant manager access — Microsoft keeps a deleted user's OneDrive for 30 days by default (admins can change this), then 93 more days in a deleted state that only an admin can restore
• SharePoint sites where the employee was the only owner: assign a new owner before account deletion — ownerless SharePoint sites become inaccessible
• Shared Drives and SharePoint libraries are typically fine; personal drive content is the risk

Code and repos

• Transfer any GitHub or GitLab repos owned by the user to the organisation account (not another individual)
• Check for open PRs, active branches, and in-progress work — notify the team lead
• Check for CI/CD pipeline secrets stored in the user's personal space

Documentation and runbooks

• Ask the departing employee to document processes, credentials for shared accounts, and institutional knowledge during the notice period
• Confluence and Notion pages owned by the user: reassign or export
• Password manager entries: if the employee had entries for shared credentials (not personal), export and securely transfer those to the team vault

For regulated industries, data transfer must be logged. HIPAA requires documented evidence of who accessed what during the transfer process.

Phase 7: Email, Licensing & Post-Departure

Email continuation

• Set an auto-reply on the former employee's email for 30–90 days directing senders to the right contact
• Forward incoming emails to the manager or successor for business continuity
• Update any public-facing email addresses (website, LinkedIn company page, email signatures) that reference the departed employee

Licence reclamation

Every unused licence is wasted spend. Reclaim immediately after deprovisioning: Microsoft 365 and Google Workspace seats; Copilot, Power BI, and Power Apps add-on licences; Salesforce, HubSpot, and Zendesk seats; Adobe Creative Cloud; and any SaaS subscription associated with the user's email. Copilot licences alone run $30 or more per user per month — disciplined offboarding is often the fastest ROI in the process.

Post-departure audit (within two weeks)

• Run a SaaS discovery scan comparing the current access map against the offboarding checklist — any app that still shows the departed email address needs a manual revocation pass
• Verify all checklist items were completed; use the completed IT offboarding checklist as the audit evidence
• Confirm device has been wiped and asset register updated
• Update any documentation, runbooks, or system notes that named the departed employee as the owner or responsible party

Privileged & Admin Account Offboarding

Employees with admin-level access to cloud infrastructure, databases, or security tools require a separate protocol. The stakes are categorically higher.

What counts as privileged access: cloud infrastructure admin (AWS root or administrator, GCP Owner, Azure Owner); GitHub organisation owner or admin; Salesforce system admin; domain admin in Active Directory; Okta super admin; and any account with billing access, ability to create or delete users, or access to production data at scale.

Remote Employee Offboarding

Remote offboarding removes the ability to collect equipment in person, escort the employee from the premises, or verify the workspace. Everything must be done digitally — which requires specific adaptations.

• Device recovery: ship a prepaid return box as part of the offboarding workflow. Use MDM remote wipe (Intune, Jamf) as a backup if the device is not returned within the agreed window. Document the MDM wipe in the offboarding record.
• Access revocation: the same as in-office but with more emphasis on the API token and SSH key audit — remote employees are more likely to have personal development environments with embedded credentials.
• Physical access: you can't see the person remove their access badge or hand in their key. Triple-check physical access systems: did you deactivate their building access code even for a remote worker? If they ever visited the office, they may have an active access card.
• Knowledge transfer: more critical for remote employees who may have built processes, documentation, and tooling without colleagues seeing them work. Build document hand-off as a formal, assigned pre-departure task.
• Exit interview for IT: specifically ask remote employees about personal devices used for work, any accounts they created on personal email addresses, and any data stored locally that hasn't been synced to corporate systems.

Contractors, Shared Accounts and Role Changes

• Contractors and agency staff. Their end date sits in a contract IT may never see, so ask the engagement owner for it when the work starts. Remove guest accounts and sponsor links, recover company kit and get written confirmation that company data has been deleted from the contractor's own devices. For a supplier as a whole, use the vendor offboarding checklist.
• Shared accounts. A shared login has no single owner to disable. Rotate the password the day the leaver goes and move the account into a password vault with named users.
• Role changes. A move to another team is a partial offboarding: remove the access the old role needed before adding the new role's, or the person keeps both.

Common Mistakes That Create Security Incidents

Compliance & Audit Trail Requirements

SOC 2 and ISO 27001 auditors use a consistent approach: they sample five ex-employees from the past 12 months and request evidence that access was revoked within the required timeframe. For each sampled employee they want:

• A timestamped access revocation log showing when the account was disabled
• Confirmation that licences were removed (proves no ongoing access to licensed tools)
• Device return or MDM wipe confirmation
• A completed offboarding checklist with named assignees and completion timestamps

If you can't produce these four items for each sampled employee, you have a finding. The finding is usually moderate for the first occurrence, significant if it's systemic.

SOC 2 (CC6.2 / CC6.3)

Access changes must be documented. CC6.2 and CC6.3 require access to be removed when it is no longer needed; the criteria set no hour count, but auditors commonly expect access to be revoked within 24 hours of departure.

ISO 27001 (Annex A 5.11, 5.18 and 6.5)

Annex A 5.11 covers the return of assets and 5.18 the removal of access rights; 6.5 covers the duties, such as confidentiality, that still apply after someone leaves. The policy must exist in writing and evidence of it being followed must be producible on request.

NIST SP 800-171 (3.9.2)

Used primarily by US defence contractors and federal suppliers. Requirement 3.9.2 asks you to protect systems that hold CUI during and after terminations and transfers: close accounts, recover property such as tokens and badges, and change access when someone moves role.

When each offboarding run is tracked as a CheckFlow IT offboarding checklist, the completion record automatically includes task name, who completed it, and timestamp. Print the completed checklist or save it as a PDF, or export checklist and task data, and auditors get a dated record of each step — no post-hoc reconstruction needed.

Free IT Offboarding Templates

CheckFlow includes ready-to-use offboarding and IT process templates — free to try, fully customisable, and designed to run as live checklists with task assignments, due dates, and completion tracking. The templates below are built for IT and security teams and can be launched immediately from the CheckFlow IT template library.

IT Offboarding Checklist

SaaS Access Offboarding Checklist

Remote Employee Offboarding Checklist

Employee Offboarding Checklist

Active Directory Cleanup Checklist

User Access Review Checklist

How CheckFlow Supports IT Offboarding

The root cause of most offboarding security failures is the same: no structured, enforced process that every team member follows every time, regardless of who's handling the offboarding. The senior engineer knows to check for IAM keys. The junior tech doesn't. A checklist removes that knowledge dependency entirely — the process carries the quality standard, not the individual running it.

CheckFlow is purpose-built for running the same process repeatedly with assigned tasks, due dates and automatic completion records. When an IT offboarding checklist is launched, every task is assigned to the right person, with a due date. A step can halt the checklist, so nothing after it can be ticked until it is done, and the cut-off task can be assigned to the IT owner alone; the completion record exists automatically. The Reports Grid shows every open offboarding across the organisation, live — no chasing for status updates. For teams using Zapier or API integrations, a new HR leaver ticket can auto-launch the offboarding checklist with employee name, department, departure date, and manager pre-filled from the HR system. The IT team doesn't even need to start it — the process starts itself.

For MSPs managing offboarding for multiple clients, CheckFlow handles concurrent offboardings — ten clients' departing employees can all have live offboarding checklists running simultaneously, each with their own assignees and timelines, all visible in the Reports Grid. This is the use case that spreadsheets and PSA tickets fundamentally can't match at scale. When a whole client ends its contract with you, the checklist for when a client leaves your MSP covers handing back admin rights, domains and licences and removing your own tools.

Conclusion

IT offboarding is a security control, not a farewell ceremony. The seven-phase structure covered in this guide — immediate access block, identity revocation, SaaS audit, API and token cleanup, device recovery, data transfer, and post-departure tasks — is what complete offboarding looks like in practice. A structured, assigned checklist is the only reliable way to ensure all 40-plus steps happen every time, regardless of who's handling it.

The organisations that pass SOC 2, ISO 27001, and NIST audits without drama aren't working harder — they're running the same rigorous process every time an employee leaves, and the audit evidence is already there when the auditor asks for it. A verifiable, timestamped offboarding record isn't an administrative overhead; it's the proof that your security controls are operational, not just documented.

Frequently Asked Questions