ISO 27001 and ISO 9001 in SharePoint: what you can prove with built-in tools and where that falls short

Part three of the series Documents in SharePoint. In part one we went through what SharePoint does out of the box, and in part two how to move off a file server step by step. Today, specifically: documentation for ISO.

When a company is weighing where to start moving documents into SharePoint, I almost always recommend the same thing: the ISO documentation. It’s a small area — dozens of documents, not hundreds of thousands. It has a clear owner. And above all, it’s where a file server really isn’t enough: the auditor doesn’t want to see a folder called “Valid policies”, but proof that only the approved version is valid, that you know who changed it, and that the people who should have access can get to it.

This part covers how to set that up in SharePoint with built-in tools, what you can show the auditor from it — and where the honest limit is, beyond which SharePoint can’t reach on its own.

What the standards require of documents

Both ISO 9001 and ISO/IEC 27001 have a section on documented information (according to the commonly quoted wording, clause 7.5 in both standards) with the same logic. Put simply, they want two things.

When creating and updating, a document should be properly identified (for example by title, date, author or number), have a suitable format and go through review and approval.

When controlling, a document should be available where and when it’s needed and adequately protected, and its distribution, access, storage, changes (that is, versions) and finally retention and disposal should be under control.

In clause 7.3, both standards also want people to be aware of the policy (the security policy or the quality policy, respectively) and of the consequences of not meeting the requirements of the management system. ISO/IEC 27001 then adds controls in Annex A that directly concern documentation. According to the commonly quoted wording of control 5.1, policies should be approved by management, published, communicated to the people concerned and acknowledged by them, and reviewed at planned intervals. According to the same wording, Annex A also contains controls on protecting records, access control and logging events.

The map: requirement, feature, licence

What the auditor wants to see	How SharePoint covers it	Licence
The valid, approved version	Content approval and major versions — readers see only the approved version	All plans for organisations
History of changes	Automatic version history: who, when, with the option to open and restore	All plans for organisations
Document identification	Required properties: number, owner, review date, type	All plans for organisations
Access control	Site and library permissions through groups; authors edit, everyone else reads	All plans for organisations
Who did what with the document	Microsoft 365 audit log, records kept for 180 days, with export to CSV	All plans for organisations (in Business plans an admin has to turn it on once); one year with E5
Protection against loss	93-day recycle bin and restore of the whole library within the last 30 days	All plans for organisations
Retention period and disposal	Retention labels	Manual labelling: Business Premium, E3; default library label and automatic labelling: E5
Employees having read it	SharePoint itself doesn’t record it	—

How to set up a library for controlled documents

It isn’t a complicated project. One site, one or two libraries and a few settings you make once.

A separate site with clear roles

Controlled documents belong on their own site, not in a team library where everyone saves things. Three roles are enough: authors (edit drafts), approvers (approve versions) and readers — the rest of the company, who only read the documents. All three roles as groups, not as individuals; when someone leaves or joins, you change group membership, not document permissions.

Major and minor versions with approval

In the library’s versioning settings, turn on major and minor versions and content approval, and under draft item security choose that drafts are visible only to people who can edit documents. A document in progress has version 1.1, 1.2, and authors and approvers can see it. Only approval creates major version 2.0, and that is what readers see; until then, they read the previous approved version. So the “valid version” isn’t a question of the file name, but of its status in the system.

Restricting draft visibility matters: without it, readers could also see versions still in progress. It has one side effect worth knowing about — people can’t fully sync a library with drafts restricted like this to File Explorer in Windows (it syncs read-only, or not at all). For controlled documents, though, that’s more of an advantage: people read in the browser, where the valid version always is, and not in a local copy.

Required properties and a template

For the “Directive” or “Policy” document type, set required properties — document number, owner, next review date, area — and a default template with the company header. Office then won’t save the document without these details. A file dragged and dropped into the library, however, can have them empty, so checking they’re filled in is part of approval.

A “for review” view

The standards want documents reviewed regularly. A library view filtered by next review date shows owners what’s overdue. If you want more, you can build reminders on it in Power Automate; to start with, the view and the owners’ discipline are enough.

Retention

If you have Business Premium or E3, create retention labels in line with your internal policy — for example “Keep for 5 years from last change”. The label ensures the document is kept for the set period even if someone deletes it, and once that period is over it can be deleted automatically. With these licences, a person applies the label to each document manually; setting it as the default for the whole library or applying it automatically requires E5. For dozens of controlled documents, manual labelling is manageable — it just needs to be part of approval. Without these licences, retention relies on rules and on the recycle bin and library restore, which, however, cover only days, not years.

What the auditor will see

With the library set up like this, you answer the auditor’s typical questions from one place:

• “Show me the valid version of the security policy.” Open the library as a reader — you’ll see only the approved version.
• “When was it approved?” Version history shows when the major version was created, and the approval status carries the approver’s comment. Who is responsible for the document is in the required “owner” property.
• “What changed compared with the previous version?” Open the older version from the history next to the current one.
• “Who has access to it?” Library permissions through three groups instead of a tree of exceptions.
• “Who opened or downloaded it in the last quarter?” An export from the Microsoft 365 audit log.

With a file server, all of these questions get answered with a manually kept spreadsheet, file naming or digging through a log.

Where SharePoint alone falls short

To be honest: there’s one important thing SharePoint can’t prove on its own. That employees have read the policy — who, which version and when, and who hasn’t yet. The audit log shows that someone opened the document, but opening isn’t reading. And for security policies, according to the commonly quoted wording of control 5.1, “communicated and acknowledged” is right there in the requirement.

Other things the built-in tools cover only partly:

• Multi-level approval (owner, then security manager, then management). Built-in content approval is single-stage, and the newer approvals in libraries can handle several approvers at once (one is enough, or all must approve), but not one after another; a multi-stage process is built in Power Automate.
• Repeating acknowledgement regularly — for example, an annual reminder of the security policy to all employees.
• A completion overview — what percentage of people have confirmed the current version, by team.

How to handle this — manually, in Power Automate or with a specialised app — is the topic of the last part.

Key takeaways

1. ISO documentation is the ideal first step. Small scope, a clear owner and a benefit you can see at the very next audit.
2. Approval, versions, permissions and auditing are in your licence. One well-configured library is enough; retention for years needs Business Premium or E3/E5.
3. Opening isn’t reading. Proving that people know the policy is the only part SharePoint can’t cover on its own — and the auditor asks about it.

---

At EP365 we help companies prepare SharePoint for controlled ISO documentation — from designing the site, roles and libraries, through retention labels, to training document owners. Usually as part of governance design. If you have an audit coming up, get in touch — we’ll go through what you have and what’s missing.

In the last part: how to prove to the auditor that people have read a policy, and what the new Czech Cybersecurity Act says about it. We’ll compare an attendance sheet, a Power Automate solution and specialised apps.