Google Vault Deep-Dive: Holds, Search Scope, and Chain of Custody

Aug 16
6 min read

Updated: Aug 16

You've seen Vault mentioned twice already in this series — once as "the evidence room" in the Drive exposure article, once in passing in the Takeout article. Both times, the same line: Vault is what you use when you actually need the file.

That's true. It's also not the whole story.

Vault is a legal hold and eDiscovery tool first, and an investigator's tool second. Those two jobs pull in different directions, and if you don't know where the seams are, you'll assume Vault sees more than it does.

What Vault Actually Is (And Isn't)

What it is: a search, hold, and export layer that sits across Workspace data — built for legal discovery and compliance, not day-to-day IR.

What it isn't: a second copy of every log you've already seen in the Investigation Tool. Vault doesn't give you actor/IP/visibility fields — it gives you the underlying content.

If Drive log events are the timeline and Vault is the evidence room, Vault's door only opens for a few rooms in the building — not the whole floor.

Creating a Matter

Before you can run a single search, Vault makes you create a matter. Think of it as a case folder — every search, hold, and export you run lives inside it, tied to whatever investigation you opened it for.

Two things worth knowing before your first one:

One matter per case. Running two unrelated investigations at once? Don't dump both into the same matter — you'll lose the ability to cleanly hand off or close one without touching the other.
Matters are shareable. Add another investigator to the matter and they see everything you've run inside it — searches, holds, exports. Useful once a case grows past one person; also means you should know who else has access before you assume a matter is private to you.

Search Scope: What Vault Can Actually See

This is the part people get wrong most often. Vault doesn't cover "Workspace" as a whole — it covers specific services, and coverage has grown over time, so don't assume last year's scope is this year's.

Gmail — mail, including drafts and chats migrated into Gmail
Drive — files in My Drive and Shared Drives, including version history
Google Chat — spaces and direct messages, if history is turned on for the space
Groups — messages sent to Google Groups
Meet — recordings saved to Drive, plus limited attendance/metadata

Notice what's missing: Calendar isn't a Vault search target. If your case hinges on "what meeting was this person actually in," Vault won't answer that — you're back to Admin Console reports.

Gmail Search Syntax Inside Vault

The basic search fields get you far, but the real power is in the “Terms” field, which takes Gmail-style search operators:

Operator	What it does
to: / from: / cc: / replyto:	Match a specific address in that header
in:inbox / in:spam	Match a system folder
label:	Match a specific label
is:read / is:unread	Match read state
larger: / smaller:	Match by message size, e.g. larger:5M
filename:	Match an attachment name
has:attachment	Match messages with an attachment
AND / OR / NOT (or -)	Combine or exclude terms
*	Wildcard
AROUND n	Match terms within n words of each other

Chain them together and you can get specific fast. Investigating a suspected data handoff to a personal account, for example:

from:dean@ AND to:*@gmail.com AND has:attachment AND larger: 2M

Two limits worth knowing before you rely on this:

English words and numbers only — no punctuation. Vault can't search for a literal string with symbols in it. That includes href links, so if you're hunting a phishing email by the URL embedded in it, a Vault text search won't find it — pull the raw message and check manually instead.
A blank space between terms means AND, not OR. Don't assume unrelated words in a query are being treated as alternatives.

One more thing before you trust a timestamp in your results: Vault displays times in your browser's local system time, not UTC. If you've got investigators in different time zones — or your own machine's clock is off — normalize before you build a timeline.

Holds: The Part That Actually Preserves Data

A hold is what stops data from being purged — by retention rules, by a user hitting delete, by anything. No hold, no guarantee the thing you need still exists tomorrow.

Two ways to scope a hold

Org-wide / OU-wide hold: applied across an organizational unit. Broad, blunt, usually for a standing legal or compliance requirement rather than a single investigation.

Custodian-based hold: applied to specific accounts — the people actually relevant to a matter. This is the one you'll use mid-investigation: put a hold on the account(s) involved the moment you suspect something, before you've finished scoping the case.

Speed matters here. A hold placed after a user has already deleted and purged something doesn't reach back in time — it only stops what happens next.

Vault Retention vs. Native Workspace Retention

This is where two systems with similar names quietly disagree with each other.

Native Workspace retention rules (set in Admin Console) control how long data lives by default — and they purge on schedule. A Vault hold overrides that purge for anything it covers, for as long as the hold is active. Remove the hold, and native retention rules resume — including deleting anything that was only being kept alive by the hold.

Two more things that trip people up here:

Vault retention and Email Audit Log retention are not the same clock. An email can fall out of the Audit Log's retention window while still being fully searchable in Vault, or the other way around — check both before you conclude something isn't recoverable.

And a brand-new Workspace org has no default retention rules configured at all — someone has to turn them on. Until they do, mail just follows the plain mailbox-to-Trash timeline below: nothing purged early, but nothing extra held either.

That second 30-day window is the one people miss.

Once an email clears a user's Trash, most people assume it's gone. It isn't — Google holds it for another 30 days by default, and during that window it's still searchable in Vault and still shows up in your other investigation tools. After that, it's gone unless a hold was already in place.

Export Formats — and Why Chain of Custody Actually Matters Here

Once you've searched and scoped what you need, Vault exports it — but the export itself is often the piece that ends up in front of legal or a third party, so how it's packaged matters.

Mail exports as MBOX or PST — you choose the format when you set up the export. MBOX is what most investigators pick; it's the more versatile of the two and easier to work with in other tools.
Drive exports keep native file formats (Docs, Sheets, etc.) rather than flattening everything to PDF.
Chat and Groups export as structured message files, not screenshots.
Exports can be limited to the EU or US data region if you have a requirement about where the data physically lands — outside those two, your only option is “no preference.”
Exports aren't permanent: you get 15 days to download before Google auto-deletes them, with unlimited re-downloads inside that window but no extension once it closes.
Confidential Mode Gmail content is included — Vault can search and export messages sent with Confidential Mode turned on, it isn't a blind spot.

The part people skip: an export isn't one file, it's five.

.zip — the actual email content (MBOX or PST, whichever you picked), attachments included
metadata.csv — per-message summary (IDs, labels, from/to/cc/bcc, sent/received dates)
metadata.xml — the same summary data, plus the exact search query used to generate the export
results-count.csv — a simple count of messages and accounts in the export
checksum file — hashes for the other four files, so you can prove nothing was altered or lost in transit

Download all five. Skipping straight to the .zip is the single most common mistake — metadata.xml has your search query on record, and the checksum file backs your chain-of-custody claim later.

One more wrinkle: timestamps inside metadata.xml don't reflect the sender's time zone, the recipient's, or the admin's — they reflect whichever mail server (MTA) last touched the message before it landed in the mailbox. Don't assume it's local to anyone in the case.

Common Investigator Mistakes

Assuming Vault = full visibility. It's access to content, not an audit trail — you still need the Investigation Tool for who/when/how.
Placing a hold after the fact and assuming it recovers what's already gone. It doesn't — it only preserves what's still there.
Forgetting Calendar (and a few other services) simply aren't in scope, then wondering why a search comes back empty.
Treating the export as done without saving the manifest — then having no way to answer "how do we know this wasn't modified" later.

Final Thoughts

Vault earns its "evidence room" nickname — but a room only holds what someone thought to lock the door on, and only for the wing of the building it was built to cover.

Vault preserves content; it doesn't log activity — pair it with the Investigation Tool, not instead of it
Holds stop future loss, not past loss — speed matters
Search scope has gaps (Calendar is the one people forget)
The export isn't done until the manifest is saved with it

-------------------------------------------------------Dean-----------------------------------------