Most Google Workspace compromises succeed through settings that were never changed from their defaults: SMS codes accepted as a second factor, any third-party app allowed to request mail scopes, automatic forwarding left on and audit logs kept nowhere but the Admin console. This checklist turns the CISA Secure Cloud Business Applications (SCuBA) Secure Configuration Baselines for Google Workspace into ten numbered sections of Admin console checks that [Organisation] can work through and evidence. Each check carries its SCuBA policy ID (for example GWS.COMMONCONTROLS.1.1v1) so results line up with the ScubaGoggles assessment tool and with the CIS Google Workspace Foundations Benchmark, which covers much of the same ground. It is written for Workspace super admins, security engineers and auditors in organisations of any size; the plain-language, step-by-step version for small teams is the Google Workspace for Small Business guide, and the design reasoning sits in the Google Workspace Security Guide.
This is an independent guide from NHI Mgmt Group, based on Google's public documentation as of November 2026. It is not sponsored or reviewed by Google. Product features change, so confirm settings against Google's current documentation.
How to use this template
- Replace text in square brackets, such as [Organisation], [Workspace owner], [Security team] and [SIEM], with your own names.
- Mark each check Met, Partly met, Not met or Accepted deviation. Record the organisational unit (OU) or group the setting applies to, because Workspace settings inherit down the OU tree and a setting that is correct at the top level can be overridden lower down.
- "SHALL" checks come from SCuBA policies CISA marks as mandatory; "SHOULD" checks are recommended. For a non-federal organisation both are good practice, and any SHALL you decide not to meet should be written up as an accepted deviation with an owner and review date.
- Policy IDs were checked against the SCuBA baseline files in CISA's ScubaGoggles repository on 8 November 2026. CISA versions each policy (v1, v2), so recheck IDs when you rerun the assessment.
- Some settings depend on your Workspace edition (for example context-aware access, DLP, security sandbox and data regions). Where a feature is not in your edition, record that fact rather than marking the check as failed silently.
1. Authentication and 2-Step Verification
- Phishing-resistant MFA (security keys or passkeys) is required for all users (GWS.COMMONCONTROLS.1.1v1). In the Admin console this is 2-Step Verification enforcement set to "Only security key"; Google's help centre states that passkeys also satisfy this option. See the Phishing-Resistant MFA Guide.
- Where security keys are not yet enforced for a population, 2SV is still enforced for them (1.2v1) and the method is "Any except verification codes via text, phone call", so SMS and voice are not accepted (1.3v1).
- The new user enrollment period is between one day and one week (1.4v1). Google allows up to six months; a long window means new accounts sign in with a password alone.
- "Allow user to trust the device" is off (1.5v1), so 2SV is not silently skipped on a remembered browser.
- Post-SSO verification (login challenges) is on for users signing in through your SSO profile and through other SSO profiles (3.1v1, 3.2v1).
- Web session length forces reauthentication after 12 hours (4.1v1).
- Password policy: strength enforced, minimum length 12 (16 recommended), enforced at next sign-in, no reuse and no forced expiry (5.1v1 to 5.6v1).
2. Super admins and privileged accounts
- Between two and eight super admin accounts exist, each distinct and named (6.2v1). Export the list from Account, Admin roles, Super Admin, Assigned admins and compare it with [Workspace owner]'s approved list.
- Admin accounts are cloud-only, separate from the identity provider that federates normal sign-in (6.1v1), so a compromise of the IdP does not hand over the tenant. At least one super admin is a break-glass account held under dual control.
- Admins use separate admin accounts and do not read mail or browse with a super admin identity. Day-to-day tasks use delegated admin roles with the least privilege needed. See Admin panels and super admin accounts.
- Highly privileged accounts are enrolled in the Advanced Protection Program (9.1v1); other sensitive users, such as executives and finance approvers, should be too (9.2v1).
- Self-service account recovery is off for super admins and for all other users (8.1v1, 8.2v1), and users cannot add their own recovery phone or email (8.3v1). Recovery goes through [Service desk] with identity proofing.
- Multi-party approval for sensitive admin actions is on (17.1v1), so a single compromised admin cannot, for example, weaken 2SV settings alone.
3. Device and context signals
- Context-aware access policies restrict access to Workspace services based on device signals, such as a managed, encrypted device with a current OS (2.1v1).
- Account conflict management replaces conflicting unmanaged (consumer) Google accounts that use your domain with managed accounts (7.1v1).
- Google Drive for desktop is allowed only on authorised devices (GWS.DRIVEDOCS.5.1v1).
- Endpoint management is set to advanced management for mobile devices that hold corporate mail, with screen lock and remote wipe, where your edition supports it. (NHI Mgmt Group recommendation; SCuBA covers device signals through context-aware access.)
4. Third-party apps, OAuth and API access
- App access control is configured for every app that reaches Workspace data (10.1v1). In Security, Access and data control, API controls, each app is set to Trusted, Limited, Specific Google data or Blocked, and high-risk services such as Gmail and Drive are marked Restricted so only Trusted or Specific Google data apps reach them.
- Unconfigured third-party apps are blocked, including the "basic sign-in info" option, so users cannot grant low-risk scopes themselves (10.2v1, 10.4v1).
- "Trust internal apps" is not ticked (10.3v1): internal apps are reviewed and configured individually like any other.
- Less secure apps that do not use modern authentication are prevented (10.5v1). See Google Workspace Less Secure Apps Retirement.
- Only approved Google Workspace Marketplace apps can be installed (11.1v1).
- Domain-wide delegation grants are listed, each with an owner, a business reason and the narrowest scopes, and reviewed at least quarterly. These service account grants can impersonate any user. See How to audit Google Workspace domain-wide delegation grants and the Google Workspace Domain-Wide Delegation Security Guide.
- Google Drive SDK access is disabled unless a named integration requires it (GWS.DRIVEDOCS.4.1v1).
5. Gmail: authentication and spoofing
- DKIM signing is enabled for every domain (GWS.GMAIL.2.1v1); an SPF record that fails all non-approved senders is published for each domain (3.1v1).
- DMARC is published for every Workspace domain, including alias domains (4.1v1), at p=reject (4.2v1), with an [Organisation] contact for aggregate and failure reports (4.4v1). Federal agencies also add CISA's reporting address (4.3v1). See the Email Authentication Checklist.
- All spoofing and authentication protections are on: similar domain names, employee name spoofing, inbound mail spoofing your domain, any unauthenticated mail, and Groups protection against spoofing your domain (7.1v1 to 7.5v2). Flagged mail is not kept in the inbox (7.6v1) and Google may apply future recommended settings (7.7v1).
- No domains are on lists that bypass spam filters or hide warnings, and the "bypass spam filters" and "hide warnings" options are off (18.1v1 to 18.3v1). No email allowlist is used (14.1v1).
6. Gmail: attachments, links and data leaving
- Attachment protections are on: encrypted attachments and attachments with scripts from untrusted senders, and anomalous attachment types (5.1v1 to 5.3v1); flagged mail is not kept in the inbox (5.5v1).
- Link protections are on: identify links behind shortened URLs, scan linked images, warn on clicks to untrusted domains, and allow future recommended settings (6.1v1 to 6.4v1).
- Enhanced pre-delivery message scanning is on (15.1v1); security sandbox is on where licensed (16.1v1).
- Automatic forwarding is disabled, at least to external domains (11.1v1). Attackers who take over a mailbox commonly add a forwarding rule (MITRE ATT&CK T1114.003).
- POP and IMAP are disabled (9.1v1); user email uploads are disabled (8.1v1); Google Workspace Sync is disabled where not needed (10.1v1); per-user outbound gateways are disabled (12.1v1); mail delegation is disabled or limited to named roles (1.1v1).
- Unintended external reply warnings are on (13.1v1).
7. Drive, Calendar, Chat, Meet and Groups sharing
- Drive external sharing is limited to allowlisted domains (GWS.DRIVEDOCS.1.1v1), with warnings when users share outside them (1.3v1) and out-of-domain file warnings (1.9v1).
- Where an OU allows external sharing, "anyone with the link" is off (1.5v1), sharing with non-Google accounts is off (1.4v1), access checking is "recipients only" (1.6v1), and new items default to "private to owner" (1.8v1).
- Monitoring for potential ransomware corruption in Drive is on (5.2v1) and the Drive security update is applied (3.1v1).
- Calendar shares only free/busy externally for primary and secondary calendars (GWS.CALENDAR.1.1v1, 1.2v1) and warns before external invitations (2.1v1).
- Chat history is on and users cannot change it (GWS.CHAT.1.1v1, 1.2v1); external file sharing in Chat is off (2.1v1); external chat is limited to allowlisted domains (4.1v1).
- Meet makes uninvited external users ask to join (GWS.MEET.1.1v1), warns for external participants (4.1v1), and turns off automatic recordings and transcripts (5.1v1, 5.2v1).
- Groups are not accessible from outside the organisation unless the owner grants it (GWS.GROUPS.1.1v1); owners cannot add external members or let outsiders post without a reason (1.2v1, 1.3v1).
8. Data protection and other services
- DLP rules cover Drive, Calendar, Chat and Gmail for the data types [Organisation] treats as sensitive, such as payment card numbers and national identifiers (18.1v1), with the action set to block once tested (18.2v1). See the Data Loss Prevention (DLP) Guide.
- Google Takeout is disabled for users (12.1v1), removing a one-click bulk export path for a compromised account or a departing employee.
- Data region policy matches [Organisation]'s residency requirements, and data is processed in the region chosen for data at rest (15.1v1, 15.2v1; SCuBA requires the United States for federal tenants).
- Google services without their own control are off for everyone unless approved (16.1v1); Early Access apps are off (16.2v1); Looker Studio sharing outside the organisation is off (16.3v1).
- Gemini and other AI features are switched on only for approved OUs after review. See the Gemini for Google Workspace Security Guide.
9. Alerting, logging and retention
- The system-defined alerting rules SCuBA lists are enabled with alerts sent to [Security team] (13.1v1). Review the remaining system-defined rules and enable those that apply.
- Admin, Enterprise Groups, Login, OAuth Token, SAML and Context-Aware Access audit logs are streamed to [SIEM] (14.1v1), through BigQuery export or the Reports API. See the Google Workspace Audit Log Detection Guide.
- Audit logs are searchable for at least 3 months and retrievable for at least 12 months (14.2v1). Do not rely on the Admin console's own retention window alone.
- Detections exist at minimum for: changes to 2SV or SSO settings, new super admin grants, new domain-wide delegation grants, OAuth grants of Gmail or Drive scopes, new mail forwarding, and suspicious login alerts.
10. Governance and continuous assessment
- The ScubaGoggles assessment (or an equivalent CIS benchmark scan) runs at least quarterly, and results are compared with the previous run to catch drift.
- Every accepted deviation has a written reason, compensating control, owner and review date.
- Admin changes to security settings follow change management and are reconciled against the Admin audit log monthly.
- Leavers lose access the same day, including transfer of Drive ownership, removal of app passwords, OAuth tokens and delegated access. See the Employee Offboarding Security Checklist.
- A tested response plan exists for tenant compromise. See the Google Workspace Compromise Playbook.
Implementation guidance
Which baseline to align with. Both main references are free to read and overlap heavily. Choose based on who asks for evidence.
| Reference | Publisher and form | Assessment tool | Best fit |
|---|---|---|---|
| SCuBA Secure Configuration Baselines for Google Workspace | CISA; markdown baselines per service (Common Controls, Gmail, Drive and Docs, Calendar, Chat, Meet, Groups, Classroom, Sites, Assured Controls) with SHALL/SHOULD policies and NIST SP 800-53 mappings | ScubaGoggles, CISA's open source assessment tool | Federal agencies under BOD 25-01, organisations that want policy IDs and mappings to 800-53 |
| CIS Google Workspace Foundations Benchmark | Center for Internet Security; current version 1.4.1 at the time of checking | CIS tooling or third-party scanners that implement the benchmark | Organisations already reporting against CIS Benchmarks or CIS Controls |
Rollout order. Changing these settings can lock users out or break integrations, so stage it:
- Run a baseline assessment and export the results. Inventory OUs, super admins, OAuth apps, domain-wide delegation grants, forwarding rules and users with POP, IMAP or app passwords.
- Fix sections 2 and 9 first: super admin hygiene and log export cost little, rarely break anything and give you visibility for everything after.
- Pilot 2SV changes and app access blocking in a test OU of IT staff for two weeks. Check the OAuth Token audit log to find apps that would be blocked before you block them.
- Roll out by OU in rings (IT, then one business unit, then everyone), with a named rollback: each setting can be reverted at the OU where it was applied. Keep a break-glass super admin outside the rollout OUs.
- Switch DLP and Gmail quarantine actions from warn or audit to block only after reviewing two to four weeks of matches.
- Rerun the assessment, record deviations and schedule the quarterly rerun.
Threat to check mapping. Use this to explain to stakeholders why a setting matters.
| Threat | MITRE ATT&CK | Checklist sections | NIST SP 800-53 Rev. 5 |
|---|---|---|---|
| Credential phishing of users and admins | T1566 Phishing; T1078.004 Cloud Accounts | 1, 2, 5, 6 | IA-2(1), AC-6(5) |
| Malicious or over-scoped OAuth apps | T1528 Steal Application Access Token | 4, 9 | AC-6(5), SI-4(5) |
| Mailbox takeover with forwarding | T1114.003 Email Forwarding Rule | 6, 9 | SC-7(10) |
| Bulk data theft from Drive | T1530 Data from Cloud Storage | 7, 8 | AC-21, SC-7(10) |
| Attacker disables alerts or logging | T1685 Disable or Modify Tools | 2 (multi-party approval), 9 | SI-4(5), AU-11 |
In NIST CSF 2.0 terms, sections 1 and 2 support PR.AA-03 (users, services and hardware are authenticated), sections 3 to 8 support PR.PS-01 (configuration management) and PR.DS-01 (data at rest), and section 9 supports DE.CM-03 (monitoring personnel activity and technology usage).
Small versus large organisations. A small business on Business Starter or Standard may lack context-aware access, DLP and security sandbox; meet sections 1, 2, 4, 5, 6 and 9 fully and record the edition gap. Large organisations should drive the checklist from OUs and groups, assess each OU separately, and automate the quarterly rerun so results feed the risk register.
Common failure patterns.
- Correct at the top, wrong below: a child OU created for contractors or a pilot overrides 2SV or sharing settings and is never reviewed.
- Super admin sprawl: former IT staff, a reseller and an integration account all hold super admin, and none use security keys.
- App access left at default: unconfigured apps are allowed, so any user can grant a third-party app read access to mail. See the Consent Phishing and Illicit OAuth Grants Guide.
- Forgotten delegation: domain-wide delegation granted years ago to a service account whose key still sits in a repository.
- Logs never leave Google: the investigation starts after the retention window has already removed the first malicious login.
Metrics: percentage of users and of admins enforced on security keys or passkeys; number of super admins (target two to eight); OAuth apps with Gmail or Drive scopes that are not Trusted or Specific Google data (target zero); external forwarding rules (target zero unless approved); ScubaGoggles SHALL pass rate per OU; and days since the last full assessment.
References: CISA: ScubaGoggles and SCuBA Google Workspace Secure Configuration Baselines · CISA: Secure Cloud Business Applications (SCuBA) Project · CISA: BOD 25-01 Implementation Guidance · CIS: Google Workspace Foundations Benchmark · Google: Deploy 2-Step Verification · Google: Control which apps access Google Workspace data · NIST: SP 800-53 Rev. 5 · MITRE ATT&CK: Email Forwarding Rule
This template is provided for guidance and must be adapted to your organisation and Workspace edition; setting names change as Google updates the Admin console. Related NHI Mgmt Group resources: Google Workspace Security Guide · Top 10 Google Workspace Security Mistakes · SaaS and OAuth App Governance Guide · DMARC, SPF and DKIM Guide