Google Workspace Backup: Do You Need Third-Party Tools?

What Google Vault Actually Does

Google Vault is Google’s built-in information governance and eDiscovery tool, not a general-purpose data protection layer. It gives administrators three core functions: retain, search, and export, across a defined set of Workspace applications, and understanding those three verbs precisely is the starting point for every decision that follows in this article.

Retention, Holds, and Search, the Three Things Vault Is Built For

Vault’s job is narrow by design. Once an administrator sets a retention rule or places a hold on an account, organizational unit, or group, Vault preserves matching data behind the scenes, independent of whatever the end user does in their own view of Gmail, Drive, or Chat. This is the mechanism that lets legal and compliance teams say with confidence that a departing employee’s correspondence or a set of files relevant to an investigation still exists somewhere, even after the visible copy is gone.

Search sits on top of retention. Authorized Vault users can query preserved data by account, organizational unit, date range, or keyword, and most supported services accept Boolean search operators for narrowing results. Google frames this as the identification and preservation stages of the Electronic Discovery Reference Model, the industry-standard eDiscovery workflow, and Vault deliberately stops there rather than extending into the later review, analysis, and production stages that dedicated eDiscovery platforms handle. Export is the final piece: once a search returns the right result set, that data can be pulled into standard formats for legal review, a lawsuit, or an internal audit trail, including results tied to any licensed account in the domain.

Which Apps and Editions Actually Include It

Vault’s coverage is tied to specific Workspace apps and specific plan tiers, and both boundaries matter when you’re deciding whether you’re actually protected. On the app side, Vault supports Gmail, Google Drive, Google Chat, Google Meet recordings, Google Groups, and, as of a mid-2026 update, retention rules and litigation holds for the standalone Gemini app. However, this explicitly excludes Gemini features embedded inside other apps, such as “Help me write” in Gmail or Docs, since those interactions aren’t retained the same way. Voice for Google Workspace text messages, voicemails, transcripts, and call logs are also covered, but only for organizations with a Voice add-on subscription.

On the licensing side, Vault comes bundled at no extra cost with Google Workspace Business Plus and Enterprise editions. Organizations on Business Starter or Business Standard don’t get it by default and have to purchase Vault as a separate add-on license if they want it at all. Even then, coverage extends only to users individually assigned a Vault license; an admin without one can’t use the tool, and a user without one isn’t protected by it, regardless of the organization’s plan. This licensing detail alone explains why so many smaller Workspace deployments have effectively zero retention protection without realizing it.

Backup vs. Retention: The Difference That Trips Up Most Admins

The single most common misunderstanding about Google Workspace data protection is treating “Vault is retaining my data” as functionally equivalent to “my data is backed up.” The two concepts share a surface resemblance; both involve keeping copies of data around, but they solve different problems, protect against different failure modes, and recover data in fundamentally different ways.

What “Backup” Actually Means in Practice

A true backup solution creates independent, restorable copies of data on a defined schedule, stored separately from the live production environment, with the explicit purpose of putting that data back exactly where it was if something goes wrong. The test that separates backup from everything else is simple: can you point the tool at a specific mailbox, a specific date, and a specific state, and have it rebuild that mailbox to that exact point? Vault cannot do this. It’s explicitly designed to retain and export data outward for review, not to restore data into a live user account, a distinction Google’s own retention tooling doesn’t attempt to blur, even though the marketing language around “retention” often gets read that way by admins under time pressure.

This matters because the two failure modes, backup and retention, rarely overlap. Retention protects against scenarios such as someone trying to make data disappear, such as an employee deleting incriminating emails, a departing staff member wiping their Drive before offboarding, and the legal or compliance need to prove the data still exists and retrieve it for review. Backup protects against a completely different scenario: data that’s gone by accident, corruption, a sync error, or malicious action, where the actual operational need is to restore it to its original location so the business can keep functioning. Conflating these two needs leads organizations to believe they’re protected when they’re only covered for one.

Why Vault Gets Mistaken for Backup So Often

The confusion isn’t accidental; it’s structural. Vault genuinely does keep data that a user has deleted from their own view, and to someone unfamiliar with the underlying mechanism, “the data survived deletion” looks indistinguishable from “we have a backup.” The difference only becomes visible at the moment of recovery, which is exactly the worst time to discover it, since by then the assumption has usually gone unchallenged for months or years of normal operation.

