7 Google Workspace Offboarding Mistakes Startups Keep Making (And How to Fix Them)

When someone leaves your startup, the first thing most founders do is hit "Suspend" on their Google Workspace account. That feels like the job is done. It isn't. Suspension blocks login — it doesn't kill active sessions, doesn't revoke OAuth tokens, and doesn't protect files stored in personal Drive. Most of the real risk sits in the seven steps that founders skip. Here's what they are and how to close each one.

Why This Matters for Startups Specifically

If you run your company on Google Workspace — and most seed-to-Series A startups do — then GWS is your identity layer. Email, Drive, Calendar, Meet, third-party SSO: it all ties back to that account. A botched GWS offboarding isn't a minor IT oversight. It's a live credential that a former employee can still use, data that can silently disappear, or a billing seat you keep paying for months after someone's last day.

Mistake 1: Thinking "Suspend" Cuts Off Access

It doesn't. Suspension prevents interactive login at accounts.google.com — that's all it does. Any device where the employee was already signed in keeps that session alive until it expires naturally, which can be hours or days.

Worse: OAuth tokens issued to third-party apps are untouched by suspension. Every tool the employee connected via "Sign in with Google" — Slack, Notion, Zapier, HubSpot, GitHub — holds an active grant. Many of those tools use offline access grants, meaning they can call Google APIs on the employee's behalf without any re-authentication. Those grants survive suspension entirely.

The correct sequence:

