Google Workspace Lockdowns: Hardening for SMEs and Regulated Teams

TL;DR

Google Workspace ships with sensible defaults and dangerous gaps. This article walks the hardening sequence we use on every tenant: the day-one baseline, the CIS Google Workspace Foundations Benchmark v3 controls that actually move the needle, Context-Aware Access policies, Drive DLP for credit cards and ZA ID numbers, sharing controls scoped per OU, and the more aggressive lockdowns for HR, Finance and Legal.

The day-one baseline

Before anyone touches Context-Aware Access or DLP, four things have to be true. If they aren’t, the rest is decoration.

2-Step Verification, mandatory, on every account. Admin console → Security → Authentication → 2-Step Verification → Allow users to turn on 2-Step Verification: enforced. Set an enforcement date 14 days out so users have time to enrol. After that date, a user without 2SV cannot sign in. No CEO exceptions. We’ve watched more than one CEO exception turn into a phishing claim.

Recovery email and recovery phone, both populated. Without recovery info, an account locked out of 2SV needs a super-admin reset, and that path is brittle on a Sunday night. Force users to set both on first login. Audit quarterly.

Suspicious-login alerts, on. Admin console → Reporting → Alert Center → confirm Suspicious login, Leaked password, User suspended for spam, Government-backed attack, and Account password changed are all enabled and routed to a real, monitored shared mailbox. Not a personal Gmail.

Admin notifications, on. Admin actions, super-admin sign-ins, OAuth grants from new apps: all routed to the same shared mailbox. If your tenant has no inbox watching admin events, you will find out about a breach from your bank, not your console.

While you’re in there, run the TamingDNS Google Workspace check to confirm SPF, DKIM and DMARC are correctly configured. A tenant sitting at p=none is a tenant where impersonation is invisible. The DMARC page goes deeper.

The CIS Benchmark controls that actually matter

The CIS Google Workspace Foundations Benchmark v3 is the closest thing to a vendor-neutral hardening checklist for Workspace. It covers nine sections: Account, Authentication, Application Permissions, Calendar, Drive and Docs, Gmail, Mobile, Sites, and User Settings. Here are the controls that move the needle.

Strong password policy (CIS 1.2.x). Minimum 14 characters where you can’t push to passkeys yet. Password reuse blocked. Workspace can’t enforce complexity rules the way Active Directory can; length plus 2SV does the heavy lifting.

2SV with security key for admins (CIS 1.3.x). Super admins should be on hardware security keys, not Authenticator codes. Admin console → Security → 2-Step Verification → Methods → Only security key, applied to the Super Admins OU. SMS as a fallback is forbidden under the benchmark. Yes, it’s painful for one engineer for one afternoon. Do it anyway.

Sharing outside domain restricted (CIS 5.1.x). Drive sharing default set to Off on the default OU. Specific OUs (Sales, Marketing) get a more permissive override where there’s a real business need. Link sharing default: Restricted. The benchmark is explicit on this: Anyone with the link must not be the default.

Session length (CIS 1.5.x). Web sessions for sensitive OUs: reduce from the default 14 days to 8 hours, or 1 hour for super admins. Yes, users will sign in more often. That’s the point.

OAuth app access (CIS 3.x). Trust internal apps, restrict third-party access by default. Any app requesting Drive or Gmail scopes goes through admin allow-listing. Without this, one user clicking Allow on a malicious OAuth grant gives an attacker full mailbox read for as long as the token lives. And tokens live a long time.

API access (CIS 1.6.x). Less-secure-app access off. Domain-wide delegation reviewed annually; orphaned service accounts revoked.

The full v3 PDF is free from the CIS website. We score every tenant we audit against it and present gaps as a numbered scorecard. Most SMEs we walk into clear about 60% on first scan. Two careful days gets that to 90%+.

Context-Aware Access

