When someone leaves your organisation, how long does it take to remove all of their access?
Not just their Google account. Their app tokens, Drive shares, group memberships, delegated access to other users’ accounts, Chrome session data, and third-party services connected through their Google identity.
If the honest answer is “it depends on who handles it” or “we follow a checklist,” your offboarding process is a Zero Trust failure waiting to happen.
The problem with manual offboarding
Manual offboarding is one of the most consistently underestimated security risks in Google Workspace. It relies on the assumption that the person handling it will remember every step, every time, under the pressure of a deadline that is often the same day someone leaves.
In practice, this is what tends to get missed:
1. Third-party app tokens. When a user authenticates a third-party app via “Sign in with Google,” that app receives an OAuth token tied to their account. Suspending or deleting the account does not automatically revoke those tokens in all cases. An attacker who has compromised an app can retain access even after the user account is suspended.
2. Delegated access. If a user was granted access to another user’s Gmail or Calendar, or if they had delegated access themselves, those permissions persist until explicitly removed. This is rarely on a standard offboarding checklist.
3. Shared Drive permissions. Files and folders shared with a user directly, rather than through a group, remain accessible until someone removes them. On a domain with thousands of files, this is not something a manual process handles reliably.
4. External app integrations. Users often connect personal tools, Zapier automations, or other services directly to their Google account. When they leave, those integrations remain active and potentially accessible.
5. Group memberships. Users added to distribution groups, shared drives, or mailing lists stay in those groups until manually removed. If sensitive data is shared with those groups, former employees retain indirect access.
None of these items requires malicious intent to create a problem. They are routine gaps in a manual process.
What Zero Trust offboarding actually requires
Zero Trust applied to offboarding means one thing: when someone leaves, every access point closes. Not most of them. All of them. And it happens the same way, every time, regardless of who runs the process.
This requires automation, not checklists.
A Zero Trust offboarding workflow should cover:
1. Account suspension: The account is suspended immediately when the offboarding is triggered, not at end of day or when someone remembers to do it.
2. App token revocation: All OAuth tokens associated with the account are revoked. Every third-party app that had access loses it at the point of offboarding, not when someone manually reviews the app list.
3. Drive file transfer: Files owned by the departing user are transferred to their manager or a designated account. Shared content remains accessible to the right people.
4. Group and calendar removal: The user is removed from all groups, shared calendars, and distribution lists automatically.
5. License recovery: The Google Workspace license is released and made available for the next hire.
6. Delegated access removal: Any delegated access granted by or to the departing user is revoked.
Each of these steps should be logged. If an approver is needed for any step, that approval should be captured and stored for audit purposes.
How GAT Flow handles this
GAT Flow is GAT Labs’ workflow automation tool for Google Workspace. It lets admins choose and customize predefined offboarding templates that execute every step in sequence, log each action, and require approval where policy demands it.
Once the workflow is configured, it runs the same way every time. There is no dependency on who is covering IT that week. There is no risk of a step being missed because the departure was sudden or an admin was overloaded.
The most important step for Zero Trust is token revocation. GAT Flow lets you revoke all third-party app tokens for a Google Workspace user in a single workflow step. This closes the OAuth access gap that manual offboarding processes frequently miss.
Beyond offboarding, GAT Flow supports the full user lifecycle:
Onboarding
Admins create new accounts with the correct OU placement, group memberships, and permissions from day one. They assign access consistently instead of relying on ad hoc permission grants that often remain long after users no longer need them.
Role Changes
When users move departments or change roles, admins can automatically update permissions to match new responsibilities (RBAC). The workflow removes old access, grants new access, and applies the same process consistently regardless of who handles the request.
Bulk Updates
When admins need to update permissions across multiple users, such as removing access to a Shared Drive after a project ends, GAT Flow handles the changes in a single operation rather than manually updating users one by one.
What to audit before you automate
A good offboarding workflow is only as effective as the access map it is working from. If you do not know what access a user has, you cannot revoke it completely.
Before building your offboarding workflow, run a baseline audit with GAT+:
1. Connected apps: Use GAT+’s third-party application audit to see every OAuth app connected to your domain and which users have authorised them. This gives you the full picture of what needs to be revoked at offboarding.
2. Drive shares: Run a Drive audit to identify files owned by specific users or shared with them directly. GAT+ lets you remove external collaborator access in bulk so that file cleanup does not slow down the offboarding process.
3. Group memberships: Audit which groups each user belongs to. Group memberships often leave residual access in place after admins suspend an account.
4. Delegated access: Identify any users who have granted or received email or calendar delegation. This is one of the most overlooked access vectors in a manual offboarding process.
Once you have this baseline, your offboarding workflow addresses every layer of access, not just the obvious ones.
Building accountability into sensitive offboarding steps
Some offboarding actions require more than automation. They require documented approval.
If an admin needs to access a departing employee’s email archive as part of an HR investigation or data retrieval process, that access should not happen without oversight. GAT Unlock provides the approval layer for these situations.
The admin submits a request specifying what they need to access and why. A designated Security Officer reviews and approves the request. The access is granted for a limited time, and every detail is logged. When the access period ends, it expires automatically.
This is what Zero Trust looks like when applied to the admins themselves, not just the users.
In regulated industries, this audit trail is not optional. GDPR, HIPAA, and ISO 27001 all require that access to personal data be documented and justified. GAT Unlock provides that documentation without creating additional process overhead for routine work.
The access that survives a manual offboarding
To make this concrete, here is what typically remains after a standard manual offboarding in a mid-sized Google Workspace domain:
In the days following a manual offboarding, GAT+ audits regularly uncover active OAuth tokens tied to suspended accounts, Drive files still shared with former employees, group memberships that admins missed during the checklist process, and undocumented calendar delegation configured informally over time.
None of this is intentional. It is the natural result of a process that relies on memory and attention rather than automation.
An automated workflow removes these gaps by running the same steps in the same order every time. The workflow defines what gets revoked, not whoever happens to be on duty.
A note on Shadow IT and offboarding
One of the reasons Zero Trust offboarding is harder than it looks is Shadow IT. Users often connect third-party apps without IT fully reviewing them, creating hidden access risks across the domain.
GAT Flow revokes all third-party app tokens issued by a user in a single workflow step, even when admins have not previously reviewed those apps. At the same time, ongoing third-party app auditing in GAT+ helps admins understand which apps users actively connect across the domain, identify risky applications earlier, and reduce Shadow IT before it becomes a security issue.
Setting up alerts for new app installations means you are notified as soon as a new app connects to your domain. This gives you continuous visibility as your environment evolves, instead of discovering Shadow IT only after it becomes a security or compliance issue.
For a broader view of how Shadow IT feeds into Zero Trust risk, see our guide on Zero Trust security in Google Workspace.
Summary: What a complete Zero Trust offboarding covers
A robust, automated offboarding workflow in Google Workspace should handle all of the following:
- – Revocation of all OAuth tokens and third-party app access
- – Drive file transfer to the appropriate owner
- – Removal from all groups, shared drives, and mailing lists
- – Calendar and Gmail delegation removal
- – License recovery
- – Documented approval for any sensitive admin access to the departing user’s data
- – Account suspension on the day of departure
Every step logged. Every action auditable. No dependency on who runs the process.
Insights That Matter. In Your Inbox.
Join our newsletter for practical tips on managing, securing, and getting the most out of Google Workspace, designed with Admins and IT teams in mind.
