Why external sharing is the control that fails most audits, and how to configure link sharing, guest access and expiry so it does not.
Every document platform supports “anyone with the link”. Every organisation has at least one folder where it is enabled and nobody remembers why. That combination is the single most reliable finding in a document platform audit.
The mechanism is worth understanding precisely, because the fix is configuration rather than technology, and the configuration is usually one default setting away.
Teams talk about “external sharing” as one thing. It is three, with different risk profiles.
Named guests are a controlled mechanism. The person is identified, the scope is a repository, and access can be revoked with an end date.
Organisation-wide links are widely treated as internal and are not. In a tenant with contractors, acquired companies and guest domains, the population that can follow such a link is larger than the team that created it understands.
Public links are the obvious risk, and the failure is rarely that someone enabled one deliberately. It is that a link created for a specific purpose was never revoked.
Four reasons, all structural.
The default is permissive. Many platforms enable link sharing tenant-wide or per workspace on creation. The path of least resistance is the risky one.
The creator is not the owner of the risk. The person sharing a file to unblock a partner is not the person accountable for a leak.
Revocation is nobody’s job. Links have no natural expiry unless one is set, so they persist beyond the relationship that justified them.
The audit is retrospective. By the time a review finds the open folder, the exposure has existed for months.
Configuration that fails closed, plus a review that catches drift.
Link sharing disabled by default, enabled per workspace with justification. This inverts the path of least resistance: creating an external link becomes a deliberate act.
The cost is friction, and it is worth being honest that it is real. Teams will complain. The alternative is a control that depends on everyone remembering.
For anything recurring, a named guest is strictly better: attributable, scoped, expirable, reviewable. Make guest access the documented route for external collaboration, and treat link sharing as the exception for one-off, low-sensitivity material.
Any external access should have an end date unless someone deliberately extends it. A guest without an end date becomes permanent by inattention.
Worth testing rather than assuming. Some platforms cache permissions, and a revoked link may continue to work for a period. Verify with a real link against a real document, then revoke and re-test.
You need to be able to answer: which documents are currently shared externally, with whom, and since when. A platform that cannot produce that list makes the review manual, and manual reviews do not happen on schedule.
External sharing reviews tend to converge on the same three questions, and the answers come from the platform rather than from policy.
What is shared externally right now? A list of documents with external access, the mechanism and the recipient. If producing this requires walking repositories, the organisation cannot answer the question, and that inability is itself the finding.
Who authorised it? For each external share, the person who granted it and when. Shared links with no owner are the ones that persist indefinitely, because nobody is positioned to revoke them.
When was it last reviewed? The date of the most recent examination of each share, and the outcome. A share reviewed and confirmed is a different thing from a share nobody has looked at since creation.
Answering these requires four platform properties:
The practical value of the third question is that it converts a review from “decide about everything” to “decide about the oldest and least used items”, which is a much smaller task and one that actually gets done.
Where a platform cannot answer these, the control depends on user discipline. That works in small organisations and reliably fails past a few hundred people.
Access control answers who can reach a document. These reduce the consequence when someone reaches it who should not.
| Control | Effect | Limitation |
|---|---|---|
| Watermarking | Discourages screenshots and identifies the source | Visible only, defeated by re-typing |
| Download restriction | Keeps content in the browser | Does not stop screenshots |
| Copy protection | Reduces casual exfiltration | Not a security boundary |
| Audit of external access | Makes exposure visible | Retrospective |
| Classification labels | Lets users judge what may be shared | Depends on correct classification |
None of these is a substitute for not granting the access. They reduce the blast radius of the cases the access control missed.
An assistant that retrieves content on a user’s behalf can surface documents the user could not have found, and the permission model determines whether it also surfaces documents they should not see.
The question to ask is whether retrieval filters by the requesting user’s permissions or by a service account’s. The second answer means external sharing controls are decorative once AI is enabled. Our AI agents security checklist covers how to test this.
Almost everything on this page is a settings decision. The reason external sharing keeps failing audits is not that the controls are missing, it is that the permissive default is the one nobody changed.
For a self-hosted deployment, those settings are yours to choose at installation rather than inheriting from a vendor’s tenant defaults — which is a modest but genuine advantage, and one worth configuring on day one rather than after the first review. Our access control article covers the internal side of the same model, and data residency requirements covers where externally shared content is allowed to travel.