Blog

What document governance is, and what it is not

Document governance is the practice of making an organisation's documents answer four questions — which are required, what state each is in, who may open it, and what has happened to it. Storage answers none of them.

Four columns headed Required, State, Access and History, each one a question a document store cannot answer on its own.

Document governance is the practice of making an organisation's documents answer four questions at any moment: which documents are required, what state each one is in, who is allowed to open it, and what has happened to it. A system that stores files answers none of those. That gap is the whole subject.

The confusion is understandable, because the two look identical from the outside. Both show folders. Both let you upload. The difference only appears when somebody asks a question that a folder has no opinion about.

The four questions

Which documents are required. A folder holds whatever was put in it. Governance starts from the opposite direction: the process declares what a complete case looks like — an identity document, a signed contract, a proof of address — and every case is created already knowing that list. The difference is not a checklist somewhere. It is that "complete" becomes a property the system can evaluate, rather than a judgement somebody makes by looking.

What state each document is in. A file exists or it does not, and that is all a store can say. A governed document has a position: missing, partially delivered, uploaded but unread, validated, rejected and awaiting correction, or expired. Expiry matters more than it sounds — an insurance certificate that was valid when it was filed is not evidence today, and nothing about the file itself records that.

Who may open it. Not "who has the link". Access that depends on nobody having forwarded something is not access control. Governance means the answer is computed from who the person is and what the document belongs to, and that the same rule applies whether the document is reached through a screen, an API, or a search result.

What has happened to it. Who added it, who read it, who decided on it, when, and what it looked like at the moment of the decision. This is the question that separates answering an audit from preparing for one. Preparing means reconstructing the history from email and memory; answering means reading it.

Why "we already have a DMS" is usually true and rarely enough

A document management system is genuinely good at the first half of the problem: putting files somewhere sane, versioning them, searching them. What it typically does not model is the process those files belong to — the sequence, the conditions, the decisions.

So teams fill the gap with the tools at hand. The required-document list lives in a spreadsheet. The approval happens in an email thread. The check that everything arrived is a person remembering to look. None of that is careless; it is what you do when the system has no place to put it. But each of those is a control that exists only while somebody is paying attention, and controls of that kind fail quietly. Nobody notices a checklist that was not run.

The part that has become urgent

There is a newer reason this matters, and it is the one that has changed the conversation in the last two years: AI is only as reliable as the documents behind it.

An assistant that answers from your documents will answer from whatever it can reach. If it can reach an outdated policy, it will quote the outdated policy — confidently, in fluent prose, with no signal that anything is wrong. If it can reach a document the asker was never allowed to see, it has just leaked it, and the leak looks like a helpful answer.

Neither of those is a flaw in the model. Both are governance failing one layer down. Which documents are current, which are complete, and who may see them are exactly the four questions above, and an assistant inherits whatever answer the organisation already had.

What it looks like when it is working

A case is created and already knows it needs three documents. Two arrive; the third does not, and the case cannot be submitted for approval — not because somebody objected, but because the transition is refused. The approver sees the case as it stood at that moment, and their decision is recorded against that state rather than against whatever the case became afterwards. When the last approval lands, the process does not end in a folder: it calls the system that actually owns the operation and closes with the reference that came back. Six months later, somebody asks why that decision was made. The answer takes a minute, and it is a record rather than a reconstruction.

None of this is exotic. It is the ordinary shape of a governed process, and the reason it is worth naming is that the alternative — files in a store, rules in people's heads — looks the same right up until the moment somebody asks.

All articles

Get started

See it on your own documents

Open a free account, or tell us what your files look like today.