How to Build a SaaS Offboarding Checklist That Actually Closes Every Access Path

Most organizations have an offboarding checklist. Most checklists end at the identity provider — the departing employee's account is disabled, password reset, and the laptop collected. The work done is real and necessary, but it is also incomplete. A meaningful share of the access an employee accumulated during their tenure does not live inside the identity provider at all, and is therefore unaffected by the standard procedure.

This guide describes an offboarding framework designed to close every remaining access path, organized around the categories of access that the standard process fails to address.

Category one: federated SaaS via SCIM and SSO

For applications connected to the identity provider via SCIM and SAML, the standard procedure is generally adequate. Disabling the user in the IdP triggers a deprovisioning event downstream, and access terminates within a defined window. Validate that the SCIM provisioning logs confirm deprovisioning in each application within 24 hours of the IdP change. Capture the timestamps as evidence for compliance review.

Category two: applications with SSO but no SCIM

A surprisingly large set of business applications support SAML or OIDC authentication but do not provision and deprovision users automatically. After IdP deactivation, the user can no longer log in, but the user object inside the application persists. License consumption continues, shared content remains under their ownership, and re-enabling the IdP account would restore access without any further review. Maintain a list of these applications and explicitly deprovision the user inside each one as part of the offboarding workflow.

Category three: unmanaged accounts created with corporate identity

The most consequential category is the long tail of SaaS accounts that the employee created independently, using their corporate email address, often via "Sign in with Google" or the Microsoft equivalent. These accounts do not appear in the identity provider, do not appear in procurement, and survive offboarding intact. The data within them — exported reports, customer correspondence, source code in private repositories — survives with them. Shadow SaaS is fundamentally an identity problem, and offboarding is where that thesis becomes operational.

Category four: OAuth grants the employee consented to

Every OAuth grant authorized by the departing employee remains active after their account is disabled — and in some configurations, an OAuth refresh token continues to issue new access tokens even when the user can no longer authenticate interactively. Review the OAuth grant list filtered to the employee's account in Google Workspace and Microsoft 365 and revoke each grant explicitly. Couple this with a session revocation operation so that no resumed sessions persist.

Category five: shared credentials, service accounts, and rotation

Service accounts, password-vault entries, and shared credentials are often the most overlooked category. If the departing employee had access to any vault, treat each shared item as compromised on departure and schedule rotation within the offboarding ticket. Where the employee owned service accounts, transfer ownership and rotate credentials. Where they had administrative access to CI/CD or cloud consoles, ensure their cloud IAM entries are also explicitly removed; federated logins terminate at the IdP, but direct console users with separate passwords do not.

Category six: mailbox and inbox forwarding

Inspect the departing employee's mailbox for forwarding rules established during employment, particularly to external addresses. Address handover and transition plans frequently establish such rules; many are forgotten. Disable forwarding, archive or transfer the mailbox per legal hold requirements, and confirm with the manager that any necessary inbox content has been preserved.

Documenting the audit trail

Each step above produces evidence that should be retained for compliance and dispute purposes. Recognized standards such as ISO/IEC 27001, AICPA SOC 2, and the NIST Cybersecurity Framework 2.0 all require evidence of timely access revocation; an offboarding ticket containing only an IdP timestamp is generally insufficient under modern auditor expectations. Every SaaS breach is, at root, an identity failure, and offboarding evidence is the most common artifact regulators request to evaluate that posture.

Automating the long tail

Categories three and four — unmanaged SaaS accounts and OAuth grants — are the categories most resistant to manual workflow. Their existence is not obvious until they are discovered, and the discovery has to happen continuously rather than at the moment of departure. Waldo Security's Employee Offboarding performs this discovery on an ongoing basis and produces a list of every account and grant tied to a departing employee, with the actions required to close each one.

If you would like to compare your current offboarding completeness against a continuously discovered baseline, a demonstration can be arranged.