Google Workspace Admin Runbook
Google Workspace Admin Runbook
Stand up and secure a Workspace tenant entirely from the official Admin Console — no command line. Each step gives the exact click path under admin.google.com, what to set, and how to confirm it worked.
Sign in & orient
Sign in with a super-admin account. The left rail is your whole toolset: Directory, Devices, Apps, Security, Reporting, Account.
No menus? If you do not see Directory / Security in the left rail, the account is not a super admin. Get elevated before continuing.
Organizational units
OUs are the policy container. Almost every security and app setting can be scoped to an OU, and settings inherit down the tree.
Give each OU a name and parent. Build around who gets which policy (e.g. Staff, Contractors, Service-accounts, Kiosks), not around the org chart.
Create users
| Field | Set |
|---|---|
| First / last name, primary email | Identity and login address. |
| Organizational unit | Drop them into the right OU now, so policy applies from day one. |
| Password | Auto-generate or set; tick Ask for a password change at the next sign-in. |
Download Google’s template, fill it, and re-upload. The headers are fixed — do not rename them. Required columns are roughly:
# Use the template you downloaded; these are the required columns
First Name [Required]
Last Name [Required]
Email Address [Required]
Password [Required]
Org Unit Path [Required]
Change Password at Next Sign-InLarge imports Split very large files and upload in batches; the console caps rows per upload and will reject a malformed sheet wholesale.
Groups
Name it, give it an address, add members and owners, then pick an access type. The preset sets who can join, post, and view.
| Access type | Who can join / post |
|---|---|
| Restricted | Invite-only, members post. Safe default for internal teams. |
| Team | Anyone in the org can join / post. |
| Announcement | Members view, only owners/managers post. |
| Public | External posting allowed. Use with care. |
Groups are access principals They are used to grant Drive shares, app access, and calendar rights — not just email. Loosening join/post settings is a real security decision.
2-step verification
First allow users to turn on 2SV org-wide. Then, per OU, move enforcement from Off to On (or On from a date), set a new-user enrollment period, and choose allowed methods.
| Setting | Recommended |
|---|---|
| Enforcement | On (or On from a date once everyone is enrolled). |
| Methods | Any except verification codes via text/phone; security keys for admins. |
| New-user enrollment period | A short grace window (e.g. 1 week) before enforcement bites. |
Enforce only after enrollment Turning enforcement on for users who have not enrolled locks them out. Confirm enrollment first (Reporting shows 2SV status), and keep a break-glass admin excluded.
Password & login controls
| Setting | Recommended |
|---|---|
| Enforce strong password | On. |
| Minimum length | 12 or more. |
| Enforce at next sign-in | On, so the policy takes effect promptly. |
| Allow reuse / expiry | No reuse; no forced expiry. |
Skip rotation Current guidance (NIST) is against routine expiry — length plus 2-step beats forced rotation, which just breeds weaker, patterned passwords.
Sharing & app access
The highest-leverage security toggles in Workspace live here: external Drive sharing and which third-party apps may touch your data.
Decide per OU whether files can be shared outside the domain, with warnings, and whether link-sharing defaults to restricted.
Set unconfigured apps to Blocked (or Limited), then explicitly trust the ones you use. This shuts down OAuth-token phishing, one of the most common tenant compromises.
Restrict Marketplace installs to an admin-managed allowlist so users cannot add add-ons that request broad scopes.
Audit & monitoring
Filter, review, and export the activity logs. The four that matter most for security:
| Log | Watch for |
|---|---|
| Login events | Failed and suspicious sign-ins, new IPs / countries. |
| Admin log events | Privilege grants, security-setting changes. |
| Drive log events | External shares and mass downloads. |
| OAuth token log | New third-party app authorizations. |
Review Google’s built-in alerts (suspicious login, leaked password, government-backed attack) and add custom activity-rule alerts from any log above.
Don’t monitor by hand For anything ongoing, export or stream these logs to a SIEM instead of clicking through the console. See the companion Splunk / Elasticsearch sheets for ingest and queries.
Admin roles
Assign a prebuilt role (User Management, Groups Admin, Help Desk, Services Admin) or build a custom role scoped to specific OUs — instead of handing out Super Admin.
Minimize super admins Keep two or three, each on a hardware security key, used only for break-glass. Everyone else gets a scoped role.
Offboarding a user
Cut access first, move the data, delete last. Order matters.
Suspend immediately to block sign-in, then Reset sign-in cookies (same menu) to kill active sessions right away.
The delete dialog prompts you to transfer Drive and Gmail to another user. Do that before confirming. For a departing manager with lots of data, use the standalone transfer tool instead.
Recovery window A deleted user can be restored for about 20 days. After that the account and any untransferred data are gone.
