IT Offboarding Checklist: The Complete Security Guide (2026)

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 2023 study by Beyond Identity found that 89% of former employees still had access to at least one corporate application after leaving. Ponemon Institute 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.

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:

• 59% of companies have experienced a data breach attributable to poor offboarding
• 89% of ex-employees retained access to at least one app (Beyond Identity 2023)
• 720% spike in data exfiltration activity in the days before a layoff announcement (Cyberhaven 2024) — employees often have advance knowledge before the news is public
• Average enterprise manages approximately 275 SaaS applications (Zylo) — IT directly controls only about 16% of them through the corporate IdP
• 71% of organisations have no formal offboarding process
• 41% of companies fail to collect all devices during offboarding (Capterra)
• The average time between an employee's departure and access revocation is over 3 days when offboarding is handled manually

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.

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 account suspension — Google retains Drive data for 30 days post-deletion if not transferred
• 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. The average enterprise manages approximately 275 SaaS applications (Zylo). IT directly controls only about 16% of them through the corporate IdP. The remaining 84% — marketing tools, design platforms, project management apps, AI tools, developer utilities — are purchased and used by business units with no IT visibility. A 2023 Beyond Identity study found 89% of ex-employees retained access to at least one app, and 43% of businesses may have ex-employees still accessing code repositories.

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.

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.

BYOD (personal devices)

More than 80% of organisations allow BYOD (JumpCloud data). 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. 41% of companies fail to collect all devices during offboarding (Capterra) — 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 retains content for 30 days after account deletion; 93 days in some configurations
• 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.

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. Auditors expect access to be revoked within 24 hours of departure as a reasonable control. CC6.3 specifically requires that access is revoked when employment ends.

ISO 27001 (Annex A 6.5)

Requires formal policies for access revocation and asset return on termination. The policy must exist in writing and evidence of it being followed must be producible on request.

NIST SP 800-171 (3.1.1 / 3.1.2)

Used primarily by US defence contractors and federal suppliers. Requires immediate account closure on departure and a formal review of access rights.

When each offboarding run is tracked as a CheckFlow IT offboarding checklist, the completion record automatically includes task name, who completed it, and timestamp. Export the completed checklist as PDF or JSON and it satisfies the documentation requirement for all three frameworks — 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.

Employee Offboarding Checklist

Employee Onboarding

IT Support Checklist

IT Change Management Process

Disaster Recovery Audit

Incident Management Process

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, enforced order, and automatic completion records. When an IT offboarding checklist is launched, every task is assigned to the right person, with a due date. Nothing is skippable; nothing is done out of order; the completion record exists automatically. The real-time dashboard shows every active offboarding across the organisation simultaneously — 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 on a single dashboard. This is the use case that spreadsheets and PSA tickets fundamentally can't match at scale.

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