Google publishes two versions of its Workspace security checklist, one for small businesses with fewer than 100 users and another for medium and large organizations. Both are organized as feature inventories: lists of settings an admin can enable, grouped by product area, with links into the admin console. An admin who works through every item ends up with a tenant where the available controls are turned on, and that feels like progress. It is progress, but a completed Google security checklist is a setup inventory, while a security assessment is a different exercise entirely, and the difference matters.
A setup inventory tells you what to enable. A security assessment tells you whether what you enabled actually protects the organization given its size, its data, its compliance obligations, and the way people actually work. The checklist can't know that your sales team shares Drive folders with 40 external domains, or that a former contractor's OAuth tokens are still active, or that the DLP rule you enabled last quarter has never fired because the content detectors don't match your actual sensitive data patterns. Those are contextual gaps, and they survive every checkbox.
Google's checklist for medium and large businesses splits its guidance into two broad sections: "Security best practices, Setup" and "Next steps, Monitoring, investigation, and remediation." The structure looks balanced on the page, but in practice it creates a subtle problem. Setup tasks are finite. You enable 2-step verification, configure session lengths, restrict OAuth scopes, and you're done. Monitoring tasks are ongoing and open-ended, yet the checklist presents them in the same format: a list of items to review, each with a link. An admin checking boxes can mark the monitoring section complete after a single pass through the security dashboard and the email log search.
The consequence is that monitoring decays into a one-time event. Nobody schedules the recurring review of mobile devices associated with accounts, or the weekly check of delivery logs for anomalous routing. The security report that's supposed to evaluate domain exposure to data security risks gets opened once, skimmed, and never revisited. Meanwhile, the tenant drifts. New OAuth grants accumulate, sharing permissions widen, and the gap between the configuration snapshot the checklist captured and the live state of the environment grows wider every month.
Some checklist items read like straightforward toggles but carry significant operational dependencies that the checklist never surfaces. Client-side encryption is the clearest example. The checklist includes it as a line item for Drive, Gmail, Calendar, and Meet, but enabling CSE requires an external key service and identity provider configuration. In most deployments, the encryption keys live outside Google's infrastructure by design, which means the organization is now responsible for key availability, backup, and rotation. If the external key service goes down, encrypted files become inaccessible. If the identity provider integration breaks, users can't decrypt anything. None of that complexity is visible from the checklist entry.
Context-Aware Access presents a different kind of risk. The checklist lists it alongside other access controls, but access levels in Workspace are a shared resource. A single access level can be assigned to multiple apps simultaneously, and deleting or modifying that level affects every app that references it. An admin who creates a restrictive access level for Drive and later assigns the same level to Gmail and Meet has built a single point of failure. One change to the access level's IP range or device policy cascades across the entire application surface. Teams that enable Context-Aware Access without mapping these dependencies first tend to discover them during an outage, which is the worst possible time.
The pattern is consistent: the checklist tells you a control exists and links to the page where you enable it. It doesn't tell you what breaks if you enable it without planning, and it doesn't tell you what other controls it depends on or shares state with.
The Google security checklist lists DLP rules and Context-Aware Access as independent line items under separate headings. An admin working through the list enables DLP content detectors for Drive and Gmail, then separately configures access levels for device trust or network location, and checks both boxes. In isolation, each control does useful work. DLP scans content and blocks or warns on sensitive data. Context-Aware Access restricts where and how users can reach applications.
The compounding benefit comes from layering them. A DLP rule that blocks credit card numbers from leaving Drive is stricter when it's paired with a Context-Aware Access policy that already prevents unmanaged devices from reaching Drive in the first place. The DLP rule handles the content; the access policy handles the context. Together, they reduce the attack surface that either one has to cover alone. In practice, organizations that treat these as separate checkboxes end up with DLP rules that fire on managed corporate laptops (where the risk is lower) and no access restrictions on the personal devices where the risk is higher. The checklist format, by separating them into different sections, makes this misalignment easy to create and hard to notice.
SPF, DKIM, DMARC, BIMI, and S/MIME appear as individual items in the checklist, and each one links to its own setup page. The problem is that these protocols form a dependency chain, not a feature list. SPF authorizes sending servers. DKIM signs messages so recipients can verify they haven't been altered. DMARC tells receiving servers what to do when SPF or DKIM checks fail. BIMI builds on a DMARC policy at enforcement to display a verified brand logo. S/MIME adds end-to-end message encryption on top of everything else.
Partial implementation is common and quietly dangerous. An organization that publishes an SPF record and enables DKIM signing but sets its DMARC policy to "none" has technically checked three boxes while gaining almost no protection against spoofing. Receiving servers see the DMARC record, note the policy is passive, and deliver spoofed messages anyway. The admin who checked those items has no reason to revisit them, because the checklist doesn't explain that a DMARC policy of "none" is a monitoring mode, not an enforcement mode. Moving from "none" to "quarantine" to "reject" is a phased process that requires reviewing aggregate and forensic reports over weeks, and the checklist gives that process exactly zero guidance.
Gemini controls appear in the checklist as line items, but the guidance stops at the toggle. There's no checklist-style framework for assessing what data Gemini can reach once it's enabled, what prompt injection exposure looks like inside a Workspace tenant, or how to scope AI access before rolling it out broadly. This is a meaningful gap because Gemini in Workspace doesn't operate in a vacuum. It reads Drive files, summarizes Gmail threads, and surfaces information from across the tenant based on the user's existing permissions.
The risk is that Gemini makes existing permissions more consequential. A user who technically had access to a shared Drive folder but never opened it now gets that folder's contents surfaced in a Gemini summary. Oversharing that was invisible becomes visible. For organizations that haven't audited their sharing permissions recently, enabling Gemini can expose internal data patterns that were hidden only by the friction of manual search. The Google security checklist doesn't address this because it's a configuration concern, not a feature toggle, and configuration concerns require context the checklist doesn't have.
Several controls appear in the checklist as navigation links with no explanatory prose. Multi-party approval for sensitive admin actions is one. When enabled, it requires a second administrator to confirm high-risk changes like modifying 2-step verification settings or changing account recovery options. Without it, a single compromised admin account can disable security controls across the entire tenant before anyone notices. The checklist links to the feature but doesn't explain why it matters or what operational changes it requires, so most admins skip it.
Automated account suspension for logins from specific IP addresses is another. This control lets admins define IP-based rules that automatically suspend accounts showing suspicious login patterns. It's a powerful early-response mechanism, but it requires careful scoping: suspend too broadly, and you lock out a remote office; suspend too narrowly, and the rule never fires. Classification labels for Drive and Gmail fall in the same category. Labels let organizations tag documents and messages by sensitivity level, which feeds into DLP rules and sharing restrictions. Without labels, DLP rules rely entirely on content detection, which means they miss sensitive documents that don't contain recognizable patterns. The checklist includes all three controls and explains none of them.
Organizations working toward SOC 2, ISO 27001, or HIPAA compliance often use the Google security checklist as a starting point, which is reasonable but incomplete. Some checklist items carry direct audit weight: enforcing 2-step verification maps to access control requirements across all three frameworks, and DLP rules with logging enabled support the data protection controls that SOC 2 and HIPAA both require. Email authentication at enforcement (DMARC set to reject) satisfies integrity controls in ISO 27001.
Other checklist items are hardening measures that improve security posture but don't correspond to specific audit controls. BIMI, for example, is a brand-protection feature, not a compliance requirement. The checklist doesn't distinguish between these categories, so an admin prioritizing for compliance has no way to know which items an auditor will ask about and which are optional improvements. The practical consequence is wasted effort: teams spend time on low-audit-weight items while leaving high-weight controls partially configured. Mapping checklist items to the specific framework you're targeting, before you start working through them, saves significant rework later.
A structured security assessment evaluates configuration in context. Instead of asking whether a control is enabled, it asks whether the control is configured correctly for the organization's size, user behavior, data sensitivity, and compliance obligations. It identifies interdependencies between controls, like the relationship between Context-Aware Access levels and the apps that reference them, or the gap between DLP rules and the classification labels that make them effective. And it produces a prioritized remediation list: a sequence that accounts for operational risk, implementation complexity, and audit weight.
The Google security checklist is a useful starting point. It ensures admins know what controls exist and where to find them. It can't replace the judgment calls that come from evaluating a live environment: which OAuth grants represent real risk, which sharing patterns need immediate attention, which Gemini access scopes are too broad for the data they reach. Those are assessment questions, not checkbox questions.
Suitebriar, a Google Cloud Premier Partner and Workspace reseller that has served more than 1,000 organizations, conducts this kind of contextual Workspace security assessment. The output is a prioritized remediation plan built around how the organization actually uses Workspace, what compliance frameworks apply, and where the real exposure sits. If your team has finished the checklist and wants to know what it missed, that's the right next conversation to have. Get in Touch to start one.