Context-Aware Access (CAA) is Workspace’s equivalent of Conditional Access in Microsoft. It sits on Enterprise Standard, Enterprise Plus, Cloud Identity Premium, and Education Plus. Not on Business Standard or Business Plus. If you need the policy engine and you’re on the Business tier, you’ll either upgrade the whole tenant or buy Cloud Identity Premium for the users who matter most. The Google Workspace SKUs explainer covers the licensing maths.

What CAA actually does: it conditions access to apps (Drive, Gmail, the admin console, third-party SAML apps) on signals about the device, the network, the location, and auth strength. Here are the policies we deploy on almost every tenant that has the licensing for it.

Deny Drive from non-corporate devices. Access level: Device must be company-owned AND Device encrypted AND Screen lock enabled. Apply to: Drive, Docs, Sheets, Slides, for the entire tenant. A personal laptop without the corporate management profile cannot open Drive. Not “asks for a password and probably gets in.” Cannot. The CAA evaluation happens before the auth challenge.

Require 2SV from outside the office. IP not in the office range triggers a 2SV challenge on every sign-in. Inside the office, the 30-day trusted-device window applies. Outside it, every session re-challenges. Cheap defence against credential stuffing from someone’s holiday accommodation Wi-Fi.

Shorter session duration for HR. HR OU gets a CAA policy with Reauthentication required every 4 hours. They handle payroll exports, ID copies, medical-aid attestations. A laptop left open at lunch shouldn’t give a passing colleague a four-day HR session.

CAA policies are evaluated in order, deny overrides allow, and apply at the OU level. Build them iteratively: audit mode first, then enforced. We’ve rolled CAA out too aggressively on a Friday afternoon and locked the COO out of mail at the airport. Don’t do that.

Drive DLP

Data Loss Prevention in Workspace runs on Drive (file content) and Gmail (message content). Both ship on Enterprise Standard and above. Check current SKU coverage before promising the board.

The detector library is what most people miss. Google ships predefined detectors for credit card numbers (PAN), South African ID numbers, passport numbers, IBAN, and more. The ZA ID detector is named South Africa: ID number and matches the 13-digit Luhn-checked format. Here are the starter rules we deploy on almost every regulated tenant.

Rule 1: Credit card numbers. Detector: Credit card number, threshold Very high confidence, scope External sharing. Action: Block sharing and warn admin. A user trying to share a Sheet containing real PANs to an external domain gets a hard block. Internal sharing gets a softer Warn so the legitimate finance flow isn’t broken.

Rule 2: ZA ID numbers, bulk threshold. Detector: South Africa: ID number, threshold 10 or more matches per file, scope External sharing. Action: Quarantine and require admin release. One ID in a contract is normal. A spreadsheet with 200 IDs heading outside the domain is a POPIA event in motion.

Rule 3: Custom regex for client account numbers. If your business uses an internal account number format, build it as a custom regex detector. Action: Warn user before sharing on internal, Block on external.

The action ladder runs Audit (log only) → Warn (user can override) → Block (no override) → Quarantine (admin must release). Start at Audit for a fortnight, read the false-positive rate, then ratchet up. Going straight to Block on a noisy detector turns the security team into a help desk.

Drive sharing controls

Sharing is where most SME breaches actually happen. Not zero-day exploits. A public link on a folder containing client data, indexed by Google, found by a researcher.

Link sharing off, by default, at the OU level. Default sharing for new files set to Restricted (only people added). Sharing outside the organisation set to Off on the default OU. The Sales OU gets an exception allowing specific external domains via the allow-list.

Allow-listed domains. Admin console → Apps → Google Workspace → Drive and Docs → Sharing settings → Trusted external domains. Add the explicit list of partner, supplier and client domains the business actually transacts with. Every other external domain falls to the Block tier. This is the control that stops “share to my personal Gmail to work over the weekend” without taxing legitimate external collaboration.

