Secure SaaS Offboarding Checklist

Disabling an identity account is a critical first step, but many organizations stop there and leave significant risk behind. The parts that create long-lived exposure are often the ones SSO doesn't touch: existing browser sessions that remain active, direct SaaS logins that bypass the IdP entirely, API keys and personal access tokens, OAuth consent grants that third-party apps still hold, shared admin accounts the departing user knew, and billing ownership that routes invoices to a departed employee.

The gap between "account disabled in the IdP" and "all access actually removed" is where most SaaS offboarding failures live. An attacker who compromises an orphaned session or a forgotten API token has the same access as the employee who created it. A secure offboarding process verifies cleanup inside the apps that matter, not just at the identity layer. See our SaaS sprawl governance and onboarding and offboarding playbook guides for the broader context.

Before you start removing access, you need to know what access exists. Pull app assignments from the identity provider and any SSO portal to get the known list. Then go deeper: search for shadow IT by looking at expense reports for SaaS subscriptions, checking email for trial invitations and "welcome" messages, and asking department heads what tools their teams use that IT might not manage. This inventory work is the foundation that makes the rest of the process reliable.

Build an ownership map for the departing user. List which apps they own, administer, or pay for. Identify integrations they set up: automation workflows in Zapier or Power Automate, API keys in developer consoles, and third-party OAuth connections in Slack, Microsoft Teams, or Google Workspace. When the only admin for a critical SaaS app leaves without a documented ownership transfer, the result is often a scramble to regain control through vendor support.

Related: RBAC and data classification.

Use this checklist as a baseline and tailor it to your stack. If you want the fastest leverage, focus on privileged users and high-risk SaaS apps first. The checklist covers five areas: identity provider actions, SaaS app actions, ownership and continuity, shared credentials, and verification.

# Secure SaaS Offboarding Checklist (SMB)

## A) Identity (IdP) actions
- [ ] Disable or suspend primary account
- [ ] Revoke sessions / force sign-out
- [ ] Remove from privileged roles and high-risk groups
- [ ] Confirm MFA recovery and break-glass accounts are not tied to this user

## B) SaaS app actions
- [ ] Disable or suspend user in each high-risk SaaS app (not just SSO)
- [ ] Remove user from app roles (admin, billing, integrations)
- [ ] Revoke API tokens and personal keys
- [ ] Remove OAuth grants / third-party consents created by the user

## C) Ownership + continuity
- [ ] Transfer app ownership and admin responsibility
- [ ] Transfer data ownership (files, projects, dashboards) or archive per policy
- [ ] Update billing contacts and invoice destinations

## D) Shared credentials + secrets
- [ ] Rotate shared passwords and keys the user knew
- [ ] Remove the user from password vaults and shared secret stores

## E) Verification + evidence
- [ ] Record ticket ID, completion timestamp, and approver
- [ ] Attach export/screenshots of access removal where practical
- [ ] Schedule a 30-day follow-up to confirm no unexpected reactivation

Related: Multi-Factor Authentication (MFA) and conditional access.

Data handoff is where offboarding intersects with data governance. Transfer ownership for key apps before the last day when possible, so the departing user can walk a successor through where things live. Archive or export critical data for continuity and in case future investigations need it. Align retention and access decisions to your data classification policy and any contractual requirements that apply to the data the departing user handled.

Be deliberate about what data the departing user takes with them. Personal devices may have cached files, downloaded attachments, or synced folders that contain business data. Revoke sync access and, where appropriate, issue a remote wipe. This isn't about distrust, it's about closing the data access loop the same way you close the account access loop.

Related: DLP and secure email archiving.

A secure process is repeatable and reviewable. The goal is not paperwork for its own sake, it is being able to show access was removed and why decisions were made. Keep a ticket with the ID of who approved the offboarding, what was done, and when. Retain identity and admin activity logs long enough to investigate if something surfaces later.

Schedule a 30-day follow-up check. This catches reactivated accounts, missed SaaS apps, and shared credentials that weren't rotated. It also catches the case where someone re-enabled access "temporarily" during the departure and forgot to clean it up. A brief follow-up check turns a point-in-time process into ongoing assurance.

Related: POA&M.

SaaS offboarding is part of the broader access lifecycle. Our onboarding and offboarding playbook covers the end-to-end joiner/mover/leaver process including devices and identity. SaaS sprawl governance addresses the discovery and management problem that makes offboarding harder than it needs to be.

RBAC and conditional access provide the policy enforcement layer that limits what departing users can do even before explicit offboarding happens. MFA protects against credential reuse by requiring a second factor the departing user controls. Together, these controls create defense in depth: role-based restrictions limit exposure, conditional access blocks risky sessions, MFA prevents credential-only access, and offboarding removes it all.