How to handle a DSAR using Google Vault

Under UK GDPR and EU GDPR, a Data Subject Access Request gives individuals the right to receive a copy of the personal data an organisation holds about them. The organisation has one calendar month to respond — extendable by a further two months for complex requests, but only with notification.

A valid DSAR response must identify all personal data held about the subject, explain how it is used, confirm who it has been shared with, and provide copies where requested. Incomplete responses, late responses, or responses that fail to identify relevant data can all result in regulatory action.

For most organisations using Google Workspace, a significant proportion of personal data about employees, customers, and contractors lives in Gmail threads and Drive files. Email is often where the most sensitive data is found: HR decisions, performance reviews, disciplinary records, contract negotiations.

Google Vault is the tool Google provides for searching and exporting this data. It supports custodian-level searches — meaning you can search specifically for all data sent to, received by, or owned by a given email address — which is exactly the scope a DSAR requires.

A defensible DSAR process using Google Vault follows a consistent structure:

• Identity verification. Confirm the requestor is who they claim to be before taking any action. Document the verification method and outcome.
• Scope definition. Determine which systems hold data about the subject. For Workspace users, this typically means Gmail (sent and received), Drive (owned and shared files), and any connected services. Define the custodians explicitly before running any searches.
• Legal hold (if applicable). If there is any possibility of related legal proceedings, place a hold before exporting. A hold without export is reversible; missing data because a hold wasn\'t placed is not.
• Search and export. Run custodian-scoped searches in Vault. For a DSAR, the primary custodian is the subject themselves — all mail sent or received, all Drive files owned. Secondary custodians may be relevant if the subject appears in others\' correspondence.
• Review for exemptions. Not all personal data must be disclosed. Legal professional privilege, third-party data, and information whose disclosure would prejudice a criminal investigation can be withheld. Each exemption applied must be documented.
• Response production. Prepare the response in a readable format. Raw MBOX files are not an acceptable response to a DSAR. The data should be presented in a way the subject can reasonably understand.

Every DSAR must be accompanied by a documented record of the process: when the request was received, how the subject was identified, what searches were run, what exemptions were applied and why, and when the response was sent.

This documentation is what a regulator reviews if a complaint is made. It is also what protects the individuals who handled the request from personal liability. A thorough process record can demonstrate that the organisation acted in good faith and followed a reasonable procedure, even if the outcome is later disputed.

Creating this record manually — from exported MBOX files and spreadsheets — is doable but time-consuming. It also creates gaps: the kind of small omissions that are difficult to explain under regulatory scrutiny.

GDPR permits organisations to charge a reasonable fee, or refuse to respond, to requests that are "manifestly unfounded or excessive" — particularly where they are repetitive. The threshold is high, and the burden of demonstrating vexatiousness sits with the organisation.

A complete request log is essential here: without it, you cannot demonstrate that a request is repetitive. Tracking DSARs in a centralised system, rather than across individual inboxes, makes this defensible.