OU-scoped overrides. The OU structure becomes the policy fabric. Default OU: locked down. Sales: external sharing to allow-listed domains. Marketing: external link sharing permitted (they send press kits). Finance: external sharing off bar a named-domain list for the auditors. HR: external sharing off, full stop, plus DLP layers on top.

While tightening sharing, audit existing exposure. GAM’s print drivefileacls or the Drive Files shared externally report in the security investigation tool surfaces every file currently shared outside the domain. The first run on a tenant that’s never been audited routinely returns four-digit numbers.

Hardening for regulated teams: HR, Finance, Legal

A flat baseline applied tenant-wide is too loose for HR and too tight for Marketing. The fix is separate OUs with separate policy stacks.

Dedicated OU per regulated function. /Regulated/HR, /Regulated/Finance, /Regulated/Legal. Each OU inherits the tenant baseline and adds its own overrides. Policies attach to the OU, not to individual users, so headcount churn doesn’t drift the posture.

More aggressive Context-Aware Access. Regulated OUs get CAA policies others don’t: mandatory company-owned device for any access, 4-hour reauthentication, IP allow-list for specific apps. No personal-device session at all, not even with 2SV.

DLP rules per OU. Finance OU: PAN detection at very high confidence, action Block, no warn. Legal OU: detector for legal-hold labels applied via Drive; any external share of a labelled document is auto-quarantined. HR OU: ZA ID detector at threshold 1 or more, not 10 or more. Even a single ID leaving the OU goes to quarantine.

Vault retention. Each regulated OU gets its own retention rule. Finance: 7 years on Gmail and Drive (POPIA and tax requirements). Legal: indefinite hold on litigation matters via Vault holds. HR: 5 years on personnel records, then defensible deletion. Vault sits on Business Plus and Enterprise; if you’re on Standard with a regulated function, you have a compliance gap.

Drive labels. Beyond DLP detectors, Drive labels mark sensitivity (Confidential, Restricted, Public) and act as classification metadata. Labels can drive DLP rule conditions and Vault retention. Legal teams especially benefit because labels survive folder moves and copies.

The end state: a 30-person SME where Marketing can fling a press release at a journalist and HR cannot accidentally email a payroll spreadsheet to a personal address. Same Workspace. Different OUs.

How this scores against an underwriter’s questionnaire

A 2026 cyber-insurance questionnaire reads almost like a CIS scan. Do you enforce MFA on all users, including admins? With what factor? Do you restrict external Drive sharing? Do you have DLP rules for PII? Do you have Context-Aware Access policies? What is your Vault retention policy for finance and HR data?

A tenant hardened against the baseline above answers every line on the technology section without hesitation. 2SV mandatory: yes, security keys for admins. Sharing restricted: yes, allow-listed external domains, default OU locked. DLP: yes, deployed and tuned. CAA: yes, with details. Vault: yes, per-OU retention plus legal holds.

The underwriter doesn’t care that Workspace is “secure by default”. They care whether you configured it. Defaults aren’t evidence.

The cyber insurance and DMARC article covers the broader questionnaire, including DMARC, MFA scope and EDR coverage.

Learn the full sequence

A blog article is a survey. Clicking every screen, building OU hierarchies, writing GAM scripts, tuning DLP detectors over a fortnight of false positives: that takes weeks. We teach it as a course because the official Google admin training is built for certification, not for actually running a tenant.

The Taming Google Workspace for Admins course is the curriculum Paul built after a decade of running Workspace tenants. CIS controls walked through one screen at a time. CAA policy authoring with worked examples. DLP rule design including the false-positive triage cycle. OU strategy for regulated teams. It’s what we point internal IT teams at when they want to own this themselves rather than retain us for it.

Get a 60-minute hardening review

We run a 60-minute review against the CIS GWS Foundations Benchmark v3. You leave with a written scorecard (per-section pass/fail with evidence), the top three gaps to close ranked by risk, and a fixed-scope quote to close them. No commission-driven upsell. If your tenant scores 95% already, we say so and bill nothing.

Book the call or browse all OSH services.