How to Audit Google Drive External Sharing and Public Links: Find, Triage and Fix Exposed Files

Most organisations that use Google Drive cannot say, on any given day, how many of their files are open to anyone with the link or shared with people outside the company. Sharing settings stop new mistakes, but they do not clean up the years of links and external shares that already exist, and turning a setting off later can break legitimate work overnight. This guide is the audit procedure: where the evidence lives in Google Workspace, how to build a complete inventory of externally shared and public files, how to triage what you find, and how to fix it at scale without a flood of helpdesk tickets. It is written for Workspace administrators, security engineers and data protection leads who already have baseline settings in place and now need to measure and reduce existing exposure.

This is an independent guide from NHI Mgmt Group, based on Google's public Workspace administrator documentation as of November 2026. It is not sponsored or reviewed by Google. Product features change, so confirm settings against Google's current documentation.

Key takeaways

• Settings and exposure are different questions. The sharing policy tells you what users may do from now on; only an inventory of file permissions tells you what is already open, and that is what an audit has to measure.
• Use the Drive inventory export for the full picture. The weekly or daily BigQuery export carries per-file permission rows, including anyone grants and pre-computed external sharing flags, which the event log alone cannot give you for files shared before your retention window.
• Use Drive log events for change and attribution. Events with a visibility of people_with_link, public_on_the_web or shared_externally show who changed sharing and when, but they are kept for six months, so older shares are invisible there.
• Triage by content and audience, not by count. A public link on a marketing PDF and an external editor on a payroll sheet are both "external sharing"; rank by sensitivity label, role (editor before viewer) and recipient type (anyone, consumer accounts, unknown domains).
• Fix in waves with owner notice. Bulk changes through the investigation tool are quick, but removing access without warning breaks partner work; notify owners, give a short deadline, then revoke and record exceptions with an expiry.

What you are auditing and why settings are not enough

A Google Drive file can be reached by people outside your organisation in five main ways. Each one leaves a different trace, and each needs its own query.

The configuration baseline (allowlisted domains, warnings, default link visibility, blocking non-Google accounts) is covered in the Google Workspace Security Checklist, and label-driven sharing control and trust rules are covered in the Google Workspace DLP and Data Protection Guide. This page assumes those exist and asks a narrower question: what is exposed right now, who did it, and what should happen to it.

Two behaviours make the audit necessary even with good settings. First, Google states that when external sharing is turned off, external users lose access to items previously shared with them, and that changes can take up to 24 hours. That makes "just turn it off" a disruptive change for any organisational unit that has relied on external sharing, so most organisations keep sharing on for some teams and must therefore audit what those teams share. Second, group settings override organisational unit settings, and where a user is in several groups the highest-priority group applies, so a single exception group can quietly re-enable external sharing for people who appear locked down at OU level.

The evidence sources and what each one answers

Choosing between them: where your edition supports it, the inventory export is the backbone of the audit because it is a full snapshot rather than a stream of changes. Log events explain how a file came to be exposed and are the right tool for an investigation or for alerting. The Drive API route is for editions without the inventory export, and it introduces a privileged service identity of its own (see "Where identity fits" below).

Edition matters. Google lists the Drive inventory export for Frontline Plus, Enterprise Standard and Plus, Education Standard and Plus, Enterprise Essentials Plus and Cloud Identity Premium, and the security investigation tool for a similar set of editions. Business editions should plan on the audit and investigation tool plus the Drive API.

Build the inventory: step by step