There’s also a licensing-driven version of this confusion. Because Vault ships bundled into Business Plus and Enterprise at no additional line-item cost, it gets treated by procurement and IT as “the backup that’s already included,” simply because no separate purchase decision was ever made for it. A tool that genuinely requires a standalone backup product would prompt someone to evaluate whether it does what’s needed; a tool that’s already present by default rarely gets that scrutiny until an actual data-loss event forces the question. This is precisely why the rest of this article treats “does Vault cover this scenario” and “do I need something else” as two separate questions that deserve separate, deliberate answers rather than one assumed by default.

Where Vault’s Coverage Ends: Apps and Data It Doesn’t Touch

Even within its intended retention and eDiscovery role, Vault’s coverage has specific, documented gaps. Knowing exactly which apps and data types fall outside its scope is what lets you calculate real exposure, rather than guessing at it after something has already gone missing.

The Apps Vault Was Never Built to Cover

Vault does not support Google Keep or Google Classroom at all; content in either service sits entirely outside retention rules and holds, regardless of plan tier or license assignment. Calendar sits in a partial state: Vault can apply retention rules to calendar metadata but not to the full content of every calendar item, leaving a meaningful gap for organizations that rely on Calendar entries as a record of decisions or scheduling history. Google Sites and Forms similarly fall outside Vault’s supported service list, meaning any organization using Sites for internal documentation or Forms for structured data collection is managing that content with zero built-in retention safety net.

This matters more than it might first appear because Workspace adoption tends to expand organically: a team starts using Sites for an internal wiki or Forms for intake requests, without IT ever revisiting the data-protection conversation for that specific app. The result is a growing footprint of business-relevant data sitting completely outside the one governance tool the organization already pays for, simply because nobody checked whether that particular app was in scope. A reseller or implementation partner reviewing an organization’s actual app usage against Vault’s supported list, rather than assuming coverage extends to everything, is a straightforward way to surface this gap before it becomes a problem.

The Export and Format Limits That Bite During a Real Recovery

Vault’s export function caps out at 10 GB per ZIP file, with larger result sets automatically split across multiple files, a limit that’s rarely noticed during routine legal holds but becomes a real operational bottleneck when someone needs to reconstruct a large mailbox or a Drive folder full of media quickly. Gmail exports are further constrained to PST or MBOX formats, which aren’t universally compatible with every review platform or migration tool an organization might already be using, adding a conversion step to what should be a straightforward recovery.

Google’s own documentation is direct about the practical consequence of these constraints: occasional partial export errors can result in incomplete data exports, and, critically, Vault does not allow restoring deleted data directly back into a user account. Everything that comes out of Vault is exported as a file that must be manually reimported into the environment, which is a significantly slower and more error-prone process than a purpose-built backup tool’s point-and-restore workflow. For a single legal hold reviewed at leisure, this is a minor inconvenience. For an operational emergency where a team needs its Drive folder back within the hour, it’s the difference between a five-minute restore and a multi-hour manual rebuild.

Vault Coverage by Data Type

The Accidental Deletion Problem Vault Wasn’t Built to Solve

Accidental deletion is the single most common data-loss event any Workspace organization will face, and it’s also the scenario where the backup-versus-retention distinction matters most in practice. What happens, and doesn’t happen, when a file or email is deleted by mistake rather than by policy.

The Window Between “Deleted” and “Gone for Good”

Google Workspace has its own native deletion timelines independent of Vault: items in Gmail’s Trash and Drive’s Trash are generally purged automatically after a set period, and once that window closes, the data is gone from Google’s systems entirely unless something else, specifically, an active Vault hold or retention rule, was already protecting it before deletion happened. This is the critical sequencing point most admins miss: Vault only protects data that was already covered by a rule or hold at the time of deletion. It offers no retroactive protection, no undo button, and no way to recover something that fell outside every active hold when it disappeared.

In practice, this means an organization’s actual protection against accidental deletion is only as good as the comprehensiveness of its retention rules before the deletion occurred. Most organizations configure Vault reactively, in response to specific legal or compliance triggers, rather than proactively, as a blanket safety net for every user and every app. A sales rep who accidentally empties their Trash folder, or a marketing team member who deletes the wrong shared Drive folder, is fully exposed unless that specific account is already under an active hold, which, in most real-world configurations, it is not.

