# 21 Leaver offboarding runbook > DRAFT · v0.1.0 · role: Prevent · [policy: #29 · #10](https://docs.google.com/spreadsheets/d/1nOztaPd1Y7eNeRSR_hdovYy-ncpx-bAx/edit?usp=sharing&ouid=115159875779023172526&rtpof=true&sd=true) Before this control: [№5 Account inventory (incl. shared/service accounts)](account-inventory.md) · [№20 Basic mobile device management](mobile-basic-management.md) Google's checklists close with 'prevent unauthorized access after an employee leaves'; this runbook is that item as a fixed sequence rather than a good intention. On HR's notice the account is suspended, live sessions and tokens are killed, recovery paths are stripped, managed devices are wiped ([20 Basic mobile device management](mobile-basic-management.md)), data moves to its successors under the retention rules ([32 Vault retention & legal hold](vault-retention.md)), and the account register ([5 Account inventory (incl. shared/service accounts)](account-inventory.md)) records the outcome. Every step is a GAM one-liner, so the sequence takes minutes once written down — and is reproducible at 6pm on a Friday, which is when it is needed. Documentation: [Maintain data security after an employee leaves](https://knowledge.workspace.google.com/admin/users/maintain-data-security-after-an-employee-leaves) ## Caveats - Suspension is one click to reverse for any admin — the monthly HR diff is what catches a quiet re-enable, and the exported audit log (№33) is where the re-enable event lands. - Public links owned by the leaver outlive the account if it is deleted before ownership transfer — №11's sweep is the backstop, but transfer-then-delete is the rule. - Deprovisioning revokes Google-side access only — sessions in third-party SaaS federated through Google Workspace survive it, so offboard the IdP/SaaS side too (№22 is what makes that one place). ## Setup steps 1. Suspend the account the moment HR confirms the departure — suspension stops every new sign-in at once while keeping mail, files and memberships intact for transfer. ``` gam update user suspended on ``` Note: Suspend, don't delete: deletion starts a 20-day clock after which the data is unrecoverable, strands the leaver's files, and is the LAST step of this runbook, not the first. docs: [Delete or remove a user from your organization](https://knowledge.workspace.google.com/admin/users/delete-or-remove-a-user-from-your-organization) 2. Kill what is already alive: reset sign-in cookies, revoke OAuth tokens, app passwords and backup codes, and rotate the password — suspension alone does not end every existing session or standing credential. ``` gam user signout && gam user deprovision && gam update user password random ``` 3. Strip the recovery paths — a recovery phone that leaves in the leaver's pocket is a password reset waiting to happen. ``` gam update user recoveryemail "" recoveryphone "" ``` 4. Wipe the work account from their managed devices ([20 Basic mobile device management](mobile-basic-management.md)) — mail already synced to a phone does not care that the password changed. ``` gam print mobile query "email:" → gam update mobile action account_wipe ``` 5. Transfer what the organization keeps: Drive and Calendar to the manager via a data transfer, group ownerships to a named successor, and any mail the team still needs via delegation or routing — inside what the retention rules ([32 Vault retention & legal hold](vault-retention.md)) already require. ``` gam create datatransfer gdrive calendar ``` docs: [Options to preserve former employee data](https://knowledge.workspace.google.com/admin/getting-started/options-to-preserve-former-employee-data) 6. Remove standing privilege the register knows about: admin role assignments, rows in the delegation and OAuth registers, and every shared-account password the leaver knew — those rotate now. ``` gam print admins | grep → gam delete admin ; rotate shared-account credentials from the account register ``` 7. Close out: once transfers are complete and retention allows, archive the account (Archived User license) or delete it, and record the completed runbook against the register entry. ``` gam update user archived on — or, after data transfer completes: gam delete user ``` docs: [Archive former employee accounts](https://knowledge.workspace.google.com/admin/users/archive-former-employee-accounts) ## Ongoing maintenance - **[automatable: script]** Monthly: diff suspended accounts against the HR leaver list — every leaver suspended-or-archived, every suspension traceable to a leaver or an incident. - **[automatable: AI agent]** After each departure: re-run this control's verify block against the leaver's account before closing the register entry. ## How to verify 1. Attempt a sign-in as the leaver — the response must be 'account disabled', not a password prompt. 2. Enumerate what survives: tokens, app passwords and backup codes must all come back empty. ``` gam user show tokens gam user show asps gam user show backupcodes ``` 3. Confirm the devices came back clean: every device row for the leaver shows the account wiped or the device no longer syncing. ``` gam print mobile query "email:" ``` ## Settings screens - Directory > Users (suspend, reset and per-user security actions) - console: https://admin.google.com/ac/users - screenshot: ../screenshots/admin.google.com/ac/users.png