One of the topics that generates the most questions when organisations start using SharePoint is permissions. Who can see this document? How do I stop HR from seeing the executive contracts? Why can't my colleague edit this file?
SharePoint permissions are powerful — perhaps too powerful if you don't understand them properly. This article explains how they work and how to structure them sensibly for a mid-sized business.
How the permissions model works
SharePoint has three levels where you can assign permissions:
Site → Library or List → Folder or Document
By default, everything inherits permissions from the level above. If someone has access to the site, they have access to all libraries within that site — unless you break inheritance at some point.
The basic permission levels
SharePoint uses three main roles that cover most cases:
| Role | Can do |
|---|---|
| Owner | Everything — manage permissions, delete, configure |
| Member | Create, edit and delete documents |
| Visitor | Read only |
For most organisations, these three roles are sufficient. The temptation to create complex custom permission levels usually creates more problems than it solves.
If you need more granularity, SharePoint has additional permission levels:
| Level | Can do |
|---|---|
| Full Control | Everything, including managing permissions |
| Design | View, add, edit, delete, approve and customise |
| Edit | Add, edit and delete lists, documents and items |
| Contribute | View, add, edit and delete documents and items |
| Read | View and download documents |
| View Only | View documents but not download them |
In practice, Owner, Member and Visitor cover 95% of cases. The additional levels are useful in very specific situations — for example, if you need someone to be able to add documents but not delete them.
Permissions are visible — or invisible
An important concept that many people don't know: in SharePoint, if you don't have access to something, that content is invisible to you. You don't see an "access denied" message — it simply doesn't exist.
An HR site you don't have access to doesn't appear in the navigation. Documents from that site don't appear in search results. For you, that content doesn't exist. This is a huge advantage for privacy and security — but it also means you need to make sure the right people have the right permissions, because if they don't, they won't even know the content exists.
SharePoint groups vs Microsoft 365 groups
You can assign permissions in two ways:
SharePoint groups — specific to each site. Useful for managing who accesses what within a particular site.
Microsoft 365 groups (or Entra ID groups) — managed from the admin centre and can be used across multiple sites. More recommended for organisations that want centralised access management.
The general recommendation is to use groups — never assign permissions directly to individual users. If someone leaves the organisation, you remove them from the group and they lose access to everything at once. If you have per-user permissions, you have to go site by site looking for where they appear.
One thing you can't do with groups
SharePoint groups cannot be nested — you can't put a SharePoint group inside another SharePoint group. However, you can add the following inside a SharePoint group:
- Microsoft 365 groups
- Entra ID security groups
- Individual users
This means the correct way to manage teams is through Microsoft 365 or Entra ID groups, not by trying to create hierarchies of SharePoint groups.
Sharing and its consequences
One of the least understood aspects of SharePoint is what happens when users share content.
Sharing breaks inheritance
Every time a user shares a file or folder with someone, SharePoint automatically breaks permission inheritance for that item and creates unique permissions. Over time, a library can end up with dozens of items with different permissions — very difficult to audit and manage.
Members can share with others
By default, users with the Member role can share the site or its content with other people — adding them to the Members group without the owner knowing. If you have a site with sensitive content, configure the Access Request Settings to prevent this.
Only Owners can revoke shared access
Members and Visitors who have shared content cannot undo that access. Only site Owners can do so. Make sure your Owners are aware of this responsibility.
Sharing links — a risk that's not always visible
SharePoint offers different types of link when you share a document or folder:
| Link type | Access |
|---|---|
| People in your organisation only | Only users with an account in your company |
| Specific people | Only the people you explicitly name |
| Anyone with the link | Anyone on the internet, with no authentication required |
The last type — "Anyone with the link" — is the most dangerous. If someone forwards that link by email or posts it somewhere, anyone in the world can access the document with no barrier.
For organisations handling confidential client information or personal data, this link type should be disabled at the tenant level. From the Microsoft 365 admin centre, the administrator can restrict which link types are available to users.
Permission inheritance — what it is and when to break it
This is one of the most important concepts for understanding how SharePoint permissions work.
What is inheritance?
By default, everything in SharePoint inherits permissions from the level above. A library inherits the site's permissions. A folder inherits the library's permissions. A document inherits the folder's permissions. If you give someone access to the site, they automatically have access to all content within that site.
What does breaking inheritance mean?
Breaking inheritance means disconnecting an item from the level above and creating unique permissions for that item. From that point on, changes to the site's permissions no longer affect that item — it has its own independent access configuration.
When is it appropriate to break inheritance?
The most common and most justified case is at the library level — for example, an HR documents library within a general site that needs to be visible only to the HR team. Breaking inheritance on the library and assigning specific permissions is the correct solution here.
Why should it be the exception, not the rule?
The more items have broken inheritance, the harder it is to manage and audit who has access to what. Imagine someone leaves the organisation — you have to review not just the site groups, but also every library, folder and document with unique permissions to make sure that user no longer has access anywhere. With clean inheritance, you remove the user from the group and you're done. With dozens of broken inheritances, you have a massive audit job on your hands.
The golden rule: break inheritance only when the site structure cannot solve the problem on its own. If you need to permanently separate access, the right approach is to separate the content into different sites from the start.
The most common mistakes
Unique permissions at too many levels
The more items have broken inheritance, the harder it is to manage who has access to what. The golden rule: maintain inheritance wherever possible. Only break it when it's truly necessary and there's no other solution.
Giving Member access when Visitor would do
By default, many administrators give everyone Member access "so they can work". The result: anyone can delete or modify documents. For content that only needs to be read, use Visitor.
Permissions at the individual document level
Breaking inheritance at the level of an individual document is technically possible but a maintenance nightmare. If you need to separate access at that level of granularity, the most likely answer is that you need a separate library.
A sensible structure for a mid-sized organisation
For most organisations, a structure like this works well:
- General intranet site — Visitor access for the whole company
- Each department site — Member access only for that department
- Leadership site — restricted access to leadership and administration
- HR site — very restricted access, only the HR team
Each site inherits internally, without breaking permissions at library or document level except in very specific cases.
Permissions and regulatory compliance
If your organisation handles personal data (clients, employees), SharePoint permissions are part of your GDPR compliance. Personal data must be accessible only to those who need it. A periodic permissions audit is not optional — it's an obligation.
Microsoft Purview and the Microsoft 365 admin tools allow you to audit who has accessed what and when.
Need help reviewing or restructuring your SharePoint permissions?