Locking Down Gemini: The Admin Controls That Actually Matter

Locking down Gemini in Google Workspace isn’t one setting. It’s six separate controls that each govern a different surface, layered in a specific order where some override others entirely. Configuring one and assuming it covers the rest is the most common way an admin ends up with a governance picture that looks complete and isn’t.

This puts every control in one place, in the order that actually matters, and names the two gaps documented elsewhere in this series that no combination of these settings closes on their own.

The Six Controls

1. Per-app access

Administrators can enable or disable Gemini features and the side panel independently in Gmail, Drive, Docs, Meet and Chat. This is the coarsest control, an on/off switch per product, and the first place to look if the goal is simply preventing Gemini use in a specific tool entirely.

2. Gemini Notebook access

Separate from the five products above, Gemini Notebook has its own on/off toggle, scopable to a specific organisational unit or group. This is worth treating as genuinely separate rather than assuming it’s bundled with the general Gemini toggles, particularly given the data residency gap documented elsewhere in this series.

3. Data regions

For the Gemini app, admins can configure EU-only storage and processing, US-only, or both, down to the organisational unit level. This control explicitly does not extend to Gemini Notebook, which operates outside data region rules entirely regardless of how this setting is configured.

4. Temporary chats and user deletion

Two toggles, scoped domain-wide, by organisational unit, or by configuration group (with groups overriding organisational units): whether users can start chats that don’t save to their activity, and whether they can delete their own conversation history.

5. Automatic retention periods

Absent Vault governing retention, admins can set conversations to auto-delete based on inactivity, at 3 months, 18 months, or 36 months, or choose to retain them indefinitely. This is the default retention behaviour that applies when nothing stronger is configured.

6. Vault retention and holds

The strongest control on this list, and the one that overrides every setting above it when active. Vault rules take precedence over admin console settings and user settings entirely. Its documented scope, however, is the standalone Gemini app specifically, not every surface Gemini touches.

What Actually Overrides What

These six controls aren’t six independent dials. They form a hierarchy, and knowing which sits above which prevents the common mistake of configuring a lower-level setting and assuming it’s the final word.

Who Should Actually Own Each Piece

These six controls rarely sit with one person in a real organisation, which is part of why gaps open up between them. Recognising who typically owns each decision helps explain why coordination, not just configuration, is the actual work involved.

The pattern worth noticing: the further down this list, the more the actual decision belongs to legal or compliance rather than IT alone, even though IT is who executes the configuration in every case. An organisation where IT configures Vault retention without legal’s specific input on scope and duration is optimising for technical correctness while potentially missing the actual compliance requirement driving the need for it in the first place.

The Checklist, in Practice

Working through this in a specific order avoids the two most common configuration mistakes: assuming coverage that isn’t there, and setting controls that get silently overridden by something configured elsewhere.

• Start with per-app access. Decide which of Gmail, Drive, Docs, Meet and Chat should have Gemini available at all, before configuring anything downstream.
• Decide on Gemini Notebook separately. Given its documented exemption from data region and sharing rules, this deserves its own explicit decision rather than inheriting whatever the general Gemini toggles are set to.
• Set data regions if regional compliance matters. Remembering this doesn’t reach Notebook, which needs its own separate handling.
• Configure temporary chats and deletion for genuine user privacy needs, understanding these get overridden the moment Vault retention or a hold applies.
• Set a default retention period for the baseline case where nothing stronger governs a conversation.
• Layer Vault retention or holds on top for anything requiring actual legal preservation, knowing this covers the standalone app and not embedded features elsewhere.

Why This Needs a Checklist Rather Than a Single Toggle

It’s worth pausing on why Google spread this across six separate controls instead of offering one master switch for Gemini governance, since understanding the reasoning makes the checklist easier to apply correctly rather than by rote.

Each of the six controls addresses a genuinely different kind of decision. Per-app access is a product decision, whether Gemini belongs in a specific tool at all. Data region is an infrastructure decision, where processing physically happens. Retention and Vault are legal and compliance decisions, how long content exists and who can reach it later. Temporary chats and deletion are user experience decisions, how much control an individual has over their own activity.

Collapsing these into one setting would force every organisation into the same answer across four or five genuinely separate questions, when in practice an organisation might reasonably want Gemini fully available in Docs but restricted in Chat, EU-only processing but a generous retention window, or user-controlled deletion for routine work paired with mandatory holds for a specific legal matter. The six-control structure exists because these are six different questions with six different right answers depending on context, not because Google made governance unnecessarily complicated.

Revisiting the Checklist Over Time

None of these six controls, or the two gaps sitting outside them, are fixed permanently in their current form. Google continues actively developing Gemini’s governance surface, and both gaps documented in this series, Vault’s app-only scope and Notebook’s residency exemption, are the kind of thing Google has a track record of eventually extending or closing as the product matures.

A checklist configured correctly today against today’s documentation can become incomplete or, less commonly, unnecessarily restrictive as Google’s own controls evolve. Treating this as a living configuration, reviewed on a fixed schedule, whether quarterly or aligned to a broader compliance review cycle, catches drift in either direction before it becomes a problem discovered during an actual incident or audit.

The specific numbers and boundaries documented across this series were all verified directly against Google’s own admin documentation at a specific point in time. Before relying on any of them for an actual compliance decision, confirming against the current state of that documentation is worth the few minutes it takes, particularly given how much this exact area has already changed in the recent past.

Common Questions

The Short Version