File sharing policy: a page people can actually follow

A file sharing policy exists because people will send things outside the company and you would rather they did it in a way you can see. Most versions of this document fail the same way: they are written as prohibitions, so the only compliant option is to do nothing, and the actual behaviour moves to personal accounts where nobody can see it at all.

What a file sharing policy should state

• Which categories of material may be shared externally at all, named in terms people recognise rather than in classification labels nobody applies.
• The approved route — the system, not the mechanism of the week — and that personal accounts and messaging apps are not it.
• Whether external links must be named-recipient or may be open, and the default expiry.
• Who may approve an exception, because a policy without an exception route is one people route around.
• What must be recorded: who shared what, with whom, and when.
• How long external access lasts by default, and who reviews it.

Write the permitted path, not just the prohibition

The test of this document is whether somebody with a genuine need can read it and know exactly what to do in the next sixty seconds. If the answer is "ask IT", the policy has outsourced itself to a queue and will be bypassed by anybody working to a deadline. State the normal case plainly — most sharing is unremarkable — and reserve the heavy language for the categories that deserve it, which in most companies is personal data, unreleased financials and anything under a confidentiality obligation to somebody else.

The riskiest share is rarely a document going to a stranger. It is a file shared correctly with a supplier two years ago and never revoked, because the project ended and nobody owned the link. Expiry dates do more for this than any classification scheme.

Making it enforceable

1. Set the system defaults to match the policy — team-only sharing, link expiry on — so the compliant path is the default path.
2. Review external shares quarterly against a list of current suppliers and clients.
3. Revoke on project close and on leaver departure, as a step in both checklists rather than as a separate task.
4. Log exceptions with the approver and the reason; a growing exception log tells you the policy is wrong somewhere.
5. Re-read the document once a year and delete anything it says that the system now does automatically.

Where people actually go wrong

Three things, in order of frequency: sharing a whole folder when one document was needed, forwarding a link onwards so the audience is now unknown, and using a personal account because the approved route was slower. The first two are settings problems. The third is a product problem on your side of the fence, and no amount of policy language fixes it.

Ettex Storage supports the enforceable version: team-level defaults, per-person permissions, expiring external access and an exportable log of who opened what. Keeping it beside an access control policy means the two documents cover different questions — what may leave, and who may see it internally — rather than repeating each other.