SharePoint isn't a compliance system

Nearly every organisation I audit keeps its documents in Microsoft 365. Policies, procedures, method statements, certificates, training records — all sitting in SharePoint and OneDrive. And why not? It's already paid for, everyone can find it, and it syncs to the laptop on site.

Then the audit starts, and the same thing happens every time. I ask to see the current version of a procedure and its approval history. Someone opens a folder called "Policies FINAL", next to another called "Policies FINAL v2", next to "Policies (use this one)". The file's been edited eleven times; nobody can tell me which change mattered or who signed it off. And when I ask "show me the document that evidences this clause," the honest answer is a shrug and a search box.

SharePoint is superb storage. It is not, on its own, a compliance system. Those are different jobs, and confusing them is one of the most common reasons a well-run business trips at its ISO audit. Here's the difference — and the good news: you don't have to rip SharePoint out to fix it.

What "document control" actually means to an auditor

ISO 9001 clause 7.5 (and its equivalents across 45001, 27001, 14001 and 42001) doesn't ask you to have documents. It asks you to control them. When an auditor tests 7.5, they're checking for specific, demonstrable things:

• Version control — which version is current, what changed, and when. Not "last modified 14:32" — a real revision history.
• Approval — who reviewed and authorised this document, and can you prove it.
• Controlled distribution — the right people are working from the right version, and superseded copies aren't still in circulation.
• Traceability — this document evidences something: a clause, a risk control, a legal obligation, a corrective action. An auditor should be able to walk from the requirement to the proof in a couple of clicks.
• Retention & retrieval — you can produce it, in a defined timeframe, years later.

A SharePoint library gives you the first inklings of one of those (file version history, if it's switched on and nobody's overwritten it) and none of the rest. Folders don't know what a document is for. They can't tell you that "Working at Height Procedure v3" is the evidence for ISO 45001 clause 8.1.2, that it's linked to three hazards on your risk register, or that v2 should no longer be handed to a new starter.

Why the "just use SharePoint folders" approach quietly fails

It rarely fails loudly. It fails in the small, expensive ways that surface at exactly the wrong moment:

• The superseded-version trap. A subcontractor works from a method statement that was updated three weeks ago because it was still in the shared folder. Now it's an incident, and your "controlled document" wasn't controlled.
• The 4pm-Monday problem. Audit's tomorrow. Someone spends the evening screenshotting SharePoint into an evidence pack, hand-mapping files to clauses in a spreadsheet. That spreadsheet is out of date the moment a document changes.
• The search-box illusion. "It's all searchable" is true until an auditor asks for the relationship between things — this document, that risk, this training record, that corrective action. Search finds files. It doesn't build a golden thread.
• The knowledge-in-someone's-head risk. The only person who knows which folder holds what is the person who built the structure. When they're on leave — or leave — your document control leaves with them.

None of this is a criticism of SharePoint. It's doing its job. The mistake is asking a filing cabinet to also be an auditor.

You don't have to move your documents — connect them

The instinct, when you realise folders aren't enough, is to think you need to migrate everything into a new system and retrain everyone. You don't. The documents can stay exactly where your team already works. What's missing is a compliance layer on top that understands what each document is for.

That's why we built the Microsoft 365 / SharePoint integration in PICMS. An administrator connects their Microsoft tenant, browses their existing SharePoint document libraries, and imports the documents that matter. From that moment, each imported file stops being a loose file and becomes evidence:

• It's indexed for AI search, so you can ask questions of your documents in plain English instead of guessing folder names.
• It's auto-mapped to the ISO clauses it satisfies — the system reads the content and proposes which requirements it evidences.
• It's woven into the Golden Thread — automatically linked to the risks, incidents and corrective actions it relates to, so the requirement-to-proof chain an auditor wants is already built.
• It carries a proper version history from import onward, so 7.5 is satisfied by design rather than by folder discipline.

In other words: your team keeps using SharePoint for day-to-day work, and PICMS turns the compliance-relevant subset into an audit-ready evidence base — without a migration project, and without asking anyone to change how they save a file.

A simple way to think about it

Storage answers "where is the file?" Document control answers "is this the right file, who approved it, what does it prove, and can I show that to an auditor in one click?" SharePoint is very good at the first question. It was never built for the second.

You've already paid for the storage and your team already lives in it. The gap isn't a place to put documents — it's the compliance intelligence that turns those documents into defensible evidence. Bridge that gap, and the 4pm-Monday panic simply stops happening: the evidence pack isn't something you build the night before, it's something that's been quietly assembling itself all year.

SharePoint isn't a compliance system. It doesn't need to be. It just needs to be connected to one.