Policy management software vs SharePoint and Excel: which do you actually need?

Most organisations keep their policies in SharePoint, a shared drive or Excel, and for storing and sharing documents those tools are perfectly capable. So the real question is not whether they can hold policies — they obviously can — but whether storage is the job. Policy management is really about three things a file store does not do: keeping policies reviewed on time, enforcing one current version, and proving staff have actually read them. This is an honest comparison of SharePoint and Excel against dedicated policy management software, so you can decide whether what you have is genuinely enough or whether the gaps are the kind that fail inspections.

What SharePoint and Excel do well

It is worth starting with the strengths, because they are real. SharePoint stores documents, controls who can access them, keeps a basic version history, and lets people find and open the current policy. Excel gives you a register — a list of policies with owners and review dates. For a small organisation with a handful of policies and no external scrutiny, that genuinely may be enough, and adding dedicated software would be over-engineering. If nobody inspects your policies and a lapsed or unread one costs you nothing, a well-kept SharePoint library is a reasonable home for them.

Where they fall short

Review tracking. Neither SharePoint nor Excel will tell you a policy is overdue for review. The next-review date sits in a column or a metadata field that nobody looks at until something prompts them, and by then it is late. A policy that has drifted three years past its review date is one of the most common findings against a policy set, and a passive file store does nothing to prevent it.

One current version. SharePoint has version history, which sounds like version control but is not the same thing. History lets you look back; it does not stop a member of staff opening, downloading or printing an old copy and working from it. There is no single enforced current version placed in front of everyone, so in practice different people can be following different versions of the same policy without anyone realising.

Proof of reading. This is the decisive gap. Neither tool can prove a member of staff has read and understood the current version of a policy. You can email a policy round, or post it to a channel, but you cannot show, on demand, who actually opened and acknowledged it. When a regulator asks you to demonstrate that your team knows the safeguarding policy or the health and safety policy, "it is on SharePoint" is not an answer — and it is exactly the answer that fails.

Why the third gap is the one that matters

Of the three, proof of reading is the one that most often turns a good organisation into a poor inspection result. Inspectors and auditors are not satisfied that a policy exists; they want evidence it is lived. A care provider has to show staff have read and follow the current safeguarding policy; a construction firm going for CHAS has to show its health and safety policy is more than a document; a school has to evidence that its policies are known. A file store can prove a policy was published. It cannot prove it was read, and that is precisely the evidence that is asked for.

What dedicated policy management software adds

Policy management software keeps the storage but adds the three missing pieces. Review dates surface automatically as they fall due, so nothing drifts. Version control puts one current version in front of everyone, with older versions archived rather than accidentally in circulation. And staff acknowledgement is captured as people read each policy, so you hold a record of who has read what and when — the evidence, not just the claim. It is the difference between a place to keep policies and a system that keeps them healthy, current and provable. In every other respect it feels like the file library people are used to; it simply does the active work a library cannot.

A worked example

Imagine a care provider that updates its medicines policy after an incident. In SharePoint, the new version is uploaded and an email goes round asking staff to read it. Some do; some do not; a few open the old version they had bookmarked. Weeks later a CQC assessor asks the provider to demonstrate that staff are working to the current medicines policy. The provider can show the policy exists and was emailed. It cannot show who read it, cannot guarantee nobody is following the superseded version, and has no record of acknowledgement. In a policy management system, the same update would have set a new current version, retired the old one, prompted every relevant member of staff to acknowledge it, and produced a live record of who had — exactly what the assessor is asking for. The event is the same; the ability to evidence it is completely different.

How to decide

The decision comes down to scrutiny. If nobody inspects your policies and a lapse or an unread policy costs nothing, SharePoint or Excel is fine, and you should not spend money solving a problem you do not have. If you are inspected — care, education, construction, any regulated sector — and you need to prove your policies are current and read, the three gaps above are exactly what will be found, and dedicated policy management software is worth it. A useful test: imagine an inspector asking you to prove staff have read your most important policy. If you could answer confidently today, you may not need the software. If the honest answer is "we sent it round", you do.

What about a hybrid approach?

Some organisations try to bridge the gap by keeping policies in SharePoint and bolting on a separate acknowledgement tool, or by running a manual sign-off sheet alongside the library. This can work, but it reintroduces the very problem you were trying to solve: two systems that drift apart, where the acknowledgement record and the current policy are maintained separately and nobody is quite sure they match. If proof of reading matters enough to add a tool for it, it usually makes more sense to have the policy, the version and the acknowledgement in one place, so the record cannot disagree with itself. A hybrid is better than nothing, but it tends to be a stepping stone to a single system rather than a stable destination.

Getting started without a big project

The fear that moving policies into dedicated software is a major migration keeps many organisations on SharePoint longer than they should be. In practice it is straightforward: load your current policies, set each one's review date and owner, mark the current version, and ask staff to acknowledge the ones that matter most first. You do not need to migrate historical versions or acknowledgements — the value is in getting the current position accurate and letting the record build forward from there. Within a short time you have policies that review themselves, one version everyone sees, and a growing record of who has read what, without ever having run a formal project.

Where Complys fits

Complys versions every policy, tracks review dates and records staff acknowledgement, so your policies stay current and you can prove they are read — and it sits alongside your certificates, training and audits in one compliance record rather than as a separate silo. It helps you organise and evidence your policies; it does not certify your organisation. If SharePoint has been quietly failing the review, version and proof-of-reading tests, that is the gap it closes.