Three SharePoint permission mistakes that cost you later

Structure SharePoint permissions in three levels — site as the boundary, library as the content type, group as the role — and stop there. Permissions are where SharePoint implementations quietly rot, and three mistakes cause most of it: breaking inheritance on individual items, granting access to individuals instead of groups, and treating sharing links as an access model. Each one solves today's request in seconds and makes next year's audit much harder.

Why permissions rot

Nobody designs a messy permission model. It accumulates one reasonable request at a time: a contractor needs one folder, a manager needs to hide one spreadsheet, a client needs to see one drawing. Each request is handled by whoever is closest, in whatever way is fastest.

The cost does not show up until someone asks the question your auditor, insurer or client will eventually ask: who has access to this? For professional services firms holding client files, construction firms holding tender pricing, and for-purpose organisations holding client and case information, that question is not hypothetical.

1. Breaking inheritance on individual items

It solves today's problem in thirty seconds and creates a permanent one. Once a library has unique permissions on individual files, nobody can reason about who sees what, and audits become archaeology.

Instead: if a document needs different access, it belongs in a different library or site. Structure is the access model.

Breaking inheritance at the library level is sometimes reasonable — a "Board" library inside a leadership site, say. Breaking it on individual files and folders is where the trouble starts, because unique permissions are invisible from the library view. A person browsing the library sees the files they can open and has no way of knowing what they cannot. An administrator has to inspect items one at a time.

A practical rule: if you find yourself breaking inheritance more than once in the same library, stop and move that content somewhere with the right access by default.

2. Granting access to individuals

Sarah needs the folder, so Sarah gets the folder. Sarah leaves. Nobody removes Sarah, and nobody knows why her replacement cannot see it.

Instead: grant to groups that describe a role — Project Managers, Site Supervisors, Finance. Membership changes; permissions do not.

Use Microsoft 365 groups or security groups, ideally managed in Entra ID so that membership follows the HR process. When someone starts as a site supervisor, they join the Site Supervisors group and inherit everything that role should see. When they leave, removing their account removes their access everywhere at once.

3. Treating sharing links as an access model

"Anyone with the link" is convenient and completely invisible in your permission reports. A year later you cannot answer the question "who has access to this?" — which is the question your auditor asks.

Instead: disable anonymous links for sensitive libraries, and set an expiry on the rest.

SharePoint offers three link types: anyone with the link, people in your organisation, and specific people. Only the last one is tied to named identities. Anyone links can be forwarded without trace; organisation-wide links quietly give every staff member access to whatever was shared.

Sensible tenant defaults for most 50–500 person organisations:

• Default link type: specific people, so the safe option is the one people get without thinking.
• Anyone links: off for sites holding client, HR, financial or case data; allowed elsewhere only with an expiry.
• External sharing: on for sites that genuinely work with clients or subcontractors, off for everything else, set per site rather than tenant-wide.
• Guest access review: guests re-confirmed periodically, so a subcontractor from a project two years ago does not still have a login.

For ongoing external collaboration — a joint venture, a long project with a consultant — a dedicated site with guests in a named group is cleaner than a trail of links.

The structure that holds up

Three levels, and stop:

1. Site — the boundary. One team, one project, one function.
2. Library — the content type. Documents, forms, drawings.
3. Group — the role. Members, owners, visitors.

If you need a fourth level of exception, you actually need another site.

In practice that means more sites than people expect, each with simple permissions, rather than a few large sites with complicated ones. Sites are cheap; untangling permissions is not. A construction business might have one site per project created from a template, each with the same Project Managers, Site Supervisors and Client groups. A professional services firm might separate client-matter sites from internal practice sites. Hub sites tie them together for navigation and search without merging their permissions.

This is also why permissions belong in the design of an intranet, not as a clean-up afterwards — we treat them as part of every SharePoint intranet build, alongside the structure covered in why intranets fail.

Fixing an existing mess

You do not have to fix everything at once. Work from risk down.

Expect pushback on moving content. People are attached to folder paths. Explain that the new location is the one where access is correct by default, and leave a link in the old place for a few weeks.

Copilot raises the stakes. Microsoft 365 Copilot answers from everything a user can access, so content that was technically shared but practically hidden can surface in an answer. If you are planning a Copilot rollout, a permissions clean-up should come first. The same reasoning applies to anything you build with Copilot Studio.

A test worth running

Pick a document. Ask someone to tell you every person who can open it, without opening a permission report. If they cannot answer in fifteen seconds, your model is too complicated to govern.

What to do next

Run the fifteen-second test on three documents: one from finance, one from a client or project, and one from HR. If any fails, start with the sharing settings, which take an afternoon and close the biggest gap. Then work through the timeline above. If you want an independent view of where your tenant stands before a Copilot rollout or an audit, the free diagnostic audit covers permissions as part of it.