1. Prepare a Cloud project: create or choose a Google Cloud project with billing enabled, create a dataset, and grant the setup admin Project IAM Admin and the analysts BigQuery Data Editor. Google estimates about 1.5 GB of storage per million files. Restrict dataset access: the inventory is itself sensitive, because it lists titles, owners and every external email address.
2. Enable the export: in the Admin console go to Reporting > Data integrations > Drive Inventory Exports, tick Enable Drive inventory report export to Google BigQuery, choose the project, dataset and schedule. Turn on the optional external sharing calculations so the access.has_external_sharing flags are filled; Google notes that several groups with over 1,000 members can delay delivery.
3. Keep history: each export overwrites the previous one and tables expire after 60 days by default. Use BigQuery Data Transfer Service or a scheduled copy into a dated table so you can show exposure falling over time.
4. Wait for and validate the first export: allow up to two weeks. Check the row count against your Drive file counts per OU, and sample ten known externally shared files to confirm they appear with the right permissions. Google warns that some files may be missing metadata and that unclaimed Jamboard files and Google Vids videos may be absent.
5. Write the core queries (described here, not as code): files with any permission of type anyone; the subset where allow_file_discovery is true; files where access.has_external_sharing_excluding_service_accounts is true, grouped by access.external_sharees.email domain; files with access.is_published_externally; external permissions with role writer or owner; and all of these joined to the shared drives table so shared drive exposure is reported by drive name.
6. Enrich: join owner.user.email and org_unit_path to your HR or directory data to flag files owned by suspended or departed users, and join access.dlp_info.matching_dlp_rules and applied labels to rank sensitivity.
7. Monitor the export itself: export events appear in Admin log events; alert if the export fails or stops, because a silent gap looks the same as a clean result.

Where the inventory export is not available, run the same logic through the Drive API: for each user (and each shared drive) list files with visibility = 'anyoneWithLink' or visibility = 'anyoneCanFind', then read permissions for files owned by that user to find external user, group and domain grants. Expect this to take days on large tenants and to need careful handling of rate limits.

Use the logs for attribution and change detection

The Drive log carries a visibility parameter with values including private, people_with_link, people_within_domain_with_link, public_in_the_domain, public_on_the_web, shared_externally and shared_internally, plus a target_user (the user, group or domain whose access changed), a primary_event flag and an owner_is_shared_drive flag. In the console, the Visibility change attribute holds the item's visibility before the activity and Target is the user whose access changed.

Two limits shape how you use these results. Retention is six months, so the log cannot tell you about a link created two years ago; only the inventory can. Export from the audit and investigation tool stops at 100,000 rows, while the security investigation tool allows up to 30 million rows, which matters for tenant-wide reviews. To keep longer history and run joins, export Workspace logs to BigQuery or your SIEM, as described in the Google Workspace Audit Log Detection Guide.

Triage: deciding what matters

A first inventory in a mature tenant often returns tens of thousands of exposed files. Rank them with a simple, explainable score rather than reviewing in file order.

Decision guidance: public and discoverable files with any sensitive marker should be fixed immediately without waiting for owners. External editors on sensitive files come next. Plain "anyone with the link" viewer access on unlabelled files is the long tail: handle it with owner notice and automation. Small organisations (under a few hundred users) can often review the whole first list by hand in a week; large ones should fix the top two tiers centrally and push the rest to owners with a deadline.

Remediate at scale without breaking work

1. Agree exception rules first: decide which teams may hold public links (marketing, recruitment, public documentation) and which partner domains are approved, and record an expiry date and business owner for each.
2. Fix the top tier centrally: in the security investigation tool select the files, choose Actions > Audit File Permissions, and use the Links tab to change link sharing or the People tab to remove external users. Review the Pending Changes view before saving. Changes on shared drive files need the Drive Update or Delete privilege, and Google states that folder sharing and folder ownership cannot be changed this way, so folders need the owner or the Drive API.
3. Notify owners for the long tail: send each owner a list of their exposed files with a one-week deadline and a simple choice: keep (with a reason), restrict to named people, or remove. Many organisations find owners fix far more than expected once they see their own list.
4. Revoke what remains: after the deadline, remove links and external permissions centrally, logging every change. If a bulk action times out, narrow the date range and retry, as Google advises.
5. Tighten settings behind the clean-up: once exposure is down, move the OU to allowlisted domains, set new items to private by default and switch off "anyone with the link" where external sharing remains on. The CISA ScubaGoggles Drive baseline expresses these as GWS.DRIVEDOCS.1.1v1 (allowlisted domains only), GWS.DRIVEDOCS.1.5v1 (no anyone with the link where external sharing is allowed) and GWS.DRIVEDOCS.1.8v1 (new items private to the owner by default).
6. Roll back safely: keep the pre-change inventory snapshot and the change log, so a wrongly removed partner can be re-added by named user (never by restoring an anyone link) within the same day.

