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 documented subject-access collection process using Google Vault can follow a consistent structure. The customer and its advisers remain responsible for the legal scope and response:

• 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.
• Preservation decision. The customer and its advisers decide whether a legal hold or other preservation step is required before collection.
• Search and export. Run authorised, custodian-scoped searches in Vault. The relevant custodians, systems, dates, terms, exemptions, and disclosure scope are decisions for the customer and its advisers; a Vault search alone does not guarantee identification of all personal data.
• 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 documented request log can help the customer evidence how it handled repeat requests. The customer remains responsible for deciding whether a request is repetitive and how the applicable law applies.