Getting Document Permissions Right

Permission models fail predictably. They start clean, accumulate exceptions, and reach a point where nobody can state who has access to a given document without inspecting it.

That point is not caused by carelessness. It is caused by exceptions being easy to add and nothing ever removing them.

Derive access, do not assign it#

The distinction that matters: is a document's access a property of what the document is, or of where somebody put it?

Assigned access — permissions set on a folder, then adjusted on a subfolder, then overridden on an item — encodes decisions in locations. Nothing records why, and nothing notices when the reason stops applying.

Derived access starts from two attributes the document already has: its type, and its confidentiality class. A supplier contract is visible to procurement and legal because it is a supplier contract, not because of the folder it happens to sit in. Moving it does not change who can see it, and reorganising the structure does not silently change the access model.

Keep the role list short#

Most organisations need fewer roles than they create. Owner, contributor, reviewer, reader, plus administrator — and then genuine confidentiality boundaries where content is restricted regardless of role: HR, legal privilege, board material, live commercial negotiations.

A model with fifteen roles is one where several have overlapping definitions, and overlapping roles mean access decisions get made by whoever assigns the role rather than by the model.

Exceptions need a reason and an expiry#

Genuine exceptions exist. A contractor needs one folder for three months. An auditor needs read access to a sample. Someone covering a colleague's absence needs their queue.

All three are legitimate and all three are temporary, which is the point. An exception should require a recorded justification and an expiry date at the moment it is granted, and it should lapse automatically. Exceptions that must be revoked by someone remembering are exceptions that persist for years.

This single rule is the difference between a model that stays explainable and one that does not, because exception accumulation is one-directional otherwise.

Design for the leaver#

The permission question that reliably goes wrong is what happens when someone leaves or changes role.

If access came from roles, removing the role removes the access, and the documents they owned need reassignment. If access came from accumulated per-item grants, deactivating the account leaves orphaned documents whose owner no longer exists and whose remaining permissions nobody can rationalise.

Two things are worth having in place before this happens rather than after: a report of documents owned by inactive accounts, and a defined reassignment path per document type.

What an access review needs#

An access review is only sustainable if it can be answered at the level of a document class rather than a document.

Which means two queries: who can see this class of document, and why — with the answer expressed as roles plus a short list of justified exceptions. If answering requires enumerating per-item permissions across thousands of documents, the review happens once, produces a spreadsheet nobody acts on, and is not repeated.

Reviews that are cheap get done quarterly. Reviews that are expensive get done when an auditor asks.

Least privilege has a failure mode too#

Restricting access further than necessary produces its own predictable outcome: people email copies. A document that the person doing the work cannot reach gets extracted, attached, and now exists outside the system with none of its controls.

So the correct target is not minimum access. It is accurate access — broad read where content is genuinely internal, tight control where it is genuinely sensitive, and a clear enough distinction that people do not need to work around it.

Over-restriction and under-restriction both end with documents in the wrong place. Only one of them looks responsible on a control matrix.

What to build before you need it#

Three reports, none of which is interesting until the moment it is essential.

Documents owned by inactive accounts, which is the leaver problem made visible. Permission exceptions past their expiry date, which is the accumulation problem made visible. And, per confidentiality class, the list of roles that can read it — which is the access review, prepared in advance rather than assembled under time pressure.

Each takes an afternoon to define and each answers a question that otherwise takes a week.