Pilot on one OU first. Run the full cycle (inventory, notice, revoke, settings change) on a team that shares externally a lot, measure the ticket volume, then roll out by OU in waves of a few weeks.

Where identity fits

• Service accounts in the sharee list: the inventory separates access.external_sharees.is_service_account, because files shared with service accounts usually come from integrations. Treat an external service account with access to sensitive files as a third-party integration to review, not as a person. See the How to Inventory third party oauth apps in google workspace guide.
• Your audit tool is a privileged identity: a Drive API scanner using domain-wide delegation can read every user's Drive. Scope it to read-only Drive metadata where possible, keep its key out of code, and review the grant. See How to audit Google Workspace domain-wide delegation grants.
• Leavers own exposed files: files owned by departed users keep their links. Transfer ownership and remove links as part of offboarding. See the Employee Offboarding Security Guide.

Detection and measurement

After the first clean-up, the audit becomes a recurring control. Alert in near real time on primary Drive events that set public_on_the_web, on external writer grants to consumer domains, and on external shares of files carrying your highest label. Re-run the inventory queries weekly. Track these metrics per OU:

• Public and discoverable files: count of files with allow_file_discovery true; target zero outside approved teams.
• Anyone-with-link files with a sensitive label or DLP match: target zero, measured weekly.
• External writer permissions: count and percentage on approved partner domains.
• Exposed files owned by inactive users: should fall to zero within your offboarding window.
• Median time from public share event to review: shows the alerting and triage loop works.
• Exceptions past expiry: exceptions kept beyond their agreed date, which should trend to zero.

Framework mapping

Common failure patterns

• Auditing settings and calling it exposure: a clean configuration report says nothing about the links created before the setting changed.
• Relying on six months of logs: the oldest and most forgotten links never appear in a log search. Use the inventory.
• Counting every log event: secondary events multiply the numbers; filter to primary events before reporting or alerting.
• Forgetting folders and shared drives: one external folder share or one external shared drive member exposes everything below it, and folders cannot be fixed through the investigation tool's bulk actions.
• Losing history: the inventory overwrites itself and expires after 60 days by default, so without a copy you cannot prove the trend to auditors.
• Bulk revoking without notice: breaking partner workflows overnight leads to blanket exceptions that undo the work.

Practitioner checklist

• Confirm which editions and OUs support the Drive inventory export and the security investigation tool.
• Enable the inventory export with external sharing calculations, a restricted dataset and a history copy.
• Validate the first export against known externally shared files.
• Run the five core queries: anyone links, discoverable files, external sharees by domain, published files, external writers.
• Score findings by audience, role, label, ownership and container, and fix the top tier centrally.
• Notify owners of the long tail with a deadline, then revoke and log every change.
• Record exceptions with a business owner and expiry, and review them monthly.
• Tighten OU and group sharing settings behind the clean-up, checking group overrides.
• Alert on new public and external writer shares using primary Drive events.
• Report the six metrics per OU monthly.

Standards and references

• Google: Export your organization's Drive inventory
• Google: Schema and example queries for Drive inventory exports in BigQuery
• Google: Reports API Drive activity events
• Google: Drive log events
• Google: Take action based on search results
• Google: Manage external sharing for your organization
• Google: Data retention and lag times
• CISA: ScubaGoggles Google Drive and Docs baseline

Related NHI Mgmt Group resources: Google Workspace Security Checklist · Google Workspace DLP and Data Protection Guide · Google Workspace Audit Log Detection Guide · Data Classification Guide