Who Accessed a Shared Google Drive Document? The Audit Log, Explained

8apps Team·

A sensitive doc was shared and now you need to know who opened it. Where the Drive log lives, what it records, what your edition hides, and the question the log can't answer.

The 4:55pm question

A contract, a salary sheet, a board deck – something sensitive turns out to have been shared more widely than intended, and now someone needs to know: who actually opened it?

Google keeps a log that can answer this. Here is where it lives, what it records, and – just as important – the two things it will not tell you.

Where the log lives

Admin console → Menu → Reporting → Audit and investigation → Drive log events. This is available to Workspace admins generally; you do not need a top-tier edition to read it.

Filter by the document (or the user) and a time window, and you get the event stream: views, edits, downloads, prints, uploads, deletions, and sharing or permission changes, each with the account and timestamp. For the 4:55pm question, the view and download rows are usually the whole story – these accounts opened it, this one downloaded it, here is when the sharing changed.

What the log records that people forget

Two event families are worth knowing about beyond plain views. Content access via APIs and sync clients is logged too ("item content accessed", "item content synced"), so a file pulled down by a connected app shows up, not just browser opens. And sharing changes are recorded too, through the Visibility change and Prior visibility attributes rather than a dedicated event name – you can reconstruct when a document became shared and by whom, which is often the real question behind the question.

What your edition gates

Reading the log is broadly available. Investigating at scale is not. The security investigation tool – pivoting from one event to everything that account touched, querying in bulk, acting on results – is limited to Frontline Standard and Plus, Enterprise Standard and Plus, Education Standard and Plus, Enterprise Essentials Plus and Cloud Identity Premium. Business Starter, Standard and Plus are excluded. For what each plan's built-in security tooling does and does not include, see our plan-by-plan breakdown.

The two things the log cannot tell you

First: anonymous link visitors are not neatly named. If a file is open to anyone with the link, an outside visitor is not a named account in your directory. You may see that access happened without ever being able to say who in the human sense. The honest phrasing for your incident note is "opened by an account we can identify" versus "accessible via link during this window".

Second – and this is the bigger one: the log answers this document. It does not answer how many other documents are sitting in the same condition. The 4:55pm question is really two questions, and the second one – "is this the only one?" – is a permissions-state question, not an event question. That is an org-wide audit: scanning every user's My Drive and Shared Drives for public links, external access and stale shares, on one dashboard. Drive Guard for Admins does exactly that, deploys to every user with one admin install, and costs US$4.80 per user per year – launch pricing against a US$8.80 list price – with a 7-day trial. Free for education institutes.

A clean incident-note structure

When you write it up: what the document is and who owns it; the sharing state and when it changed (from the sharing events); who accessed it in the window (from view/download events, with the link-visitor caveat above); and what you checked to confirm the blast radius beyond this one file. The last line is the difference between closing an incident and closing your eyes.

Sources

  • Drive log events – menu path; event names; the "item content accessed" and "item content synced" events; the Visibility change and Prior visibility attributes; external users shown as anonymous; the security investigation tool edition list on the same page. Re-read 2026-09-09.