Secure offboarding in Google Workspace: a checklist for employee departures

By Kike Gandia · Co-Founder & CEO, OSCP

Poorly managed former-employee accounts are a silent attack surface: access that stays active, data that's lost and tokens that are never revoked. This checklist covers the secure offboarding of an employee in Google Workspace, step by step.

Suspend the account immediately

The first step when offboarding an employee is to suspend the account, not delete it. Suspension cuts access instantly while preserving the data and allows you to transfer it in an orderly way. Deleting the account outright can cause the loss of valuable information.

Revoke sessions, OAuth tokens and app passwords

Suspending the account doesn't always invalidate all access: third-party OAuth tokens and app passwords may remain active. Explicitly revoke sessions, tokens and app passwords to ensure no open access remains.

Transfer data ownership

Before deleting the account, transfer ownership of email, Drive files and calendar events to a manager or a shared drive. Google's data transfer tool makes this step easier and prevents the loss of business information.

Review rules, delegations and devices

Remove forwarding rules and filters, revoke mailbox delegations and unlink or remotely wipe the devices associated with the account. Finally, apply the retention policy (with Vault if applicable) and free up the license.

Before touching anything: decide whether evidence must be preserved

If the departure is contentious, there is an open claim or there is any suspicion that the employee took information with them, the first step is not suspension: it is freezing the state. A Vault hold over mail and files, applied before transferring anything, preserves the content as it stands. The moment you transfer Drive ownership or delete the account, you lose information that cannot be reconstructed afterwards.

At the same point it is worth exporting the account’s relevant activity —sign-ins, bulk Drive downloads, recent external sharing— because audit logs have their own retention window that does not depend on the account still existing. If the departure is routine, this step is skipped and you go straight to suspension.

Close the loop outside Google Workspace

The Workspace account is usually also the identity the employee used to sign into half a dozen SaaS tools through SSO. Suspending it prevents new federated sign-ins, but it does not on its own close sessions already open in those applications or the API tokens they may have generated there, and it does nothing at all about tools with their own username and password.

So offboarding finishes outside the console: review federated applications one by one, remove the user from code repositories and the VPN, wipe or retire their devices from the MDM, rotate the shared credentials they knew in the password manager, remove them from shared drives and check whether they left IAM permissions or service accounts behind in Google Cloud.

Check the order: what breaks if you skip a step

The sequence matters more than it looks, because several steps destroy each other if done in the wrong order.

Step	If you do it too early	If you forget it
Vault hold	Nothing, it goes first	You lose the evidence as soon as you transfer or delete
Suspend the account	Nothing, the sooner the better	Access stays open
Revoke OAuth tokens and app passwords	Nothing	Third-party apps keep reading mail and files
Transfer Drive, mail and calendar	Without suspending first, the user keeps modifying data	The data is lost when the account is deleted
Remove rules, filters and delegations	Nothing	Mail keeps being forwarded outside the company
Remove access in federated apps and MDM	Nothing	Live sessions remain outside Workspace
Delete or archive the account	Before transferring, you lose the data	You keep paying a licence and keep an identity alive

FAQ

Should I delete the account immediately?

No. It's advisable to suspend it first, transfer the data and only then delete or archive it according to your retention policy. Deleting it outright can cause the loss of information and evidence.

If the account was compromised, is suspending it enough?

Suspending it cuts the sign-in, but you must also review OAuth tokens, forwarding rules and delegations, because they can keep the attacker's access independently of the password.

How long should the suspended account be kept?

The period is set by your retention policy and applicable legal obligations, not by a technical criterion. What is a technical criterion is the minimum: do not delete until the data transfer has been verified and no Vault hold remains active on that account. Deleting before checking the transfer is the most expensive mistake in this process.

Can I reassign the licence immediately?

Suspending the account does not by itself free the licence. Some editions offer archived user licences, which retain the data with Vault at a lower cost than a full licence. Check what your edition offers before assuming the saving arrives automatically on suspension.

What if the employee left months ago and none of this was done?

It is the most common finding in a Workspace audit. The way to tackle it is to inventory first: active accounts with no recent activity, suspended accounts that were never closed, and files owned by people who have left. Against that inventory you review tokens, forwarding rules and delegations before transferring ownership, and only then delete the accounts.

Is doing it by hand in the console enough, or should it be automated?

With low turnover the console is fine, provided the checklist is written down and somebody signs it off. Past a certain volume it stops being realistic: the sensible route is to lean on the Admin SDK so suspension, token revocation and transfer always run the same way and leave a record, instead of depending on whoever is on duty remembering all seven steps.

Related service

Google Workspace security audit

Sources

Request a Google Workspace audit