Google Workspace External Sharing: A Practical Policy Guide

External sharing is not the problem. Unmanaged external sharing is. The companies I see get this right do not ban external collaboration; they make it easy along well-lit paths and inconvenient everywhere else. This post is the policy-shaped companion to Why ‘Anyone With the Link’ Is Quietly Your Biggest Drive Risk.

The Workspace controls are powerful but spread across half a dozen pages in the Admin console. The point of this guide is to put them in one mental model and give you a sequence to roll them out without breaking the business.

A working mental model

Think of external sharing as a layered system with five concentric rings:

1. Allowlisted trusted domains — partners, subsidiaries, vendors with active contracts. Default sharing should “just work.”
2. Known external organizations — domains you have shared with before but have not formally trusted. Allowed, but with friction.
3. Unknown business domains — companies you have never shared with. Allowed with a warning and a justification.
4. Personal email providers (gmail.com, hotmail.com, etc.) — blocked by default for sensitive OUs.
5. Anonymous link sharing — off by default, opt-in per file with expiration.

Workspace has a mechanism for each ring. The job is to wire them up.

Trusted domains and target audiences

Workspace lets you define a list of trusted external domains in Apps > Google Workspace > Drive and Docs > Sharing settings. Files shared with users in those domains do not trip external warnings and can be allowed even when other external sharing is restricted.

Layer this with target audiences— a feature that lets you define named recipient groups (e.g., “Acme Project Team”) that show up in the share dialog as preset audiences. The combination is what you want: users get one-click sharing to defined external groups, and you get a managed list you can audit.

Pitfalls

• Trusted does not mean read-only. A trusted domain still gets whatever permission level the file owner grants. Trust is about reducing friction, not reducing scope.
• Subsidiary domains drift. Mergers, divestitures, and rebrands mean your trusted list is stale within 12 months unless someone owns it.
• Catch-all wildcards are dangerous. Trusting *.partner.com sounds convenient but allows any-subdomain.partner.com — including ones the partner has not properly secured.

Warnings at share time

The lowest-cost, highest-leverage policy you can ship is the external sharing warning. Under Drive and Docs > Sharing settings > Warning when sharing outside [domain], turn this on. The dialog requires the user to explicitly confirm. Internal data from clients we have rolled this out to consistently shows a 30 to 50 percent reduction in casual external shares within the first month — entirely from people pausing on the warning and choosing not to proceed.

Access expiration as the default

Workspace supports access expirations on commenter and viewer grants. The right policy is to set a sensible default through user education and tooling: 30 days for ad-hoc external shares, 90 days for active project collaborations, custom for contracts and vendor engagements with known durations.

Workspace itself does not currently force a default expiration on external shares, but you can enforce it via:

• An organizational policy and quarterly compliance check.
• An admin script that auto-expires shares aged beyond a threshold.
• A tool like ClearVew that surfaces stale external shares for review and one-click revocation. See Bulk Remediation.

OU-level overrides

Not every team has the same risk profile. Marketing legitimately shares decks with dozens of agencies a week. Finance does not. Workspace policy is hierarchical by OU, so the right pattern is:

1. Tighten the root OU. Default for the entire domain: external sharing on, anonymous link sharing off, warnings on, trusted domains allowlist enforced.
2. Loosen for collaboration-heavy OUs. Marketing, Sales, BD: allow slightly broader external sharing, perhaps including link sharing with expiration.
3. Tighten further for sensitive OUs. Finance, Legal, HR, Engineering with production access: external sharing off by default, requires admin approval. Couple with DLP rules that block sharing of files containing PII or financial identifiers.

For more on how DLP fits into this picture vs. a dedicated audit tool, read DLP vs Drive Audit Tools: When You Need Which.

A non-disruptive rollout sequence

The mistake I see most often is treating this as a one-shot policy change. Sequence matters:

1. Week 1 — Inventory. Pull a baseline of current external shares. See the audit checklist for the queries.
2. Week 2 — Communicate. Send a short, plainspoken note to the company explaining what is changing and why. Include the trusted domain list and a self-service request process.
3. Week 3 — Enable warnings. Lowest-impact change. Watch the data for 14 days.
4. Week 4 — Restrict sensitive OUs. Apply tighter policy to Finance, Legal, HR. Validate that no business-critical workflows broke.
5. Week 5 — Address the backlog. Begin the cleanup of pre-existing public links and stale external shares. Bulk remediation tooling pays for itself here.
6. Ongoing — Monitor and re-review. Quarterly review of trusted domains, alerts on new public link creation, monthly review of newly-shared sensitive files.

Anti-patterns

• Approval-based sharing for everything. Routing every external share through a security ticket queue is a recipe for shadow IT. People will email files instead. Reserve approval flows for genuinely sensitive OUs.
• Lists that nobody owns. A trusted domains list with no named maintainer is a stale trust list within a year.
• Policy without telemetry.If you cannot answer “how many external shares were created last week, by whom, to which domains?” you do not have a policy — you have a wish.
• Treating Drive as a silo. External sharing in Drive is one of three or four egress channels for company data. Email forwarding, Calendar attachments, and Slack file uploads are the others. Coordinate.

Closing thought

Good external sharing policy looks boring from the user’s perspective: their common cases just work, their unusual cases prompt a small pause, and their truly risky cases are blocked or escalated. Building toward that quiet experience is the whole game.

If you are running this across more than one tenant, the multi-client mechanics get interesting — see The MSP Guide to Auditing Google Workspace Across Tenants.