Drive Audit Log Retention: 6 Months and Then Gone

8apps Team·

Google keeps Drive log events for 6 months. What that means for sharing history, why old public links leave no trace, and what to export before it ages out.

The question that arrives at month eight

A document turns up somewhere it should not be. Legal, or a customer, asks the reasonable question: when was this shared, and by whom? You open Drive log events, set the date range as wide as it goes, filter on the file, and get nothing. Not "no external shares" – nothing. The share happened eight months ago, and Google's log stopped remembering it two months back.

This is not a bug and it is not your edition. It is the retention window, and it shapes what a Drive audit can and cannot prove.

The window: 6 months, near real time

Google's data retention page lists Drive log events at six months of retention, with a lag of a couple of minutes – "near real time". The aggregate Drive highlight reports lag one to three days; the event-level log you use for forensics is current almost immediately.

Six months is a rolling window. Every day, the oldest day of events falls off the back. Google's page documents no way to extend it or to retrieve an event once it has aged out. If it matters, it has to leave the log before that happens.

What the log is – and what it is not

Drive log events live at Menu → Reporting → Audit and investigation → Drive log events, on every Workspace edition. Each row is an action on an item – View, Rename, Create, Edit, Print, Delete, Upload, Download, Source Copy – with a timestamp and an actor. The thing sharing audits depend on is an attribute rather than an event: Visibility change, which Google defines as the visibility of the Drive item before the activity. There is no discrete sharing event in the Event name list, so you filter on the attribute.

What the log is not is a permissions map. It records changes, not state. If a file was made public in January and nothing has touched its sharing since, then by August there is no Visibility change row for it anywhere in the window – and the file is still public. Sharing does not expire when its log entry does. An empty result proves nothing about the current state of the file.

A rolling log answers "what changed recently" very well, and "what is exposed right now" only for the slice of files someone touched in the last half year.

The 7-day default view

The page opens on the last seven days. It is easy to run a query, see nothing and conclude the file was never shared, when the honest conclusion is that it was not shared this week. Widen the date range to the full six months before reading anything into an empty result – and remember that the full six months is still only six months. Our piece on who accessed a shared Drive document walks through the filters.

External users show as anonymous

The other forensic limit is who the log names. Google's page is explicit: users outside the domain appear as anonymous, except when they view or edit a document explicitly shared with them – as an individual or as a member of a specific group. Their views, edits and downloads are still logged, so you can see that someone anonymous opened a public-link file. You cannot see who.

For a file shared to a named external address, the log gives a name. For a file on anyone-with-the-link, it gives a timestamp and nothing else. That is the second reason a public link is worse than a direct external share: not just wider, but unattributable after the fact.

What to export, and when

If you may ever have to answer a question more than six months after the event, take a copy before it ages out. Google lets you export search results from Drive log events to Sheets or to a CSV file. A workable habit for a small admin team:

  1. Once a quarter, open Drive log events, set the date range to the previous quarter, and filter on the Visibility change attribute. Export to Sheets. That is your sharing-change record for the period, and it will still exist in year three.
  2. In the same sitting, filter on Download and Source Copy for anything you consider sensitive, and export that too. These are the events that show data leaving.
  3. Name each export by quarter and keep it where the next admin will find it – a Shared Drive with Manager access limited to the admin group is the obvious place.
  4. Note in the file what you exported and when. Six months later the log cannot confirm it for you.

Quarterly overlaps the retention window comfortably. Annually does not – you would lose half the year. The quarterly access audit checklist builds this into a full cadence.

Where the log stops

An exported log tells you what changed and, for named users, who changed it. It cannot tell you what is shared right now across the organisation, because the events that created most of that sharing are older than the log. On a Business edition there is no native report of current sharing state across every My Drive and every Shared Drive – the Drive inventory export that comes closest is an Enterprise and Education Standard-and-up feature that lands in BigQuery.

The complement: a current-state scan

The log is the history. Pair it with a snapshot of the present: every file, every permission, as of now, regardless of when the share was made. Side by side, the month-eight question has an answer – the scan shows the file is public, and the exported log from that quarter shows when it became public and who did it.

Drive Guard for Admins is the snapshot half. One admin install from the Marketplace, deployed to every user; nobody installs anything themselves. It scans every user's My Drive and every Shared Drive and shows public links, external shares and legacy access on one dashboard, with exports – including the January public link no log remembers. It reports; you fix, in the sharing dialog or Manage shared drives – revoking from inside the tool is on the roadmap. The full manual method, log and all, is in how to audit Google Drive access across the organisation.

Sources