# 44 Vault-account custody of crown jewels

> v0.0.3 · role: Prevent · edition: All (1 license) · [policy: #28 · #15, #29](https://docs.google.com/spreadsheets/d/1nOztaPd1Y7eNeRSR_hdovYy-ncpx-bAx/edit?usp=sharing&ouid=115159875779023172526&rtpof=true&sd=true)

Crown-jewel documents are owned by a locked, licensed account that nobody works from — no mail flow, no OAuth grants, no daily sign-in — and access to them is granted out of it per file, read-only and time-boxed. Because the files sit outside every working user's Drive, compromising a working user does not reach them: the blast radius of a phished employee stops at what they were explicitly and temporarily granted.

Documentation: [Transfer Drive files to a new owner as an admin](https://knowledge.workspace.google.com/admin/drive/transfer-drive-files-to-a-new-owner-as-an-admin) · [Share files and folders in Drive](https://support.google.com/a/users/answer/9310248)

## Caveats

- The custody account's own credentials become a single point of failure — it needs break-glass custody (№36, №43) and must be inside the audit-the-auditors alert scope (№61).
- There is no single Admin Console screen for the pattern — Drive can enforce both halves of a grant once it is made (the Viewer role blocks editing, and on eligible editions a per-user access expiration date revokes access automatically), but nothing enforces that the grantor actually picks Viewer and sets an expiry, so the granting discipline is still the control.

_Process control — carried out offline; no Admin Console walkthrough._

## Ongoing maintenance

- **[requires a human]** Per policy: rotate the sealed credential and update the custody record.

## How to verify

1. Check the custody record for the Vault account, confirm its credential is sealed, and verify the account still holds only the Vault privileges it should.