How Do You Use Google Vault to Manage Records Retention and Legal Holds?

Detailed Explanation

Most small businesses only think about email or document retention reactively — a lawyer calls asking for everything related to a dispute, or an insurer asks for records going back several years, and someone starts manually searching mailboxes and shared drives under time pressure. Google Vault turns that reactive scramble into something configured once and enforced automatically for every Google Workspace business and enterprise plan that includes it.

This is the Google-side counterpart to the retention question how do you automate document retention and archival policies covers at the platform-agnostic level — that page sets out how to design a retention schedule in the first place (what to keep, for how long, and why); this page covers the specific mechanism Google Workspace provides to actually enforce one.

Retention Rules

A retention rule tells Vault how long to preserve a given data type for a given scope, then what happens once that period lapses:

Scope. Rules can apply to the whole organisation, a specific organisational unit (an "Accounts" OU or a "Sales" OU, for example), or a group — letting different retention periods apply to different parts of the business without a single blanket policy trying to fit everyone.

Data type. Separate rules exist for Gmail, Drive, Chat, Meet recordings, and other covered Workspace services, since a business often needs different retention lengths for different kinds of record — client correspondence might need 7 years, general internal chat far less.

Duration. A rule can be finite (a fixed number of days or years) or indefinite. While a rule is active, the covered data stays recoverable in Vault even if the user deletes their own copy — this is the key mechanism: retention doesn't depend on a user (or an ex-employee) not deleting something, because Vault keeps its own copy independent of what happens in the user's mailbox or Drive.

What happens at expiry. Once a retention period lapses and no legal hold applies, the data becomes eligible for permanent removal from Vault. Google Workspace's own admin documentation sets out the current exact expiry and purge behaviour — worth reviewing before setting a long or indefinite rule, since indefinite retention has its own storage and discoverability trade-offs.

Legal Holds

A legal hold is a separate, more targeted tool. Where a retention rule is a standing policy, a hold is usually triggered by a specific event: a piece of litigation, an internal investigation, a regulatory request, or a departing employee whose data needs to be preserved beyond the point their account would normally be suspended or wiped.

A hold can be placed on an individual account, an organisational unit, or a group, and it overrides everything else — any retention rule's expiry, and any deletion the user themselves attempts. Data under an active hold stays preserved and searchable in Vault until an admin explicitly releases the hold. This is the standard first step once a business becomes aware that specific records may be relevant to a legal or regulatory matter — the sooner a hold is placed, the less risk of relevant data being lost to routine deletion in the meantime.

Setting This Up

1. Confirm Vault is included in the current plan. Vault ships with most Google Workspace Business and Enterprise plans; availability and any per-plan limitations are worth confirming against Google's current plan comparison before designing a retention schedule around it.
2. Design the retention schedule first, separately from the tooling. Use the same process how do you automate document retention and archival policies describes — figure out what needs to be kept, for how long, and why (legal, tax, contractual, or business need) — before configuring a single rule in Vault. The schedule is a business decision; Vault is just the enforcement mechanism.
3. Create retention rules matching that schedule, scoped by organisational unit and data type, in the Admin Console's Vault settings.
4. Assign a specific person or role as Vault's day-to-day owner — someone who knows how to place a hold quickly when a legal or HR situation requires it, since a hold placed a week late has already missed a week of protection.
5. Document the process for placing and releasing a hold, including who can authorise one — this typically sits with whoever handles legal, HR, or compliance matters, not IT alone, since the trigger is usually a legal or people situation rather than a technical one.

Things to Consider

• Vault preserves data; it doesn't back it up in the disaster-recovery sense. See the FAQ above — if the concern is accidental deletion or corruption rather than legal preservation, that's a separate backup-and-restore question, not a Vault one.
• A departing employee is a common, low-drama reason to use Vault, not just litigation. Placing a hold on an employee's account before offboarding preserves their Gmail and Drive content independent of what happens to their account afterwards — see how do you automate Google Workspace user provisioning and deprovisioning for where this fits in the wider offboarding process.
• Indefinite retention has a real cost beyond storage. Every record Vault keeps is also a record that could need to be searched, reviewed, and potentially produced later — a genuinely indefinite rule should be a deliberate choice for records that need it (some financial and compliance records do), not a default applied everywhere out of caution.
• Coverage of newer Workspace surfaces keeps expanding. Vault's support for the Gemini app's conversations, for example, was a 2026 addition rather than something the tool has always covered — confirm current coverage against Google's own Vault documentation before assuming a newer feature or app is included.

Common Mistakes

• Treating Vault as a backup tool. Businesses sometimes assume Vault protects against accidental deletion the way a backup does — it's built for legal preservation and eDiscovery, with its own separate purpose and access model, not for a user restoring an accidentally deleted file themselves.
• No named owner for placing a hold quickly. If nobody specific is responsible for Vault, a hold that should have gone on immediately after a dispute arose sits unactioned for days or weeks while people figure out who has access — assign this before it's needed, not during an actual incident.
• Setting one blanket retention rule for the whole organisation. Different organisational units genuinely need different retention periods (finance and HR records typically need longer retention than general internal chat) — a single rule for everyone is usually either too short for the records that need longer retention or unnecessarily long for everything else.
• Forgetting to release a hold once it's no longer needed. An old hold left in place indefinitely keeps preserving (and growing) a dataset that no longer needs the protection, with no one revisiting whether it's still required — review active holds periodically rather than treating "place and forget" as the end of the process.