Why “We Have Vault” Doesn’t Answer the Accidental-Deletion Question

The question an organization actually needs answered isn’t “do we have Vault”, it’s “is every user account, every supported app, and every relevant time window currently covered by an active retention rule or hold, right now, today?” Those are very different questions, and the gap between them is exactly where accidental-deletion exposure lives. An organization can have Vault fully licensed and still have zero practical protection against a Tuesday-afternoon Drive mishap, simply because nobody ever set a default retention rule broad enough to catch it.

This is also where the backup-versus-retention distinction pays off operationally rather than just conceptually. A genuine backup tool takes scheduled, independent snapshots regardless of whether anyone remembered to configure a hold for that specific user or app; the protection exists by default, on a schedule, rather than by policy decision. For organizations where accidental deletion of ordinary working files, not just legally sensitive correspondence, is the primary risk they’re trying to manage, that scheduled, no-configuration-required coverage is the specific capability Vault doesn’t offer, and a dedicated backup product does.

Offboarding and Suspended Accounts: What Happens to Departed Employees’ Data

Employee offboarding is one of the highest-stakes moments for Workspace data, since it combines a data retention need with an access control need. What actually happens to a departed employee’s mailbox and files, and where the real risk sits.

Suspension vs. Deletion, the Distinction That Determines Everything

Google’s own guidance is explicit on this point: if an administrator deletes a user account, all data associated with that account is removed from Google’s systems, and the recommended practice is to suspend the account rather than delete it, precisely to avoid that outcome. A suspended account retains its data intact and accessible to Vault, which can retrieve valuable information from it to support offboarding and legal-hold scenarios. This is a genuinely useful capability for the “we need this former employee’s email for a contract dispute” situation.

The risk sits in what happens after suspension, not during it. Suspended-but-unlicensed accounts still consume a license slot on most plans. Hence, organizations under cost pressure often convert suspension into deletion faster than their own compliance posture would ideally call for, sometimes within weeks of an employee’s departure, well before any hold or retention rule has captured everything relevant. Once that deletion happens, an active hold didn’t already cover whatever is gone permanently, and no export, no Vault search, and no support ticket to Google will bring it back.

The License-Assignment Trap in Offboarding Workflows

A subtler risk lies in Vault’s own licensing requirement: both the admin conducting the search and the user whose data is being searched must have a Vault license assigned for the search to work. If an organization removes a Vault license from a departing employee’s account as part of a routine license-reclamation process, a common cost-saving step during offboarding, that account’s data effectively becomes unsearchable and unexportable through Vault going forward, even though the underlying data may still technically exist somewhere in Google’s systems.

This creates a narrow but real operational trap: the offboarding process itself, if not sequenced correctly, can strip away the very protection an organization would need three months later when a legal question about that former employee’s correspondence arises. The practical fix is procedural: hold Vault licenses for departed employees in place for a defined retention period before reclaiming them, but it’s a step that must be deliberately built into an offboarding checklist rather than assumed. Getting that sequencing right on the first pass, across every departing employee rather than only those flagged as high-risk, is a specific area where working with an implementation partner, rather than a purely self-serve setup, tends to close gaps that get missed amid day-to-day HR and IT workloads.

Export Limits and Why They Matter During a Real Recovery

Beyond the offboarding-specific export questions already covered, Vault’s export mechanics carry consequences for any large-scale recovery scenario, legal or otherwise. This section looks at how those limits actually play out at volume.

What Happens When a Recovery Involves More Than a Few Mailboxes

The 10 GB per ZIP file export limit is manageable for a single mailbox or a narrowly scoped legal hold. Still, it becomes a real logistical problem the moment a recovery scenario involves multiple users, a full department, or several years of accumulated Drive content. Vault automatically splits larger result sets into multiple ZIP files rather than failing outright, but that shifts the burden onto whoever has to reassemble, verify, and reintroduce potentially dozens of separate export files into a coherent, usable dataset, a task with no built-in tooling to automate it.

