Control boundary
The short answer
Google describes administrator suspension as a temporary block on a user’s access to the organization’s Google services. A suspended account can later be restored, at which point the user can again access its services and data. That makes suspension an important identity-provider control—not a universal deactivation command for every product the employee used.
Record the Google account as suspended. Keep each downstream application as active or unknown until that application’s access state has been verified.
Inside Google
What suspension does
It blocks the managed Google account
Google Workspace administrators can suspend a user to temporarily block access to the organization’s Google services. Google’s restoration documentation confirms that reactivating a suspended user restores access to their services and data.
Source: Google Workspace Admin Help: Suspend a user temporarily and Restore a suspended user.
It resets Google sign-in cookies
Google states that suspension resets the user’s Google sign-in cookies, so a separate cookie-reset step is not required for a suspended user. Google also warns that sign-out timing can vary: current Gmail sessions can take up to an hour, while other applications may differ.
Source: Google Workspace Help: Manage a user’s security settings.
It remains different from deletion and data transfer
Suspension is reversible. Deleting a user and transferring company data are separate administrative operations with their own consequences. Treat retention, ownership transfer, mail routing, and deletion as explicit offboarding decisions rather than implied results of suspension.
Source: Google Workspace Admin Help: Delete or remove a user.
Outside Google
What suspension does not prove
The items below are vendor-side or organization-specific states. Because they sit outside the Google Workspace account control, a Google suspension should not be used as evidence that they changed.
| Access question | Proved by suspension? | Required follow-up |
|---|---|---|
| Managed Google account blocked | Yes, subject to propagation | Record the suspension result and time. |
| Third-party SaaS account disabled | No | Verify the account in the vendor’s admin surface. |
| Vendor-local browser or mobile session ended | No | Use the vendor’s session-revocation control. |
| Direct password or recovery method invalidated | No | Disable or rotate it at the vendor. |
| API key, personal token, or service credential revoked | No | Inventory and revoke credentials at their issuer. |
| Application ownership or privileged role transferred | No | Reassign ownership and remove vendor-side roles. |
Connected Google applications have separate controls
Google provides distinct controls for applications that access Workspace data through OAuth. Its documentation notes that removing an application’s data access does not permanently stop future use if the user can sign in again; permanent restriction requires organization-level app controls such as blocking scopes or maintaining an allowlist.
Source: Google Workspace Help: Control which apps access Google Workspace data.
External identity-provider sessions need their own handling
Organizations using a third-party identity provider should also terminate that provider’s session. Google specifically warns that an external SSO session can continue to affect access even after Google sign-in cookies are reset.
Practical workflow
Verify downstream access in five steps
- Start with the application inventory.Identify apps assigned through SSO, SCIM, direct credentials, privileged roles, API tokens, or shared ownership.
- Classify the identity path.Record whether Google is the only sign-in path or merely one of several ways the account can be accessed.
- Verify the current vendor-side state.Check the user, active sessions, roles, tokens, and ownership assignments in the application or authoritative integration.
- Record the actor and action.Name who verified the state, who performed a revocation, when each event occurred, and whether the result succeeded.
- Keep exceptions open.Do not convert an unavailable or incomplete check into “revoked.” Assign an owner and next action to every unknown.
For the full sequence, use the Google Workspace offboarding checklist. To see how Sever represents the review state, visit Features or open the sample evidence report.
Primary references
Sources
- Google Workspace Admin Help — Suspend a user temporarily
- Google Workspace Admin Help — Restore a suspended user
- Google Workspace Help — Manage a user’s security settings
- Google Workspace Help — Control which apps access Google Workspace data
- Google Workspace Admin Help — Delete or remove a user
This technical guide is operational guidance, not legal or audit advice. Validate the workflow against your organization’s policies, contracts, retention requirements, and application controls.