Learn
Guide
Rehiring a former employee in Google Workspace is not the same as onboarding someone new, and treating it that way is where most of the risk creeps back in. If the original offboarding was done properly, the account was suspended rather than deleted, and the rehire is straightforward: reactivate the account, then rebuild access from the new role instead of switching the old permissions back on. ShiftControl’s published offboarding guidance answers the delete-or-suspend question with suspend first, always, for exactly this reason. Where the account was deleted, you are working against Google’s recovery clock instead, and once it runs out the data is gone. Get the sequence wrong either way and you lose data permanently or hand someone access to tools, groups and shared drives they no longer need.
TL;DR
If offboarding was done properly the account was suspended, not deleted. A suspended Google Workspace user keeps their data and license slot but loses login access entirely, so reactivating is the cleanest rehire path. ShiftControl’s offboarding guidance recommends suspending first, always.
If the account was deleted, you are on a clock. Google’s admin documentation puts the window at 20 days to restore a recently deleted user account and its data and 25 days to restore Drive or Gmail data after it is removed from trash.
Once that window closes, the account and its data are gone permanently. There is no vendor-side recovery after day 20 for the account itself.
Treat a rehire as an access rebuild. Old group memberships, app permissions and shared drive access should be rebuilt deliberately rather than restored wholesale.
Ineffective offboarding is a real driver of breach risk, which makes the original offboarding quality (not just the rehire process) the thing worth auditing.
Employee lifecycle management software that ties HR status changes directly to Google Workspace access removes the manual guesswork rehires usually create.
About the Author
ShiftControl is built by operators from ExpressVPN, where the company’s technical co-founder ran the IT operations that grew from supporting 100 employees to over 700 across 7 global offices. The platform is purpose-built for Google Workspace lifecycle events, including the messy middle ground of rehires, role changes and delayed offboarding.
What Actually Happens to a Google Workspace Account After Someone Leaves?
There are two states the account can be in, and they behave very differently.
The first, and the one to hope for, is suspension. A suspended Google Workspace user keeps their data and license slot but loses login access entirely, which is why it is the standard recommendation when someone leaves: nothing is destroyed, nothing is reachable and no countdown is running in the background. Suspended accounts still need to be accounted for in any audit, though, since a suspended account with stale permissions is an attack surface the moment it gets reactivated without review.
The second is deletion, and deletion starts a clock. Google’s admin documentation puts the window at 20 days to restore a recently deleted user account and its data, and separately allows administrators to restore a user’s Drive or Gmail data for up to 25 days after it is removed from the user’s trash. These are two distinct clocks: one for the account itself, one for trashed content within it.
Once the 20-day window closes, the account and all associated data are permanently removed and cannot be restored. There’s no appeal process, no vendor-side backup to fall back on. This is why the timing of a rehire decision matters so much when the account was deleted. If someone is let go and rehired within three weeks, the account may still be recoverable. If the gap is longer, you’re starting from zero, which actually simplifies the security story even if it complicates the data story.
Should You Reactivate the Old Account or Create a New One?
The account states above answer the technical “can you” question. The harder question is whether you should, and that depends on what happened between departure and rehire.
If the account was suspended at offboarding and the employee is returning to the same or a very similar role, reactivating it is the simplest path. Email history, Drive files and calendar continuity are all intact, and there was never a deletion clock to beat.
If the account was deleted but is still within Google’s 20-day recovery window and the role is the same or similar, restoring it preserves that same continuity, with the caveat that you are depending on a window that may already have closed.
If the account has already been permanently deleted, or the employee is returning to a different role or department, a fresh account is usually cleaner. There’s no legacy data to audit for relevance, and access can be built from the current role definition rather than inherited from an old one.
If the departure involved any disciplinary or security concern, don’t reactivate or restore the old account under any circumstance. Start fresh and treat the rehire as a new hire from an access standpoint, full stop.
A useful analogy here is re-keying a house after a tenant moves out and a new one moves in, even if it’s the same person returning a year later. You don’t hand back the old keys because the tenant used to live there. You cut new keys that match the current locks, because you can’t be certain who copied the old ones in between. A reactivated or restored Google Workspace account is the digital equivalent of handing back old keys: convenient, but it assumes nothing changed in the interim, which is rarely a safe assumption for a role, a team structure or a company’s app stack.
Why Does Restoring Old Access Recreate Risk?
This is the part that gets skipped when teams treat rehires as a data-recovery problem instead of an access-governance problem. Bringing an account back brings back the account and its content. It does not, by itself, tell you whether the access that account previously had still makes sense.
Consider what typically survives a reactivation or a restore:
Element | Carried over automatically? | Risk if unreviewed |
|---|---|---|
Email and Drive content | Yes | Low, mostly a data hygiene issue |
Group memberships | Often, if groups weren’t cleaned up | Medium, may grant access to channels or shared drives no longer relevant |
Third-party app permissions (OAuth grants) | Sometimes, if the app wasn’t fully revoked | High, stale OAuth tokens can persist silently |
Admin roles or delegated permissions | Rarely removed cleanly without a process | High, privileged access is the costliest thing to leave dangling |
SSO and password manager entries | Depends on the tool used | Medium to high, depending on credential reuse |
The reason ineffective offboarding matters so much here is that a rehire only inherits the risk that was left behind. When access to company systems is not revoked promptly during employee departures, security gaps accumulate and become more likely to be exploited. A rehire doesn’t create that risk from nothing. It reopens a door that was never properly closed.
This is exactly why a Google Workspace security audit belongs before any rehire is granted access, not after. The audit confirms that offboarding actually did what it was supposed to do the first time, which matters far more than anything about the individual returning employee.
How Should Access Actually Be Rebuilt for a Rehire?
Building on the account-versus-data distinction above, the practical rebuild process should follow the same discipline as a new hire, with one extra step: verifying nothing old is silently attached.
Confirm the account status first. Suspended, deleted or still active but locked out. This determines whether you’re reactivating, restoring or starting fresh.
Run a permissions check before granting anything. Look specifically for lingering OAuth grants to third-party apps and any admin-level roles that were never revoked.
Assign access based on the current role, not the historical one. Group membership and app access should be provisioned from today’s org chart, not copied from the account’s last known state.
Re-enroll in MFA and SSO cleanly. Treat credentials as new, even if the account itself is old.
Log the decision. Whether you reactivated, restored or rebuilt, document it, since this becomes part of your audit trail for the next review cycle.
Manually, this is a lot of steps to get right consistently, especially for a company without a dedicated IT person doing it every week. This is the gap employee lifecycle management software is meant to close: instead of an admin reconstructing access from memory, rules tied to HRIS status (rehired, role change, department move) provision the correct groups and app access automatically, and anything left over from the previous period of employment surfaces as a Work Item to clear, with downloadable access reports for the record. ShiftControl was built around exactly this kind of event, syncing with HR systems and Google Workspace so that a rehire’s access reflects their current role from the first login, with permission visibility built in rather than bolted on afterward.
Frequently Asked Questions
Can I restore a deleted Google Workspace user after 20 days?
No. Google’s admin documentation sets a 20-day retention timeline for deleted user accounts, and after this window expires the account and all associated data are permanently removed and cannot be restored.
What’s the difference between a suspended and a deleted user in Google Workspace?
A suspended Google Workspace user keeps their data and license but cannot log in, while a deleted user’s account starts a 20-day countdown toward permanent removal. Suspension is the recommended offboarding state precisely because it avoids that countdown.
Should a rehire get their old email address back?
Only if the account was reactivated or restored within the recovery window and no naming conflicts exist. If a new account is created instead, a new address is usually simpler and avoids inbox continuity confusion.
Do rehires need MFA re-enrollment even if their old account is restored?
Yes. Credentials and device trust should be treated as new regardless of whether the account is old.
Can I recover just a rehire’s old files without restoring the whole account?
Yes. Google’s admin documentation allows administrators to restore Drive or Gmail data for up to 25 days after it’s removed from trash, separately from full account restoration.
What’s the biggest mistake companies make with rehires?
Assuming that bringing the account back restores appropriate access. The two are unrelated. Access needs a fresh review every time regardless of account history.
How do you catch leftover access from the previous period of employment?
A lifecycle tool surfaces leftover group memberships, admin roles or app permissions tied to the old account as work to clear before they’re carried into the new period of employment, and access reports give you a record of what was reviewed, rather than relying on someone to remember to check.
About ShiftControl
ShiftControl is an IT operations and SaaS management platform made for Google Workspace, built for operators rather than IT teams. It combines provisioning and access, SaaS spend management, app-permission visibility and incident response into one platform, so companies without a dedicated IT hire get the control a large enterprise has without the overhead. Set up in as little as 10 minutes through a single Google Workspace login. Cyber incident response (IR-1, via Blackpanda) is included in the subscription rather than sold as a separate add-on. ShiftControl’s technical co-founder ran IT operations at ExpressVPN as that scope grew from 100 to over 700 employees across 7 global offices, and ShiftControl was built specifically for the lifecycle moments, like rehires, that generic IT tools tend to overlook.
If your team is navigating a rehire, a stalled offboarding or just wants a clearer view of who has access to what, ShiftControl can show you what that looks like in practice.