Occasional partial export errors, which Google’s own documentation acknowledges as a known behavior, add a further layer of manual verification work: someone has to confirm that every expected file, message, and attachment actually made it into the export set, rather than trusting the process end-to-end. For a single-matter legal export reviewed by a lawyer with time to spare, this friction is tolerable. For an organization trying to reconstruct a shared Drive after a large-scale accidental deletion or a sync error affecting dozens of users simultaneously, the same friction turns a routine recovery into a multi-day manual project.

Format Compatibility as a Hidden Recovery-Time Cost

Because Gmail exports from Vault are only available in PST or MBOX format, any recovery effort that needs to land that data back into a live Gmail account, rather than simply archiving it for legal review, requires an intermediate conversion and re-import step that Vault itself doesn’t perform. That conversion introduces its own risk of formatting loss, particularly around threading, labels, and attachment metadata, none of which is guaranteed to survive a round trip through an external format and back.

This is the specific point where the “retain and export, not restore” design decision has the most tangible operational cost: even once the right data has been correctly identified and exported, getting it back into a working, business-usable state still requires manual engineering effort that a native restore function would have eliminated. Organizations that have actually run a full-scale export-and-reimport exercise, rather than assuming it would go smoothly based on a small-scale test, tend to prioritize a dedicated backup solution for anything beyond narrow legal-hold use cases.

Ransomware and Malicious Deletion: A Scenario Vault Can’t Reverse

Malicious data loss, whether from a compromised account, a disgruntled insider, or a ransomware-style mass-deletion event, represents a distinct risk category from both routine legal holds and simple accidental deletion, and it’s worth examining on its own terms.

Why Mass Deletion Events Expose the Retention-vs-Restore Gap Fastest

A compromised account with sufficient permissions can delete large volumes of Drive files or Gmail data in minutes. If that account, or the specific files it touched, wasn’t already under an active Vault hold before the event, Vault offers no protection whatsoever after the fact. This is the scenario where the gap between retention and backup stops being theoretical and becomes an active business continuity problem: dozens or hundreds of files are gone, there is no scheduled snapshot to roll back to, and only whatever narrow set of holds happened to already be in place before the incident.

Security hardening, multi-factor authentication, admin activity alerts, and access restrictions are the primary defense against this scenario ever occurring in the first place. That territory belongs to account and access security rather than data protection specifically. What this section covers is strictly the aftermath: once a malicious mass-deletion event has happened, what can actually be recovered, and the honest answer is that Vault alone recovers only what was already covered by a hold beforehand, nothing more.

The Point-in-Time Restore Capability That Only Backup Provides

A dedicated backup solution’s core advantage in a ransomware or mass-deletion scenario is the ability to roll an entire account or domain back to a specific point in time before the event occurred, restoring the full prior state in a single operation rather than manually reassembling individual files from scattered export sets. This point-in-time restore capability is structurally different from anything Vault offers. Vault was never designed around the concept of “roll back to yesterday”; it was designed around “prove this data existed and pull it out for review,” which is a fundamentally different recovery model.

For organizations in regulated or high-risk sectors, where a mass-deletion event carries not just operational disruption but potential compliance exposure, this single capability gap is often the deciding factor in whether third-party backup gets budgeted. It’s also the scenario where the “is this genuinely warranted or redundant” question from this post’s title has the clearest answer: if point-in-time restore across an entire domain is a realistic requirement for your risk profile, no configuration of Vault will deliver it, because it isn’t the tool Vault was built to be.

When Vault’s Native Tools Are Genuinely Enough

Not every organization needs to add a third-party backup tool, and it’s worth stating plainly where Vault’s native capabilities genuinely match the risk profile, rather than treating every gap identified so far as automatically requiring a purchase.

Organizations Where Legal and Compliance Needs Dominate

For organizations whose primary Workspace data-protection driver is legal holds, regulatory retention requirements, or internal investigations, law firms, compliance-heavy financial services, or any organization primarily worried about proving data existed rather than restoring it operationally, Vault’s native feature set, correctly configured, genuinely covers the core need. Search by account, organizational unit, date, or keyword, combined with defensible holds that survive user-side deletion, is exactly the toolkit an EDRM-aligned identification and preservation workflow calls for, and building a separate backup product on top of that for purely legal purposes is often unnecessary spend.

