SharePoint governance: organising documents, permissions and archives – including before a Copilot rollout

SharePoint governance means the rules and oversight that govern how a company stores documents in SharePoint. Take a hypothetical manufacturing company with 200 employees that has used Microsoft 365 for five years. Every team in Teams has its own SharePoint site, because that is how Teams works. As a result, the company has several hundred document locations, many of them left over from finished projects.

The costs show up in three places. The first is time: a salesperson sends a quote on an old template because they could not find the new one, and an accountant searches three folders for an annex to a contract. The second is security: a former project manager still has access to a library with client data, and someone has shared a price list link with “anyone with the link”.

The third is every new digital project. An automated document workflow, an AI assistant or management reporting first exposes the mess, and then forces a clean-up in the middle of the rollout. It is cheaper to organise documents deliberately before you start the next project.

This is the most common misunderstanding when rolling out Copilot. According to Microsoft’s documentation, a company’s prompts, responses and documents are not used to train models. However, Copilot shows each user everything they have even read access to.

In practice, this means old permission mistakes come to light. If a file called “Salaries 2026.xlsx” sits on a site open to the whole company, nobody has found it so far because nobody was looking. Once Copilot is switched on, it is enough to ask about salaries in a department, and the assistant may point to that file.

Microsoft provides tools for this. When a company has even one Copilot licence, the administrator gets reports on sites shared too widely and the option to exclude selected sites from Copilot search. The reports show the problem, but someone on the business side has to decide who should see what.

Order in SharePoint does not start with a tool but with a few decisions that the management board should approve. Each has a technical answer, but the choice is a business one. The table below shows these decisions with sample answers for a mid-sized company – adapt them to your own scale.

In SharePoint the basic unit is the site: a separate space for the documents of a department, team or project, with its own permissions. Sites are grouped into areas using hub sites. This way, a project’s documents have their own place, but employees can still find them from the “Sales” or “Production” area.

This flat structure is easier to maintain than one huge site with ten levels of folders. You archive a finished project in one go, and you set permissions once for the whole site. In a mid-sized company, a few areas matching the departments are usually enough.

Remember the link with Teams. Every new team in Teams creates a SharePoint site in the background. If anyone can create teams without any rules, within two years the company has more sites than employees, and half of them are abandoned.

A folder tells you where a document is; a description tells you what it is. In SharePoint, the description is recorded in library columns: document type, client, status, expiry date, person responsible. A contract described this way can be found with a filter, even if you do not remember which folder it was saved in.

There must not be too many mandatory fields, because each extra one discourages the employee saving the file. A sensible compromise is two to four mandatory fields and a few optional ones. Some values can be set automatically, for example by assigning a default client to an entire project library.

Descriptions also help AI assistants. Copilot gives better answers to a question about “the current framework agreement with client X” when documents have a status and an expiry date, not just file names like “contract_final_v3”.

SharePoint lets you grant permissions to a site, a library, a folder and even a single file. After a year of working this way, nobody knows who sees what. The rule that works in practice is simple: grant permissions to the whole site, record any exceptions and set an end date for each.

Three levels are enough on every site: owners, who manage the site; members, who edit documents; and people with read access. Each level should correspond to a group that is updated when the company structure changes, not to a list of individual names. On top of that, there are a few rules worth setting straight away:

Retention periods come partly from the law and partly from company decisions. The table below lists the most common types of documents in a mid-sized company in Poland. It is for guidance, not legal advice – details depend on the industry and are worth confirming with your chief accountant or lawyer.

Once the periods are agreed, you set up retention policies in Microsoft Purview, the Microsoft 365 tool for protecting and retaining data. Documents in a given library will be protected from deletion until the end of the period, and can then be deleted automatically. Separately, set version history limits, either automatically or by number of versions, so that old versions do not take up space indefinitely.

The mess grows fastest when anyone can create a team in Teams or a site without being asked any questions. There is no need to ban this – a simple request is enough. A form in Microsoft Forms or Power Apps collects the name, purpose, two owners and type of data, and Power Automate creates the site from a ready-made template with the right permissions.

The second mechanism deals with abandoned sites. For example, decide that after six months without activity the owner is asked whether the site is still needed. After a year with no reply, the site becomes read-only and then moves to the archive.

Microsoft does part of this work automatically. With Copilot licences, policies are available that detect inactive sites and enforce a minimum number of owners. However, the company still sets the periods and makes the decisions about deletion.

Most companies do not start from scratch, but from several hundred sites and years of habits. Cleaning up everything at once rarely works, so it is better to proceed in stages and start with the highest-risk areas. The time needed depends on the number of sites and documents, so set the plan only after the first review. The steps are as follows:

Mistakes in organising SharePoint are usually organisational, not technical. The most common is launching Microsoft 365 without any rules and trying to clean up after several years, which costs far more than planning for order from the start. Others include permissions on individual files, no shared naming conventions and no retention periods, which leave decade-old documents sitting next to current ones.

To know whether the rules are working, a few simple indicators reviewed every quarter by the person responsible for governance are enough: