How to Offboard an Employee Across Every SaaS App (2026 Checklist)

A practical 21-step guide for IT operators: how to offboard an employee from every SaaS app, including the apps without APIs or SCIM. Checklist, common gaps, and how to automate it.

It's 5:07pm on a Friday. Your phone buzzes. The message is from your CEO: "Hey, [Name] just quit. Effective now."

You open your laptop and start the mental inventory. Google Workspace — that's the easy one. Slack. GitHub. Jira. Salesforce. The password manager. That AWS IAM user you created six months ago when they joined the security review rotation. Figma — wait, are we on the Business plan that supports SCIM or the Professional plan that doesn't? Notion — how do you even deactivate someone in Notion?

By 6pm you've hit 12 apps. You're pretty sure there are 19 active apps in total. You're not sure you have the right number, because the access map lives in a Notion doc three months out of date.

This is the standard offboarding experience at a 100–500 employee company in 2026. It's not a failure of diligence — it's a systems problem. Most teams weren't built for this.

This guide gives you the full 21-step process: what to do, in what order, and what to do about the apps that don't have proper APIs.

The direct answer (if you need it fast)

Employee SaaS offboarding requires three things in sequence: (1) a single authoritative trigger — ideally your HR system, not an email from a manager; (2) parallel revocation across every app, including the ~40% of mid-market stacks that don't support SCIM or have no provisioning API at all (industry research figure — not specific to any one company); and (3) signed, timestamped evidence per app for your audit trail. Manual offboarding fails past roughly 100 employees because step two stops scaling. Industry research puts the median time between an employee's departure and full access revocation at around 11 days for companies relying on manual processes. Automated platforms run end-to-end in under 60 seconds.

The 21-step checklist below walks through the full process. Jump to Phase 4 — The Apps Everyone Forgets if you already have the fundamentals and just need the gap list.

Phase 1 — Before the last day (2–5 days prior when you have notice)

Most offboarding gaps start before the last day because nobody audits access proactively. These four steps change that.

Step 1: Get the termination from the system of record, not from a Slack message

The trigger should come from your HR system — not from a manager's DM, not from a Calendar invite, not from a rumour. HR is the only system where departure dates, effective timestamps, and legal names are consistently accurate and auditable. If you're relying on forwarded emails to kick off offboarding, you'll miss people, get dates wrong, and have nothing to show an auditor.

If your HR system doesn't send lifecycle events automatically, you need a manual intake form with: legal name, employee ID, final day (date + time), manager, and role. That's the minimum to run the process correctly.

Step 2: Pull a full access audit before the last day

Before you revoke anything, know what you're revoking. Every IT operator has experienced the post-offboarding discovery — three weeks later, someone finds the former employee still has access to the staging database because it was under a team account nobody mapped.

The audit doesn't have to be exhaustive. You need four things:

• Every active SaaS subscription tied to this person (pull from your provisioning records, or from your SSO provider's active-user list if you have one)
• Every API key, personal access token, or service account issued in their name
• Any admin-level access — in any tool — that gives them elevated permissions
• Any company-owned credential stored in a password manager under their profile

If you don't have a current access map, now is the time to build one. It doesn't need to be perfect. It needs to exist.

Step 3: Identify the tools that require manual action before the last day

Some offboarding steps can't wait until the last minute: transferring ownership of critical accounts, rotating shared credentials, reassigning open customer tickets. Do these ahead of the last day so nothing breaks the moment access is revoked.

Common examples:

• Transferring GitHub org ownership if they were the primary owner of repos or teams
• Rotating any AWS keys or GCP service accounts they created under their own identity
• Reassigning open support tickets so customer threads don't go dark
• Downloading any data they've stored in personal-directory cloud storage before the account is disabled

Step 4: Set the exact revocation window

For most roles: revocation within 24 hours of the HR termination event is a reasonable SLA. For admin and privileged access (cloud consoles, production databases, security tools): revocation within 1 hour, ideally at the same moment as departure.

Write the SLA into your process. "We'll get to it" is not a security posture.

Phase 2 — The primary identity (do this first, it cascades)

Step 5: Disable the primary identity provider account

If you use an IdP — Microsoft Entra ID, Okta, JumpCloud — disabling the user there will cascade access revocation to every app connected via SAML or SCIM. This is the highest-leverage single action in the entire process.

Do this first. Not second. Not "once you've told everyone." First.

If you don't have an IdP, go straight to Step 6.

Important: "disabled" is not the same as "deleted." Disable first. Give yourself 30 days before deletion. You may need to recover data, inspect audit logs, or respond to an HR investigation. Deletion is permanent.

Step 6: Disable the primary email account (Google Workspace or Microsoft 365)

If you're not using an IdP, the primary email account is usually your highest-leverage action. Disabling it kills access to every app that uses that email address for sign-in via "Sign in with Google" or "Sign in with Microsoft."

After disabling:

• Set up an auto-reply or mail forwarding to their manager for any inbound mail during the transition period
• Don't delete the mailbox. Archive it. You'll need it for compliance, customer communication threads, or litigation hold.
• If they had any email aliases shared with team distribution lists, update those now.

Phase 3 — Every app in the stack (work the list systematically)

This phase is where manual offboarding breaks down. At 20 apps, doing this by hand takes 60–90 minutes of active work across multiple admin consoles. At 30+ apps, it takes most of a day — if you remember all of them.

Work through these in order of blast radius (highest-risk access first, lowest last).

Step 7: Revoke cloud infrastructure access

AWS IAM users, GCP IAM roles, Azure AD users — anything that touches production or customer data. This is the highest-risk access most IT operators underestimate.

Check for: IAM users, access key IDs, role bindings, service accounts, and any MFA devices registered under their email. Rotate the keys, don't just delete the user — some services may be polling using those keys.

Step 8: Revoke GitHub / GitLab / Bitbucket

Remove from the organisation. Remove from every team inside the organisation. Check for:

• Personal access tokens they issued (Settings → Developer Settings → PATs) — these survive org removal
• SSH keys registered under their account
• Any deploy keys tied to repos they owned
• OAuth apps they authorised that may have write access to org repos

The PAT step gets missed more than any other in GitHub offboarding. See our detailed GitHub offboarding guide for the exact steps.

Step 9: Revoke Slack

Deactivate, don't delete. Deactivated users can't log in; their message history is preserved for the team. Deletion removes the history — in most cases that's the wrong call.

After deactivation:

• Reassign any Slack workflows they owned
• Transfer ownership of any private channels that only they could see

Step 10: Revoke project management tools (Jira, Asana, Linear, Trello, etc.)

Deactivate or remove from the workspace. Before you do:

• Reassign any open issues, tasks, or tickets assigned to them
• Check if they were an admin (in Jira: check Global Permissions)

Step 11: Revoke CRM and sales tools (Salesforce, HubSpot, Pipedrive, etc.)

Deactivate the user. Do not delete — historical activity data, opportunity ownership, and email log history live on the user record. Deactivation removes login; the record stays for reporting.

If they owned open opportunities, reassign before deactivation.

Step 12: Revoke support tools (Zendesk, Freshdesk, Intercom, ServiceNow)

Deactivate and reassign any open tickets. Check if they were an agent with elevated permissions (e.g., full ticket deletion rights in Zendesk) — log the permission level before removal for audit purposes.

Step 13: Revoke Zoom

Admin console → User Management → remove or deactivate. If they had a Zoom Phone number, transfer it.

Step 14: Revoke the password manager (1Password, Bitwarden, LastPass, etc.)

Remove from the team vault. This one matters: if they had access to shared vaults with production credentials, rotate anything sensitive they could see. You don't know what they may have copied before their last day.

Don't just remove access — review what they had access to and make a rotation decision for the high-value items.

Step 15: Revoke cloud storage (Dropbox Business, Box, SharePoint, Google Drive shared drives)

Transfer ownership of any files they owned. Deactivate the account.

The Google Drive case is worth specific attention: a user's "My Drive" is personal but synced to Google infrastructure. Their shared drives are collaborative. Disable the account via Workspace Admin → it kills access to shared drives automatically, but their personal My Drive content becomes orphaned. Use the Data Transfer feature to move it to a manager's account before deletion.

Phase 4 — The apps everyone forgets

This is where the 11-day median offboarding lag actually comes from. Not the obvious apps — those are usually handled. The gap is the long tail of tools that don't have SCIM, don't have provisioning APIs, and don't cascade from your IdP.

Industry research suggests roughly 40% of mid-market SaaS stacks fall into this category. They require direct admin console access per app, per user. Nobody automates them. So they don't get done.

The most common offenders:

Step 16: Adobe Creative Cloud / Adobe Admin Console

Adobe's provisioning API is only available on enterprise tier contracts. Most mid-market companies are on Team or Business plans — no API, no SCIM. You have to log into the Admin Console manually, navigate to Users, and remove them per product (Photoshop, Illustrator, Acrobat, Premiere — separately).

This takes longer than it should, and it's missed in almost every manual offboarding.

Step 17: Figma

Figma supports SCIM on Organization and Enterprise plans. On Professional, you're in the admin panel manually. Remove them from the organisation and from every team they're a member of. Check if they have any published libraries or design systems tied to their personal account — those need to be transferred before removal.

Step 18: Notion

Workspace admin → Members → Remove. Notion doesn't cascade from your IdP unless you've set up a SAML SSO connection. Check which pages they're the direct owner of — those need to be transferred to another member first.

Step 19: Loom, Miro, Canva, and other collaboration tools

Same pattern: admin console, manual removal. Check for:

• Loom: any team videos they own should be transferred to a shared space
• Miro: boards they created may be workspace-accessible or personal; transfer the personal ones
• Canva for Teams: remove from the team. Designs stay in the workspace.

Step 20: Revoke OAuth grants and third-party app authorisations

This one is almost never done manually — and it's arguably the highest-risk gap. When a user authorises a third-party app ("Sign in with Google" or "Authorize this GitHub app"), that OAuth grant persists even after you disable their primary account, in many cases.

For Google: Admin Console → Security → API Controls → App access control. Review the authorised apps tied to their account and revoke third-party access for high-risk apps.

For GitHub: even after org removal, any OAuth apps they authorised retain the access token until the user revokes it or the token expires.

Phase 5 — Evidence and closure

Step 21: Collect and sign the evidence

Every step above should generate a record: who did it, what they revoked, when, and the before/after state where applicable. For a SOC 2 CC6.3 audit, you need to demonstrate that every account created in the audit period was matched by a termination event. If you can't produce evidence of revocation per app, the auditor will ask why.

At minimum: a timestamped log entry per app revoked, with the admin who performed the action. Ideally: a screenshot or API response confirming the account state post-revocation.

How long should this take, honestly?

Manual: 60–90 minutes for a clean offboarding across 20 apps, assuming you have an up-to-date access map. Longer if you're hunting down what the person actually had access to. Add another hour if they had cloud infrastructure access that needs key rotation.

Automated: under 60 seconds for a full revocation across the same 20 apps, running in parallel, with signed evidence per action. KINT runs a full offboarding in 47 seconds end-to-end — HR event to signed evidence packet — processing 6+ apps simultaneously.

The 11-day industry median isn't because IT operators are slow. It's because the manual process doesn't scale, the access map is always stale, and the apps without SCIM never get done on time.

How to automate SaaS offboarding

If you're doing this manually today, the ROI case for automation is straightforward: every offboarding takes 60–90 minutes of skilled IT time. At 5 employees off per month, that's 7–8 hours per month on a process that should take zero active time. At 20 employees off per month, it's a part-time job.

The automatable parts:

• Trigger from HR: your HR system (BambooHR, Workday, Rippling, Darwinbox, Keka, HiBob) sends a termination event → workflow fires automatically
• SCIM and API apps: revoked in parallel, not sequentially
• Browser-automation apps (Adobe, Figma on lower tiers, Notion, Loom): handled by deterministic browser flows that log into the admin console and perform the same steps you'd do manually — but at machine speed and with signed evidence
• Evidence collection: every action timestamped, signed, and mapped to your SOC 2 CC6 controls automatically

KINT runs this workflow for IT teams at 100–500 employee companies. Self-serve signup, OAuth setup in under five minutes, 14-day free trial — no card required. If you want to see it on your own stack before committing to anything, start here.

Checklist summary (all 21 steps)

Phase 1 — Pre-termination

• 1. Get the termination from the system of record (HR, not Slack)
• 2. Pull a full access audit before the last day
• 3. Identify pre-last-day transfers (ownership, credentials, tickets)
• 4. Set the revocation SLA (24h standard, 1h for privileged access)

Phase 2 — Primary identity

• 5. Disable the IdP account (if applicable) — cascades to SAML/SCIM apps
• 6. Disable the primary email account (Google Workspace or Microsoft 365)

Phase 3 — The app stack

• 7. Cloud infrastructure (AWS IAM, GCP, Azure) — rotate keys, revoke roles
• 8. GitHub / GitLab / Bitbucket — org removal, PATs, SSH keys, deploy keys
• 9. Slack — deactivate (not delete), reassign workflows and channels
• 10. Project management (Jira, Asana, Linear) — deactivate, reassign issues
• 11. CRM (Salesforce, HubSpot) — deactivate (not delete), reassign open deals
• 12. Support tools (Zendesk, Freshdesk) — deactivate, reassign tickets
• 13. Zoom — deactivate, transfer phone number if applicable
• 14. Password manager — remove from vaults, rotate shared credentials
• 15. Cloud storage (Dropbox, Box, Google Drive shared drives) — transfer ownership, deactivate

Phase 4 — Apps everyone forgets

• 16. Adobe Creative Cloud — Admin Console manual removal per product
• 17. Figma — org removal, team membership, library transfer
• 18. Notion — workspace removal, page ownership transfer
• 19. Loom, Miro, Canva — admin console removal, asset transfer
• 20. OAuth grants and third-party app authorisations — revoke per platform

Phase 5 — Evidence

• 21. Collect and sign the evidence — timestamped log per app, mapped to SOC 2 CC6.3

Frequently asked questions

How long should employee SaaS offboarding take? Manual offboarding across a 20-app stack typically takes 60–90 minutes if you have an accurate access map. Fully automated, the same process completes in under 60 seconds. Industry research puts the median lag between departure and full access revocation at around 11 days for teams relying on manual processes — most of that delay is the browser-only apps nobody automates.

What's the difference between offboarding and deprovisioning? Offboarding is the full exit process — equipment return, knowledge transfer, HR paperwork, and access revocation. Deprovisioning is specifically the access revocation step: removing a user's credentials, permissions, and tokens from every app. This guide covers deprovisioning in detail; the broader offboarding process is owned jointly by HR and IT.

Does revoking Google Workspace access automatically remove someone from all apps? Only for apps connected via SAML or Google SSO. If someone signed into Notion with "Sign in with Google," disabling their Workspace account will eventually block that login — but not immediately in all cases, and not for apps they access via saved passwords or direct credentials. The OAuth grants themselves may also persist. Disabling Workspace is the first step, not the last.

Do you need an identity provider to automate offboarding? No. An IdP (Okta, Entra, JumpCloud) helps — it cascades SCIM-connected apps automatically. But you don't need one to automate offboarding. HR-driven lifecycle platforms like KINT read events directly from your HR system and act on apps independently of whether you have an IdP. If you do have an IdP, KINT runs alongside it and covers the ~40% of apps your IdP can't reach (industry research figure).

What are the apps most commonly missed during SaaS offboarding? The apps that require manual admin console access because they don't support SCIM on lower pricing tiers: Adobe Creative Cloud (Team plan), Figma (Professional plan), Notion (without SSO), Canva for Teams, Loom, and Miro. Cloud infrastructure — specifically GitHub PATs, AWS access keys, and GCP service accounts — also gets missed because they survive IdP account deletion.

What's the right SLA for revoking access after someone leaves? For standard accounts: full revocation within 24 hours of the HR termination event. For privileged or admin access (production database, cloud console, security tools): within 1 hour, ideally simultaneously with departure. For SOC 2 CC6.3, you need to document the SLA and show that your actual revocation timestamps fall within it.

How should you handle offboarding when someone leaves immediately, without notice? The same process, compressed. Steps 1–6 happen in the first 10 minutes. The rest follow in order of blast radius: cloud infrastructure, then development tools, then communication tools, then everything else. The hardest part is the access map — if you don't have one already, you're building it under time pressure. This is the strongest argument for maintaining a live access inventory rather than auditing reactively.

How is contractor offboarding different from employee offboarding? Contractors often have narrower access scopes — one project, one repo, one system — which makes offboarding simpler. But they also more commonly use personal credentials (personal GitHub accounts added to the org, personal email for tool sign-in) rather than company-provisioned identity. The revocation steps are the same; the discovery step is harder because access may not be in your HR system or SSO directory.

Should you delete or deactivate accounts? Deactivate first, delete later — after 30–90 days. Deletion is permanent. Deactivation removes access while preserving the account record, message history, ticket history, and any data associated with the user. Most compliance frameworks (SOC 2, ISO 27001) require you to be able to produce historical access evidence; deletion makes that harder. Set a calendar reminder to delete 30–90 days post-departure.

What evidence do you need to collect for SOC 2 during offboarding? SOC 2 CC6.3 requires evidence that access was removed when no longer needed. For each termination: the HR event with effective timestamp, the revocation action per app (admin logs, API responses, or screenshots), and the timestamp of each revocation. If you're using an automated platform, it should produce this evidence automatically and map it to CC6.1/CC6.2/CC6.3. See our SOC 2 access review checklist for the full CC6 mapping.

What happens if you find an app with lingering access weeks after offboarding? Revoke immediately, document the gap, and find the root cause. The gap is almost always one of three things: the app wasn't in your access inventory, the app doesn't have SCIM and wasn't in your manual checklist, or the step was done but not verified. Treat each discovery as a process improvement — add the app to the inventory, add it to the checklist, and consider whether automation would have caught it.

How do you offboard someone who was an admin on multiple tools? In order of blast radius. Cloud infrastructure first. Then development tools. Then everything else. Admin accounts have elevated blast radius if they remain active — a former employee with admin on your Salesforce instance can extract the full CRM, modify records, or delete data. Prioritise admin access over standard user access, and document all admin-level access in your pre-departure audit (Step 2 above).

Related reading: The 11-Day Offboarding Lag — What Causes It and How to Close It · How to Remove an Ex-Employee's GitHub Access · SOC 2 CC6 for IT Operators