The qualifier that matters here is “correctly configured.” An organization in this category still needs default retention rules broad enough to proactively cover every account, not just accounts flagged only after a legal need arises, and it still needs the licensing and offboarding sequencing covered earlier in this post to be handled correctly. Vault being sufficient in principle and Vault being sufficient as actually deployed are two different claims, and the gap between them is closed through configuration discipline, not through buying additional software.

Small Teams With Low Data-Loss Consequence

For a small organization where the practical consequence of losing a handful of files is genuinely low, no regulatory exposure, no large shared Drive that the whole business depends on operationally, and a small enough user base that manual re-creation of lost work is realistic, the cost and administrative overhead of a dedicated backup product may outweigh the risk it protects against. This isn’t the most common case among growing Workspace deployments. Still, it’s a legitimate one, and it’s worth naming explicitly rather than defaulting every organization to the same recommendation regardless of actual exposure.

The honest test is a simple one: if your organization’s shared Drive, sales pipeline data in Gmail and Sheets, or historical project files disappeared tomorrow with no ability to reconstruct them from memory or duplicate sources, what would that actually cost in lost time and lost business? For some small teams, the answer is genuinely modest. For most growing organizations, it isn’t. That answer, worked through honestly rather than assumed, is what should drive the third-party backup decision, not a generic industry recommendation applied uniformly.

Evaluating a Third-Party Backup Tool: What to Actually Look For

For organizations that do conclude they need backup beyond what Vault provides, not all third-party tools solve the same problem equally well. This section covers the specific capabilities to check for, rather than treating “get a backup tool” as a single, undifferentiated decision.

Restore Granularity and Speed

The single most important differentiator between backup products is restore granularity: the ability to recover a single file, a single email, a single user’s full account, or an entire domain independently of one another, rather than being forced into an all-or-nothing restore. A tool that can only restore an entire account when a user really needs one accidentally deleted folder back creates unnecessary disruption during recovery, overwriting current work to retrieve a small piece of lost data.

Restore speed matters just as much as granularity, particularly for the operational, as opposed to purely legal, data-loss scenarios covered earlier in this post. A backup product that takes hours to complete a straightforward single-file restore doesn’t meaningfully outperform a manual Vault export-and-reimport for small recoveries, and only earns its cost differential when the restore that would otherwise take hours or days through Vault’s process, a full mailbox, a full shared Drive, a domain-wide rollback, takes minutes instead. Evaluating actual restore time against realistic scenarios, not vendor marketing claims, is worth doing before committing.

Coverage Scope and Retention Independence From Google’s Own Systems

A genuinely useful third-party backup tool should cover the specific apps identified earlier as sitting outside Vault’s scope, Google Sites, Forms, and full Calendar content among them, rather than simply duplicating what Vault already does for Gmail and Drive. Checking a vendor’s supported-app list against your organization’s actual Workspace usage, not just the commonly cited apps, is the difference between closing a real gap and paying for redundant coverage of apps you’re already protected on.

Equally important is architectural independence from Google’s own infrastructure: a backup copy stored entirely within Google’s ecosystem doesn’t protect against certain platform-level failure scenarios the way a copy stored on genuinely separate infrastructure does. Vendors vary meaningfully here, and it’s a reasonable, specific question to ask directly during evaluation: where, physically and architecturally, does the backup copy reside, and does an issue on Google’s side have any plausible path to affecting it? An implementation partner that has evaluated multiple backup vendors in real client environments, rather than reselling a single default option, is generally better positioned to align a tool’s actual coverage with an organization’s specific app footprint.

Building a Layered Data Protection Strategy for Google Workspace

The most durable answer to “do I need third-party backup” isn’t a single yes-or-no, but a layered strategy where Vault, correctly configured, and backup, where genuinely warranted, cover different and complementary parts of the risk.

Mapping Tools to Risk Rather Than Buying by Default

The most effective Workspace data-protection setups treat Vault and third-party backup as answers to different questions rather than competing options. Vault, with comprehensive default retention rules across all accounts and apps it supports, handles legal hold and eDiscovery needs well. A backup tool, layered on top, handles the operational restore needs, accidental deletions, sync errors, and malicious mass-deletion events that Vault was never designed to solve. Treating this as a layered decision, explicitly mapped against the specific risks identified throughout this post, yields a more defensible and cost-effective outcome than either defaulting to “Vault is enough” without configuration discipline or to “buy a backup tool” without checking whether the risk profile actually warrants it.

