Back to the blog

A SaaS offboarding checklist: 8 best practices to try

Eight steps to ensure complete employee offboarding for SaaS and cloud accounts, including the OAuth grants, resources, and passwords you’re most likely forgetting.

Employee offboarding is the worst. Just ask anybody who’s been tasked with this tedious and thankless responsibility. The process sits at the center of a venn diagram of manual, time-consuming, essential, and urgent work. That’s not to mention that the task often arrives without warning, easily eats up hours, and often feels vexingly incomplete.

Of course, much of the procedural tedium of employee offboarding can’t be automated or simplified. Internal communication needs to be managed, exit interviews completed, paychecks issued, hardware and badges returned. It’s an uncomplicated (if unpleasant) list of jobs to be done. But when it comes to managing the IT footprint of a departing employee, or SaaS offboarding, things get murky.

First, what is SaaS offboarding?

SaaS offboarding is the process of securely deactivating and removing user access from applications and platforms when an employee or client leaves the company or no longer requires the service. It typically involves tasks like transferring data, revoking permissions, and ensuring compliance with security and privacy standards.

In this age of SaaS, technology adoption is frequently employee-led. So the first challenge (and it’s a big one) is figuring out what accounts exist to begin with. Sure, there are the ones IT already knows about, and those enrolled in SSO, but what about the shadow IT—the free accounts, the one-offs, the forgotten experiments? Our research shows that at an org with 1,000 employees, a new SaaS account is created roughly every 20 minutes. Indeed, for our customers, the average number of accounts per employee is 31. Tracking these accounts down can start to feel like the world’s worst scavenger hunt.

Once you’ve identified all of these accounts, deeper questions emerge: Which accounts are accessed outside of SSO or OAuth? Which ones are integrated with other SaaS applications? And which resources are in danger of becoming entirely inaccessible if not properly transferred first? 

Our employee offboarding checklist covers precisely this murky territory of offboarding SaaS access—a land of common pitfalls, missteps, and missed steps. Read on for our eight essential steps of employee IT offboarding, fine-tuned to ensure business continuity and data security in our increasingly remote, distributed, SaaS-first world of work. 

Need a handy checklist to track your progress? Download our spreadsheet!

1. Prevent the employee from accessing their Google Workspace or Microsoft 365 account.

Your first priority should be to revoke the former employee’s access to their email account by resetting their passwords and turning off any recovery methods the employee had set up, such as a secondary personal email address or mobile number. However, do not suspend or delete the account yet. In order to complete subsequent offboarding steps, the account must remain active and accessible for admins.

Review the following instructions to complete this step:

2. Transfer ownership of critical resources.

We define “critical resources” as accounts that could become orphaned or inaccessible after a user’s account is disabled. These include primary account holders for social media handles, domain owners, workspace administrators, and root users for AWS accounts.

To avoid any business disruption, it’s essential to first transfer ownership of these resources to the appropriate individuals before you revoke access to the former employee’s accounts.

3. Review and update app-to-app integrations.

OAuth grants are frequently used to power automated actions across apps. (For instance, an application like Atlassian may use an OAuth grant to sync employees from Google Workspace.) To ensure that no automated processes are disrupted, it’s important to review any OAuth grants a former employee created that have permissions to perform additional actions above and beyond signing into a given app. 

For each of these, inspect the scopes granted within each application and review the other users of the app to determine if the grant needs to be recreated before revoking accounts to avoid disrupting the integration. (In Nudge Security, this information is readily available in the “OAuth” dashboard—otherwise, it’s a fairly tedious and manual process.)

4. Revoke SSO managed accounts.

This one’s easy: If your organization uses a single sign-on (SSO) provider like Okta or Azure AD, take the step of disabling those accounts directly in your SSO environment. (Keep in mind that this step will disable the account, but you’ll still need to perform the cleanup described below in step 7.)

5. Revoke OAuth managed accounts.

One of the most seamless ways to spin up new SaaS and cloud accounts is to create an account through simple OAuth grants from Google or Microsoft. You hit “Sign up,” you breeze through the “Continue with Google” button, and you’re off to the races—it’s so easy, you hardly register that you’ve created an account. 

For each of these, it’s essential to manually remove the OAuth grants to ensure that accounts don’t persist with backdoor access. 

Review the following instructions to complete this step:

6. Revoke all remaining unmanaged accounts.

For accounts that are not centrally managed by SSO or OAuth (i.e. those for which an employee created accounts using an old-fashioned username and password), passwords should be reset in order to prevent the former employee from walking out the door with a post-it note of active usernames and passwords.

In order to reset passwords, you’ll first need to discover all of the accounts that exist. As a first step, you might log into the former employee’s email account and search for terms like “account signup,” “account confirmation,” or “password reset.” Once you have a full list, you (or another admin) will need to visit every application and complete the reset password flow. (In Nudge Security, these password resets can be requested directly from your central dashboard.)

7. Clean up all revoked accounts.

Now that SSO-managed accounts, OAuth grants, and unmanaged accounts have all been revoked, it’s time for the admins of those apps to review and delete those accounts entirely. Even after a user's account access is revoked, critical data and resources can persist or become orphaned within that account. 

To avoid this happening, administrators should finish the clean-up process on the employee’s accounts to reclaim licensed seats, migrate data and resources, and then properly delete the accounts as a final step. 

Keep in mind that if you don’t reclaim these licenses, you’ll continue to pay for them—and because these apps are likely managed by different business units, you’ll need to coordinate with multiple account administrators. (In Nudge Security, this step is easily automated via a detailed nudge sent to the owner of each app, including instructions.) 

8. Suspend or delete the employee’s Google Workspace or Microsoft 365 account. 

This final step will vary depending on internal protocol, and should be completed carefully. In determining how and when to shut down an account, consider whether the former employee’s mailbox should be forwarded to another user, whether files and data need to be transferred, and which calendar events should be delegated or deleted.

How Nudge Security can help

As a reliable and comprehensive source of truth for ALL of an employee’s SaaS and cloud apps, accounts, OAuth grants, and more, Nudge Security’s dashboard is the ideal hub from which to manage the details of SaaS offboarding for departing employees. What's more, our employee offboarding playbook automates many of the steps above, turning 5 hours of manual IT effort per employee into an estimated 30 minutes or less, resulting in upwards of 90% time savings for IT organizations. To try it out, start your free, 14-day trial of Nudge Security today.

Related posts

Report

Debunking the "stupid user" myth
in security

Exploring the influence of employees’ perception
and emotions on security behaviors