The 2026 Google Drive Security Audit Checklist for IT Admins

Most Drive incidents I have helped clean up did not involve a sophisticated attacker. They involved a finance shared drive that quietly accumulated 400 externally shared spreadsheets over four years, or a long-departed contractor whose Google account still owned the folder containing the company’s offer letters. Drive is sticky: permissions outlive the people, projects, and intentions that created them.

This checklist is the one I run for new clients during a Workspace security review. It is opinionated, it assumes you have Workspace Business Standard or higher, and it is sequenced so that the cheap, high-leverage controls come first. If you can only do the first three sections this quarter, do those.

1. External sharing inventory

Before you change a single policy, you need a defensible answer to the question “who outside the company has access to what?” Most admins underestimate this number by an order of magnitude. The fastest path:

1. Open the Reports > Audit and investigation > Drive log events page in the Admin console. Filter for Visibility = External over the last 12 months and export to BigQuery if your tenant supports it.
2. For tenants on Enterprise plans, run a security investigation tool query: actor.email matches anything AND visibility = "people_within_domain" OR "public" OR "people_with_link".
3. Bucket findings by file type, owning OU, and external domain. The 80/20 is almost always: a small number of OUs (Sales, Legal, HR) producing the majority of risky shares, and a long tail of one-off shares to personal Gmail addresses.

You are looking for two specific shapes of risk: files shared with personal email accounts (gmail.com, hotmail.com, proton.me) which break domain trust, and files shared with former vendor or partner domains that no longer have a contractual relationship.

2. Link sharing audit

Link sharing is the single largest source of unintentional data exposure in Workspace. The default in many tenants is still “Anyone in the company with the link” for new files. That sounds tame until someone forwards the link to a consultant who forwards it to their own team. We have written about why this is a bigger problem than it looks in Why ‘Anyone With the Link’ Is Quietly Your Biggest Drive Risk.

What to check

• Domain default for new files. In Apps > Google Workspace > Drive and Docs > Sharing settings, set the default to Off — only specific people for at least the parent OU.
• Existing public links. Drive log events with visibility = public reveals files that anyone on the internet can open. These are also indexable by search engines if linked from any public page.
• Link sharing on Shared Drives. Shared Drive permissions inherit differently than My Drive. Audit the Shared Drive members list and the per-folder target audience separately.
• Expired but still active links. Workspace supports access expirations, but only on commenter/viewer roles, and only when set explicitly. Old “Anyone with the link” shares from 2019 do not expire on their own.

3. OAuth app review

Every third-party app a user has connected with their Google account holds a token that can read, and often write, Drive content on their behalf — often forever. Token revocation does not happen automatically when an employee offboards. The app access control page in the Admin console is your control point.

1. Pull the full list of connected apps with the Admin SDK Directory tokens API. You want a CSV of (user, client_id, scopes, last_used).
2. Categorize: trusted (your IDP, MDM, security stack), known business apps, and shadow IT (everything else). Anything in the third bucket with Drive scopes is a candidate for revocation.
3. Move tenant-wide policy to restricted. Allowlist only the apps you have reviewed. New connections then require admin approval.
4. Set up a quarterly cadence for re-review. Apps you trusted 18 months ago may have had ownership changes, breach disclosures, or scope creep.

4. Domain-Wide Delegation hygiene

Domain-Wide Delegation (DWD) lets a service account impersonate any user in your domain across specified scopes. It is enormously powerful and, in my experience, almost always misconfigured by year three. The DWD list in Security > API controls > Domain-wide delegation is also one of the few places in Workspace where deletion is the safe default.

• Owner attribution. Every entry should map to a current employee, team, or vendor with a documented business reason. Anything else gets revoked.
• Scope minimization. A backup tool that only needs drive.readonly should not have drive. Trim scopes to the minimum required.
• Key rotation. If the underlying service account uses long-lived JSON keys, you have a credential lifetime problem. Migrate to Workload Identity Federation or short-lived credentials wherever possible.
• Logging. Confirm DWD usage shows up in your SIEM. The login audit log records impersonation events with the actor service account email.

5. Alerting

Detection without alerting is a ticket nobody opens. Workspace gives you several primitives — use them in this order:

1. Turn on the default alert center rules: leaked password, suspicious login, government-backed attack warning, and (critically) the “Drive settings changed” rule.
2. Add custom rules for: a single user externally sharing more than N files in 1 hour, files containing the strings SSN, PHI, or API_KEY being shared externally, and any new public link on a Shared Drive owned by Finance, HR, or Legal.
3. Pipe alerts into the same channel your on-call team already watches. An alert that lands in a forgotten security@ inbox is worse than no alert — it gives you a false sense of coverage.

If you want continuous risk scoring rather than rule-by-rule alerts, that is the problem ClearVew’s Risk Detection is designed to solve.

6. Retention and disposition

Audit findings tend to surface a parallel problem: data the company should have deleted years ago. Workspace retention is governed by Google Vault rules, which apply per OU and per service. The honest checklist:

• Confirm a default retention rule exists for Drive in every OU. “Indefinite retention” is a choice; make sure it is a deliberate one.
• For HR, Finance, and Legal, set retention windows that align with your records schedule. Most teams I work with land between 5 and 7 years for these OUs.
• Map your retention policy against the NIST Cybersecurity Framework (Identify and Protect functions). Auditors will ask.
• Document the disposition process — who approves, who executes, where the proof of deletion lives. Vault provides exportable evidence; use it.

Closing the loop

A one-time audit will surface a backlog. The harder discipline is keeping it closed. The teams I see succeed share three habits:

• A monthly 30-minute review of new external shares, owned by a named individual.
• A quarterly OAuth re-review, scoped to apps with Drive write access.
• Bulk remediation tooling so that the cost of fixing 200 over-shared files is minutes, not hours. That is what we built ClearVew’s Bulk Remediation for.

If you are an MSP running this checklist across multiple tenants, jump to The MSP Guide to Auditing Google Workspace Across Tenants for the multi-client variation. And if your policy work is what is really lagging, start with Google Workspace External Sharing: A Practical Policy Guide.