Getting the Vault side of that layer configured properly, setting broad default retention rules, ensuring correct offboarding sequencing, and ensuring licensing doesn’t quietly lapse for departed employees is foundational work that has to happen regardless of whether a backup tool is added on top. Skipping it and going straight to a backup purchase leaves the eDiscovery and legal-hold side of the risk under-covered even after the operational side is solved.

Revisiting the Decision as the Organization Grows

A data-protection posture that was genuinely sufficient at ten employees with a handful of shared Drive folders often stops being sufficient once an organization scales to fifty or a hundred people with years of accumulated institutional knowledge sitting in Gmail threads and Drive files. The honest-cost exercise from earlier in this post, what would actually be lost, and what would it cost to reconstruct, is worth rerunning periodically rather than being treated as a one-time decision made at initial Workspace setup and never revisited.

Vault vs. Third-Party Backup, Matching Tool to Scenario

Frequently Asked Questions

Does Google Workspace include automatic backup by default?

No. Google Workspace does not include a native, automatic backup product by default on any plan tier. What’s included in Google Vault on Business Plus and Enterprise editions, or as an add-on elsewhere, is a retention and eDiscovery tool, not a backup tool. It preserves data under retention rules, requires an administrator to configure it, and exports data for review rather than restoring it to a live account. Organizations that assume “we’re on a paid Workspace plan, so we’re backed up” are working under an incorrect assumption that only becomes apparent during a data-loss event. Confirming what’s actually configured, which accounts sit under active holds, and whether restore capability exists at all is worth doing proactively rather than discovering the gap during a recovery attempt.

Can I recover a file that was deleted before I set up a Vault retention rule?

Generally no. Vault only protects data that was already covered by an active retention rule or hold at the time of deletion. It offers no retroactive protection for data lost before a rule existed, since Vault doesn’t create backward-looking snapshots; it preserves data going forward from the point a rule takes effect. If a file was deleted and then permanently purged from Google’s systems within normal deletion timelines before any hold was applied to it, no configuration change afterward will recover it. This is why proactive, broad default retention rules configured before any specific incident matter more than reactive rules set up after a deletion has already happened.

What happens to a former employee’s Google Workspace data if I delete their account instead of suspending it?

Deleting a user account removes all data associated with that account from Google’s systems, and this deletion is not reversible through Vault or any other native tool, regardless of any prior retention rules, unless that specific data was independently exported beforehand. Google’s own guidance recommends suspending departing employees’ accounts rather than deleting them, specifically because suspended accounts retain their data and remain searchable in Vault, including by administrators who need that data for legal, compliance, or business continuity reasons after the employee has left. Deletion should only happen after a defined retention period has passed and any relevant data has been confirmed as no longer needed or already exported.

Does a Vault license need to stay assigned to a suspended employee’s account?

Yes, if you want to retain the ability to search and export that account’s data through Vault. Both the administrator performing a search and the user whose account is being searched need an active Vault license for the search to function. If a Vault license is reclaimed from a suspended employee’s account as part of routine cost-saving license cleanup, that account’s data becomes unsearchable and unexportable through Vault in the future, even if the underlying data technically still exists in Google’s systems. A common and safer practice is holding Vault licenses on offboarded accounts for a defined retention window, often tied to your organization’s legal retention policy, before reclaiming them.

How long does Google keep deleted Gmail or Drive data before it’s permanently gone?

Google Workspace applies its own default deletion timelines to items in Gmail’s Trash and Drive’s Trash, after which the data is purged from Google’s systems unless it is already protected by an active Vault hold or retention rule. These native timelines exist independently of any Vault configuration and apply the same way regardless of whether your organization uses Vault at all. Because Vault offers no retroactive recovery once this native purge window has closed, the practical safety net against this specific timeline is either a proactive, broad Vault retention rule that covers the account in advance or a third-party backup solution that maintains independent, scheduled copies regardless of Google’s own trash retention settings.

Is there a size limit on what I can export from Google Vault during a recovery?

