Google Workspace Security: What You Can (and Can't) Turn On, By Edition

Most Google Workspace security guides are written for Enterprise customers, which is a strange choice given that most Workspace customers aren’t on Enterprise. If you’re on Business Starter, Standard, or Plus, half of what you read gets recommended and then turns out to be a setting you can’t find — because it doesn’t exist on your plan.

This guide is organized the other way around: what you can turn on today, on the edition you’re actually paying for, and exactly where the real upgrade boundaries sit. Every claim about edition availability below is checked against Google’s own current edition comparison pages, not carried over from a blog post written when the tiers looked different.

The frameworks this maps to

Three references sit behind this guide, and it’s worth being precise about what each actually is:

• Google’s own security checklists — a short one for small businesses (1–100 users) and a much longer one for medium/large businesses (100+ users), which we drew the control list from directly.
• The CIS Google Workspace Foundations Benchmark (currently v1.4.0) — a vendor-neutral configuration standard covering Accounts, Gmail, Drive and Docs, Calendar, and Applications. We organize this guide’s sections along the same lines.
• NIST’s Cybersecurity Framework (CSF) — used here as an organizing lens (Identify, Protect, Detect, Respond, Recover), not as a Workspace-specific benchmark. NIST doesn’t publish one of those; CIS does. Where a control fits one of the five CSF functions, we say so — it’s the vocabulary most audit conversations already use.

Edition availability, at a glance

Bookmark this table. Every section below refers back to it instead of repeating the same caveat five times.

Cloud Identity Premium, sold as an add-on to any Business edition, brings Context-Aware Access into reach without a full Enterprise upgrade.

What this actually costs

We sell Workspace, so this table is the one section here with a direct commercial angle — worth saying plainly rather than pretending it isn’t. Pricing below is per user/month, in USD, as published by Google at the time of writing; both vendors adjust list pricing periodically, so treat this as directionally accurate and confirm current numbers before it goes into a quote.

Two things worth flagging on this table specifically:

• The annual-vs-flexible gap is consistent at roughly 20% across every Business tier — the flexible plan trades that premium for the ability to add or remove seats and cancel anytime, which matters more for a company still finding its headcount than for one that’s stable.
• Enterprise has no public list price by design — it’s negotiated per deal, scaled by seat count and term. Third-party aggregators sometimes publish ballpark figures (we’ve seen $9–10/user/month quoted for 500+-seat deals), but treat any number you see outside an actual Google quote as a rough directional estimate, not something to build a proposal on.

Identify & Protect: identity is still the perimeter

Every account-takeover path Google’s threat intelligence team talks about publicly starts the same way: a password gets phished or reused, and there’s nothing else in the way. This is also the one category where every control is available on every edition, which makes it inexcusable to skip.

Enforce 2-Step Verification. Admin console → Security → Authentication → 2-Step Verification. Turn on enforcement, but don’t flip it for every user simultaneously — set a rollout date a week or two out so people enroll before it’s mandatory, and exempt no one who isn’t explicitly exempted in writing. Prefer security keys or the Google prompt over SMS codes; SMS is phishable via SIM-swap and real-time relay in a way a hardware key isn’t.

Enroll admins and executives in the Advanced Protection Program. Same console section. This is Google’s strictest account protection tier — hardware security key required, more aggressive OAuth app blocking — and it’s meant specifically for the accounts most worth attacking. Every super admin account should be enrolled; nothing about this requires Enterprise.

Set up SSO properly, even if you only have a handful of downstream apps. Admin console → Security → Authentication → SSO with third-party IdP (or Google as the IdP for SAML apps that support it). Centralizing authentication means a disabled Workspace account actually locks someone out of everything, instead of leaving five SaaS sessions alive.

Use least-privilege admin roles. Admin console → Account → Admin roles. Super admin should be a small, named list — not the default role handed to whoever set up the domain. Build custom roles scoped to what a person’s job actually requires (user management without billing access, for instance) rather than reaching for the built-in “Groups Admin” or “User Management Admin” roles as a shortcut.

Shorten session length instead of leaving Google’s default. Admin console → Security → Access and data control → Google session control. Two settings live here, and they’re easy to conflate:

• Web session duration controls how long someone stays signed into ordinary Google services — Gmail, Drive, Calendar — before being forced to re-authenticate. Google’s own default is 14 days, which is a long time for a stolen session cookie or an unlocked laptop to stay useful to whoever has it. Setting this to something short — a few hours, or “require re-authentication every time” for the most sensitive OUs — is available on every Business tier for Google Cloud services sessions, but the broader Google services session-length control (the one covering Gmail/Drive/Calendar sessions generally, not just the Cloud console) requires Business Plus or Enterprise.
• Admin console sessions are fixed at one hour and can’t be changed at all, on any edition — Google enforces that ceiling itself, precisely because it’s the highest-value session in the domain.

This is exactly the setting behind the “short session length” recommendation for admin accounts a few sections down: apply an aggressive override to the Organizational Unit holding your admin-only accounts specifically, rather than shortening it for the whole company and generating a support ticket every time someone’s regular workday session times out.

Super admin architecture: the A/B account model and a real break-glass account

Everything above is available on every edition. So is this — it’s pure account architecture, no license required — and it’s the single highest-leverage thing on this page that most SMB Workspace deployments skip entirely.

The problem it solves. If a person’s day-to-day identity — the one that receives email, has browser extensions installed, grants OAuth consent to random SaaS tools, gets targeted by every spearphish aimed at the company — is also the account with Super Admin rights, one successful phish takes over the entire domain. Google’s own guidance is direct about this: “Give super admins a separate account that requires a separate login,” specifically so admins “use a separate user account for day-to-day activities and only sign in to their super admin account when they need to perform specific super admin duties.”

The A/B account pattern. Practitioners commonly describe this as two accounts per admin, not one:

• Account A — the person’s normal identity ([email protected]). Gmail, Calendar, Drive, day-to-day work. No admin privileges at all.
• Account B — a dedicated admin-only account, deliberately not named anything predictable like [email protected] — an obvious “-admin” suffix is exactly the pattern an attacker enumerates first. Something like [email protected] instead: Super Admin (or a scoped custom role), and nothing else — no inbox anyone emails, no OAuth grants to productivity add-ons, no mobile app installs. Signed into only for the specific admin task at hand, then signed back out.

The advantage isn’t just “two passwords instead of one.” Account B is structurally a smaller target — it never appears in a phishing campaign’s target list because it never receives ordinary mail, never touches a browser extension, never shows up in a breached-password dump tied to some other SaaS signup. Put every “B” account in its own Organizational Unit and you can apply the strictest policy in the domain to exactly that OU — hardware-key-only 2SV, short session length, no mobile sign-in — without touching the daily productivity experience of anyone’s “A” account, including the same person’s own.

Why a break-glass account is a different thing again. Even with disciplined A/B accounts, every admin login still depends on that specific person being reachable — a hardware key gets lost, someone leaves without offboarding cleanly, or the identity provider itself has a bad day. A break-glass account is a separate, sealed emergency credential: a Super Admin login nobody uses for routine work, stored offline (a sealed envelope in a physical safe, or split-knowledge between two people), with any sign-in to it treated as an active incident the moment it happens — an Alert Center rule watching that one account specifically is a five-minute setup on any edition.

One genuinely debated point here: whether to exclude that single sealed account from 2-Step Verification. The standard advice on this page is “enable 2SV everywhere, no exceptions” — and for every actively-used admin account, including your B accounts, that’s correct. But for the one true break-glass account that exists solely to survive a scenario where your normal 2SV method is itself unavailable (every hardware key in the building, an IdP outage, a disaster scenario), some security teams — echoing the same pattern Microsoft documents for Entra ID break-glass accounts — deliberately carve out an exception: one account, an extremely long randomly-generated password, sealed physical storage, and aggressive monitoring standing in for the second factor. Reasonable programs land on either side of this; the wrong answer is not having thought about it at all.

It ties back to how Google handles SSO, too. Super admin accounts bypass your third-party identity provider by design — they authenticate directly with their Google password, not through the SSO flow, specifically so an IdP outage can’t lock every admin out simultaneously. That’s precisely why your break-glass account’s own Google-side protection is what has to hold up on the worst day, not your IdP’s.

Protect: email, still the number-one attack surface

Authenticate outbound mail with SPF, DKIM, and DMARC. This is DNS configuration, not a Workspace feature — it works identically regardless of edition. If you haven’t set a DMARC policy stricter than p=none, spoofed mail from your own domain is currently someone else’s problem to notice, not yours to prevent. Google’s own authentication guide walks through the DNS records; get DMARC to p=quarantine or p=reject once DKIM/SPF alignment is confirmed clean.

Turn on Security Sandbox if you’re on Standard, Plus, or Enterprise. Admin console → Apps → Google Workspace → Gmail → Safety. This detonates attachments in an isolated environment before delivery — the closest thing Workspace has to a malware sandbox, and it’s a genuine gap on Starter, where it isn’t available at any price without upgrading the tier.

Disable automatic forwarding and lock down IMAP/POP where you don’t need them. Same Gmail settings area. Both are available on every edition and both are common post-compromise persistence tricks — a forwarding rule quietly added after a phishing hit is one of the more common ways an attacker keeps reading mail after the password’s been changed.

Restrict Drive sharing before you reach for DLP. Admin console → Apps → Google Workspace → Drive and Docs → Sharing settings. Set external sharing to “Trusted domains only” or build trust rules, default new-file access to restricted, and turn off the ability to publish files to the web. None of this requires Enterprise, and for most Business-tier customers it closes more real exposure than DLP would.

Protect: the Enterprise-only layer, if you actually need it

Two controls are worth naming specifically because they’re where “we should upgrade” conversations usually start:

Context-Aware Access lets you require, for example, that access to Drive from outside a corporate IP range also requires a managed, encrypted device. It doesn’t exist on any Business edition — not even Plus — only on Enterprise Standard/Plus, Cloud Identity Premium, and a few other premium SKUs (Frontline Plus, Education Plus). If this is the only reason you’re considering Enterprise, Cloud Identity Premium as an add-on is usually the cheaper path to the same entitlement.

Data Loss Prevention for Gmail, Drive, and Chat — content-based rules that block or warn on sensitive data leaving the organization — is Enterprise-only per Google’s current comparison page. If you’ve been told Business Plus includes DLP, double-check against the official comparison before you build a security narrative around it; several third-party guides get this wrong.

Securing Gemini, now that it’s part of every plan

Gemini shipped bundled into every paid Workspace tier at no extra charge — which means every admin, not just Enterprise ones, now has an AI governance surface to actually configure, whether or not anyone’s gotten around to it yet.

Know which control panel you’re in. Google currently splits this across two admin console areas, and it’s easy to configure one and assume you’ve covered both:

• Menu → Generative AI → Gemini app — the assistant experience inside Gmail, Docs, Drive, and Meet. Turn it on or off per Organizational Unit or configuration group, and separately toggle “Allow access to Workspace apps,” which controls whether Gemini can actually read and act on your Gmail/Drive/Calendar content versus operating as a standalone chat window.
• Menu → Generative AI → Gemini Enterprise — the agent-platform side (the same Agent Runtime this site’s Vertex AI/agent posts cover). This has its own unified on/off switches, and — as of a Google Workspace update this past month — its own Context-Aware Access policies, so Enterprise customers can require a managed device or a specific location before Gemini Enterprise access is granted, independent of the CAA policy protecting everything else.

On the “does it train on our data” question, get the actual wording, not the vibe. Google’s own FAQ states it plainly: “Submissions aren’t used to train models and are never reviewed by humans” and “None of your content is used for model training outside of your domain without permission.” That’s worth pulling directly into your own data-processing documentation or DPA file rather than paraphrasing from a vendor blog — including this one.

Set an explicit retention window instead of leaving the default. Gemini prompts and responses are retained for anywhere from 90 days to indefinitely, admin-configurable, with users able to delete their own conversation history unless an admin has turned that off. Pick a number that matches the retention posture you’ve already set for Gmail and Vault rather than leaving whatever Google defaults to.

Gemini inherits your existing DLP and data-region posture — it doesn’t add a new one. This is the detail worth sitting with: Gemini automatically applies whatever DLP rules and data-region policies your organization already has configured. If you’re on a Business tier without DLP (see above — that’s every Business tier, including Plus), Gemini doesn’t get some separate, safer AI-specific data boundary by default. It inherits the gap along with everything else. Fixing your underlying DLP and data-region configuration is, concretely, also fixing Gemini’s exposure — there isn’t a separate AI security project here so much as a reason to stop deferring the one you already had.

If you’re on Chrome Enterprise Premium, its DLP extends into the Gemini app in-browser specifically — copy/paste, printing, and upload/download restrictions on sensitive data apply there too, which is a meaningful extra layer for organizations that already standardized on managed Chrome.

Detect: alerting and audit, before you need them

The alert center is on every edition. Admin console → Security → Alert Center. Review it weekly at minimum, not just when something’s already gone wrong — it surfaces things like suspicious login attempts and mass file-sharing changes automatically. Set up admin email notifications for the alert types you actually want paged on, since the default noise level buries the signal for most small admin teams.

The audit and investigation tool is also available on every edition — Business tiers get log search and reporting; only Enterprise adds the “take action” layer (deleting a malicious email org-wide, ending a session, from inside the tool itself). Even the Business-tier version is worth a standing recurring check, not just an incident-response tool you remember exists after the fact.

Vault, starting at Business Plus, gives you retention policies and eDiscovery across Gmail, Drive, Chat, and Meet recordings. This is as much a compliance control as a security one — if a legal hold or an offboarding dispute ever requires reconstructing what an account did, Vault is the difference between a targeted search and a manual reconstruction from backups.

flowchart TD
    A[Start here: what do you actually need?] --> B{Basic account protection?}
    B -->|"2SV, SSO, basic MDM, phishing protection"| C[Any edition — Starter included]
    A --> D{"Attachment sandboxing,\nsingle data region policy?"}
    D -->|Yes| E[Business Standard or higher]
    A --> F{"eDiscovery, retention,\nadvanced mobile policies?"}
    F -->|Yes| G[Business Plus or higher]
    A --> H{"Context-Aware Access\nor DLP rules?"}
    H -->|Yes| I[Enterprise, or Cloud Identity\nPremium add-on for CAA only]

Mapping back to CIS and NIST

If you’re formalizing this into a policy document rather than just working through it as a checklist:

Common mistakes

• Buying Enterprise for one feature. Context-Aware Access alone doesn’t justify a full tier jump when Cloud Identity Premium gets you the same entitlement on top of your existing Business plan.
• Treating “Advanced phishing and malware protection” as sufficient on Starter. It’s genuinely good and it’s free on every tier, but Security Sandbox’s attachment detonation is a meaningfully different layer, and it isn’t available on Starter at any price — only by moving to Standard.
• Assuming Business Plus has DLP because a vendor’s marketing page implied it. Check Google’s own comparison page before you write that into a security policy someone will audit against.
• Rolling out 2SV enforcement instantly, org-wide, with no notice. It works, technically — and it also floods your help desk the same afternoon. Give people a real enrollment window.
• Never revisiting admin roles after the initial domain setup. The person who ran the original Workspace signup often keeps super admin indefinitely by default, long after their job stopped requiring it.
• Running admin tasks from the same account that reads email all day. If your only super admin login is also somebody’s daily driver, you don’t have an A/B account model — you have one account with too much power and too much exposure.
• Turning on the Gemini app org-wide before deciding whether it should see Workspace data. The on/off switch and the “access Workspace apps” switch are separate controls for a reason; flipping both by default is a decision, even if nobody made it on purpose.

References

• Security checklist for small businesses (1–100 users) — Google Workspace Admin Help
• Security checklist for medium and large businesses (100+ users) — Google Workspace Admin Help
• Compare Business editions — Google Workspace Admin Help
• Compare Enterprise editions — Google Workspace Admin Help
• CIS Google Workspace Foundations Benchmark — Center for Internet Security
• Context-Aware Access overview — Google Workspace Admin Help
• About DLP — Google Workspace Admin Help
• Prevent spam, spoofing & phishing with Gmail authentication — Google Workspace Admin Help
• Super administrator account best practices — Google Cloud Documentation
• Security best practices for administrator accounts — Google Workspace Admin Help
• Super administrator SSO — Google Workspace Admin Help
• Google Workspace with Gemini FAQ for Business — Google Workspace Admin Help
• Control Gemini App access to Workspace services — Google Workspace Admin Help
• Google Workspace pricing — Google
• Compare Cloud Identity billing plans — Google Cloud Documentation

Not sure where your own setup actually stands?

Mekas Cloud Services runs a free security assessment against everything covered in this guide — for Google Workspace and Microsoft 365 alike — and hands back a plain-English list of what's already solid and what to fix first, no obligation attached.

Get a free security assessmentCall +1 844-549-0999