SharePoint document control
SharePoint document control: where it works, and where it stops.
SharePoint is a capable platform and most organizations should keep using it. The question is narrower than it first looks: whether your document controls are enforced by the platform, or by a configuration plus everyone continuing to follow it. That difference is invisible day to day and decisive at audit.
Being fair about it
What SharePoint is genuinely good at.
Storage, sharing, search, co-authoring, permissions at scale, integration with the tools people already have open, and an administrative surface most organizations already know how to run. For general business content that is a strong answer, and replacing it would be a mistake.
It is also genuinely configurable. Content types, metadata columns, approval flows, retention labels and Power Automate can be assembled into something that looks very much like document control, and plenty of organizations have done exactly that.
The argument on this page is not that SharePoint is bad. It is that a general-purpose platform enforces what you configure, and document control is mostly made of refusals — the things a system will not do even when an administrator, under pressure, would prefer it did.
Five tests, about ten minutes
Run these against your own tenant.
Not against a vendor comparison table. Your configuration is the only one that matters, and a tenant that passes these does not need to change anything.
Can an approved document still be edited?
Why it mattersThis is the load-bearing question and everything else follows from it. If the content behind an approval can change, the approval is a record of a decision about something that no longer exists.
What to watchApprove a test document, then try to change it as the owner. If it opens and saves, the protection is a convention. If a permission has to be removed first, the protection is a setting somebody can put back.
What was in force on a date eighteen months ago?
Why it mattersThe question an auditor actually asks. Not "what is current" — anyone can answer that — but what applied on a specific past day.
What to watchWhether the answer is read off a register in one step, or reconstructed from version timestamps, modification dates and somebody’s memory. Reconstruction is not evidence even when it produces the right answer.
Can a draft become the copy people find?
Why it mattersIn most general platforms the newest upload is the most prominent thing, whether or not anyone approved it. That is correct behaviour for collaboration and wrong for control.
What to watchUpload a new revision without approving it, then search as an ordinary user. If the unapproved revision is what they land on, the platform is answering "what is newest" rather than "what is in force".
Who could remove evidence of a change, and would anyone know?
Why it mattersAn audit trail that a sufficiently privileged person can prune is a trail that has to be trusted rather than verified. The distinction only surfaces when somebody has a reason to prune it.
What to watchWhether history is retained for a fixed period or forever, who can alter it, and whether removing an entry from the middle would be detectable afterwards by anyone.
Are review and approval genuinely separate authorizations?
Why it mattersEvery standard that touches document control treats them as different acts. Many configurations collapse them into one step with two labels.
What to watchWhether one person can complete both without that being a deliberate, recorded decision about their authority.
If your tenant passes all five, you have document control and you should keep it. If it passes them because of a configuration rather than because the platform refuses, the thing to check next is who can change that configuration, and whether the change would be visible.
The pattern worth knowing
Configured control decays; enforced control does not.
A configuration that implements document control is a real achievement, and it has an owner. It survives while that person is there, while the flows keep running, while nobody needs an exception badly enough to ask for the permission to be widened, and while the next administrator understands why each piece exists.
None of those hold for the life of a quality system. The failure is never dramatic — a flow is switched off during a migration, an exception is granted and not revoked, a library is copied for a project and the copy becomes the one people use. Each is reasonable on the day. The result is that the control existed when it was built, and the evidence has a gap where somebody needed it.
This is not a SharePoint property. It is true of any platform where the control is configuration rather than construction, and it is the reason document control is usually bought rather than assembled.
How DocumentSynth is different
The controls are properties of the system, not settings on it.
Configured control
- An approved document is protected by a permission
- Approval is a flow that can be bypassed or disabled
- “Current” is a column somebody maintains
- History is retained for as long as a policy says
- An administrator can undo any of it, helpfully
Enforced control
- A revision adds a version and never edits one
- Approval and signature are recorded acts, bound to a version
- One version is effective, enforced in the database
- Every state change is an append-only, hash-chained event
- There is no setting that turns those off
Most organizations move only their controlled documents — the procedures, policies and quality records where being current has to be provable — and leave everything else where it is. That is usually a small fraction of the total, and it is clearer than asking one library to behave two different ways. What to require of a document control system covers the evaluation in full.
Questions
What people ask at this point.
- Can SharePoint be used for document control?
- It can be configured to support a great deal of it, and many organizations run on exactly that. The question is not whether SharePoint can hold controlled documents — it can — but whether the controls are enforced by the platform or by the configuration and the people following it. That distinction is invisible day to day and decisive at audit.
- What is the difference between version history and version control?
- Version history records what changed. Version control decides what is in force. A system with history can still let an approved document be edited, let a draft become the copy people open, or leave two revisions looking equally current. Control means the system refuses those things rather than discouraging them.
- What should I test in my own tenant before deciding?
- Three things, and they take about ten minutes. Try to edit a document after it has been approved and see whether anything stops you. Ask what was effective on a date eighteen months ago and see whether the answer is read or reconstructed. Then ask who could remove evidence of a change, and whether anyone would be able to tell.
- Do we have to leave Microsoft 365 to get document control?
- No. Most organizations keep general content where it is and move only the controlled documents — the procedures, policies and quality records where being current has to be provable. Those are usually a small fraction of the total, and separating them is often clearer than trying to make one library behave two different ways.
- How is DocumentSynth different from a well-configured SharePoint library?
- The controls are properties of the system rather than of the configuration. A revision creates a version and never edits one; exactly one version is effective and the database enforces it; approval and signature are recorded acts bound to a specific version; and every state change writes an append-only, hash-chained audit event. None of those can be switched off by an administrator who is trying to be helpful.
Next steps.
Every request is reviewed by a person. Submitting the form does not create an environment or an account.