Yes. Vault exports are capped at 10 GB per ZIP file, and larger result sets are automatically split across multiple ZIP files rather than exported as a single package. For a small, narrowly scoped legal hold, this rarely causes friction. Still, for a large-scale recovery, a full department’s mailboxes or years of accumulated Drive content, this limit means dealing with potentially dozens of separate export files that then need to be manually verified and reassembled. Google’s documentation also notes that partial export errors can occasionally result in incomplete exports, which adds a manual verification step that a dedicated backup tool’s restore process typically doesn’t require.

If my organization is on Business Starter or Standard, are we protected at all?

Not by default. Vault is not included with Business Starter or Business Standard editions. It must be purchased separately as an add-on license if an organization on those plans wants retention and eDiscovery capability at all. Without it, deleted data follows Google’s standard trash-retention timelines with no additional preservation layer, and there is no built-in mechanism to recover data once that native window closes. Organizations on these lower tiers that handle sensitive or business-critical data should treat either a Vault add-on or a third-party backup solution as a deliberate purchase decision, rather than assuming baseline protection exists simply because they’re paying for a Workspace subscription.

Can Google Vault protect against ransomware or a compromised account deleting large amounts of data?

Only to the extent that an active retention rule or hold already covered the affected accounts and apps before the event occurred. Vault has no mechanism to roll an account or domain back to a point in time before a mass-deletion event. It wasn’t designed around point-in-time restoration; it was designed around preserving specific data under rules set in advance. For organizations where a compromised account or mass-deletion scenario represents a realistic risk, a third-party backup solution with genuine point-in-time, domain-wide restore capability addresses a gap that no amount of additional Vault configuration can close, since it’s a difference in what the tool was built to do rather than in how well it’s configured.

Does Vault cover data in Google Sites, Forms, or Google Keep?

No. Vault’s supported service list does not include Google Sites, Google Forms, or Google Keep, regardless of Workspace edition or license assignment. Organizations using any of these apps for business-relevant content, internal documentation in Sites, structured intake data in Forms, or working notes in Keep have no native retention or export protection for that content in Vault. If any of these apps store data your organization considers business-critical, that’s a specific, concrete gap worth addressing directly, either by moving that content into a Vault-supported app where retention rules can apply, or by adding a third-party backup tool whose supported-app list explicitly includes it.

If I add a third-party backup tool, do I still need Google Vault for anything?

Usually yes. Third-party backup tools are built to solve the restore problem by quickly restoring deleted or corrupted data to a working state. Still, most were not built to replace Vault’s specific eDiscovery workflow: search by account, organizational unit, date, or keyword, combined with legally defensible holds that satisfy a court or regulator’s expectations for chain-of-custody documentation. Organizations with genuine legal or regulatory retention obligations generally need both tools running together rather than choosing one over the other, Vault handling the legal-hold and eDiscovery side, and backup handling the operational restore side, since each is purpose-built for a distinct part of the overall risk this post has walked through.

Glossary

• Vault: Google Workspace’s built-in tool for retaining, holding, searching, and exporting user data for legal and compliance purposes; included with Business Plus and Enterprise editions, available as an add-on elsewhere.
• Retention rule: An administrator-configured policy that preserves specific data for a set period or until a defined event, independent of user-side deletion.
• Hold: A Vault mechanism that prevents specific accounts, organizational units, or groups from having their data permanently deleted, typically applied during litigation or investigation.
• eDiscovery: The process of identifying, preserving, and retrieving electronically stored information, typically for use in legal proceedings or regulatory investigations.
• EDRM (Electronic Discovery Reference Model): An industry-standard framework outlining the stages of the eDiscovery process, from identification through production; Vault supports the earlier identification and preservation stages.
• Backup: A scheduled, independent copy of data stored separately from the live production environment, created specifically to be restored to its original state if the original data is lost or corrupted.
• Point-in-time restore: The ability to recover an account, folder, or domain to its exact state as of a specific past date, a capability offered by dedicated backup tools but not by Vault.
• Matter: A Vault container used to organize the holds, searches, and exports associated with a specific legal case or investigation.
• Suspension: Deactivating a Google Workspace user account while preserving its data, as opposed to deletion, which removes the account’s data from Google’s systems.
• Comprehensive Mail Storage: A Vault setting that ensures app-generated and automated messages, not just user-composed emails, are captured and made discoverable within Vault searches.