1. Suspend the account (blocks new logins)
2. Reset the password (this triggers revocation of standard OAuth 2.0 tokens per Google's own policy)
3. Go to Admin Console → User → Security → Connected Applications → Revoke All
4. Go to Admin Console → User → Security → Sign Out of All Sessions

Do all four steps. Suspension alone is step one of four.

Mistake 2: Deleting the Account Before Transferring My Drive Files

Files stored in an employee's personal Google Drive (My Drive) are owned by that individual account, not by your organization. If you delete the account first and then try to recover the files, you have approximately 20 days before Google moves them to permanent deletion — and about 25 days before they are gone forever, with no recovery path even for admins.

The correct order is always: suspend → transfer data → delete.

Go to Admin Console → Users → [User] → Transfer Drive Files before you touch delete. You can bulk-transfer all My Drive content to a manager or a designated service account.

One more edge case: external sharing links the employee set up continue to work even on a suspended account. Someone outside your company with a shared link can still view or download those files. You need to audit and revoke external sharing separately — suspending the owner does not break existing shared links.

The safer long-term fix: Move team-critical files into Shared Drives, not personal My Drives. Files in a Shared Drive belong to the organization. When an employee leaves, you just remove their membership — the files stay.

Mistake 3: Not Revoking Apps Script and Automation Grants

Resetting the password triggers standard OAuth 2.0 token revocation — but there's a documented exception: Google Apps Script. Scripts that run on a schedule or in response to triggers continue running under the account owner's credentials even after the password is reset and the account is suspended.

If your departing employee built any Google Sheets automation, Workspace add-ons, or custom scripts, those scripts keep executing. They may be reading or writing data across your organization's spreadsheets or sending API requests on behalf of an account you think is locked down.

Check: Admin Console → Reports → Audit → Admin Activity for any scripts owned by the user. Transfer script ownership or delete them before finishing the offboarding.

The same logic applies to third-party automation tools built on OAuth that use refresh tokens. Revoking at Google's side doesn't immediately notify the third-party app — it just means the next time that app tries to authenticate, it fails. There's a window (hours to days depending on the app) where access still appears to work.

Mistake 4: Wrong Super Admin Demotion Order

If the departing employee is a Super Admin, you cannot demote them while they're actively holding the only Super Admin role. More specifically, you cannot remove Super Admin from yourself — another Super Admin has to do it.

The operational trap: many early-stage startups have exactly one Super Admin — the CTO or a co-founder. If that person leaves and you try to remove their admin role without first promoting someone else, you can find yourself locked out of billing controls, domain management, Google Vault, and core security settings. Recovering from this requires domain-level verification with Google and can take several business days.

Correct order:

1. Promote a new user to Super Admin (confirm they can log in and see admin panels)
2. Remove the Super Admin role from the departing employee's account
3. Check for delegated admin roles (User Management Admin, Groups Admin) — remove those too
4. Then suspend or delete the account

Promote first. Demote second. Always.

Mistake 5: Leaving Email Forwarding Active — or Setting It Up Too Late

Two separate forwarding problems show up at offboarding.

First: the employee may have set up personal email forwarding in Gmail before leaving — routing company mail to their personal Gmail. Suspension doesn't stop this. While the account is suspended, emails that arrive can still forward to a personal inbox. Audit for this in Admin Console → Reports → Audit → Gmail before suspending.

Second: when you set up admin-side mail routing to forward the departed employee's incoming email to their manager, you must do this while the account is still active or suspended — not after deletion. Once the account is deleted, the mailbox is gone. There is no "forward from a deleted account." Many founders delete first, then realize the routing has nowhere to attach.

Set up admin-side forwarding first, verify it works, then proceed with deletion.

Mistake 6: Forgetting That Meet Recordings Live in Personal Drive

Google Meet recordings don't go to a shared company folder by default. They're saved to the organizer's My Drive, in a folder called "Meet Recordings." This means every recorded meeting that employee ran is sitting in their personal Drive.

If you delete the account without transferring Drive first (see Mistake 2), those recordings are in the 20-day recovery window — and then permanently gone. Check for the Meet Recordings folder during Drive transfer and move it to a Shared Drive before finalizing deletion.

Mistake 7: Leaving Recovery Email and Phone Intact

Every Google Workspace account can have a recovery email and recovery phone number attached — typically the employee's personal Gmail and personal cell, set up at account creation or during MFA enrollment.

After offboarding, those stay on the account unless you explicitly remove them. Here's why that matters: if the account is suspended rather than deleted, Google's account recovery flow can still be triggered using the attached recovery contacts. A determined former employee can use that flow to reset the account password and regain access — even from a suspended state.

Find this at Admin Console → Users → [User] → Security → Account Recovery. Remove both the recovery email and recovery phone before finishing the offboarding.

The scale problem: there's no native bulk tool for this in Google Workspace. If you have 30 employees, you're removing recovery info one account at a time. If you're at a dozen or more people, scripting this via the Directory API is worth the one-time setup cost.

For the broader problem of access closure spanning Google Workspace, Slack, Notion, Figma, and every other tool your team uses, see our guide on offboarding an employee across multiple SaaS tools without an IT team.

Quick Reference: What Each Action Actually Does

The right order: Suspend → Reset password → Revoke apps + sessions → Remove recovery contacts → Transfer Drive → Delete account.

One last step that most startups miss: a suspended account still counts as a billable seat. Once the account is fully deleted and data transferred, remove the seat from your Workspace subscription.

Most startups do step 1 and step 5 and skip everything in between. That's the gap these seven mistakes live in. If you want a repeatable process for catching these gaps on every offboarding, the 30-Minute Quarterly Access Review for Startups gives you a standing cadence to keep former-employee access from accumulating.

FAQ

Does suspending a Google Workspace account remove access to third-party apps like Slack or Notion? No. Suspension blocks interactive login to Google but does not revoke OAuth tokens held by third-party apps. Tools the employee connected via "Sign in with Google" retain their access grants until you explicitly revoke them at Admin Console → User → Security → Connected Applications, or until the tokens expire on their own (which can take days or weeks).

How long do I have to recover data after deleting a Google Workspace account? Google provides approximately 20 days after deletion to restore an account and recover data. After about 25 days, the data enters permanent deletion and cannot be recovered by admins or by Google support. Always transfer Drive files before deleting the account — suspension preserves the data indefinitely.

Can a former employee recover their suspended Google Workspace account? Yes, if their personal recovery email or phone number is still attached to the account. Google's account recovery flow can be used from a suspended state. Remove recovery contacts (Admin Console → User → Security → Account Recovery) before or during offboarding.

What's the difference between My Drive and Shared Drive when offboarding? My Drive files are owned by the individual user account. If the account is deleted, those files are at risk of permanent loss. Shared Drive files belong to the organization — removing a user just removes their membership, not the files. For operational resilience, store team-critical files in Shared Drives rather than personal My Drives.

Does resetting a Google Workspace password really revoke all access? Mostly. A password reset revokes standard OAuth 2.0 tokens, which covers most third-party app connections. It does not revoke Google Apps Script tokens — scripts the employee owned continue running. It also doesn't automatically sign them out of existing sessions on devices; you need to trigger that separately via Admin Console → User → Security → Sign Out of All Sessions.

Close the Gap Beyond Google Workspace

Google Workspace offboarding is one piece of a larger puzzle. After you've handled GWS, the same employee still has access to Slack, Notion, Figma, GitHub, HubSpot, and every other tool your team uses — and most of those have their own equivalents of the seven mistakes above.

Optserv ties the employee lifecycle to access across your full tool stack. When someone leaves, their GWS offboarding triggers automatically alongside Slack deactivation, Notion member removal, and every other tool in your access map — without a checklist and without an IT team.

See how it works at app.optserv.ai/signup or read more about how the HR/IT offboarding gap creates these problems in the first place: The Offboarding Gap: Why HR Software Won't Revoke Access.

Sources

• Google Workspace Admin Help: Automatic OAuth 2.0 token revocation upon password change
• Google Workspace Help: Maintain data security after an employee leaves
• Nudge Security: OAuth Grants — The Hanging Chads of Suspended Google Workspace Users
• GAT Labs: Safely Offboard Google Workspace Users in 5 Steps
• Google Workspace Admin Help: Restore a deleted user's Drive files