How to Use Unique Permissions for Libraries and Lists in SharePoint

With Microsoft 365 group permissions, all members (except administrators) have the same level of access to all Microsoft 365 applications and data associated with the Microsoft 365 group (e.g., Teams, SharePoint, Outlook, Planner, etc.). There are no areas blocked from their access. SharePoint is an exception because it also has its own permissions system, allowing further restriction of permissions. This is particularly advantageous for managing confidential data or in the context of the need-to-know principle in your project. Read on to become a SharePoint permissions pro!

SharePoint Has its Own Permission System

The Microsoft 365 Groups authorization system has been available for several years now. This tool allows you to grant your project team consistent permission across all Microsoft 365 applications simultaneously, such as Teams, SharePoint, Whiteboard, and OneNote. This has simplified the process of assigning permissions within project teams a lot.

SharePoint, on the other hand, has been around for many years—long before Microsoft 365 Groups were introduced. It has always had its own versatile permission system, particularly useful for assigning permissions based on the need-to-know principle. If you’re not familiar with Microsoft 365 Groups and their usage, you can learn more from these articles:

How to Use SharePoint Groups and Microsoft 365 Groups in Your Project Site

Are SharePoint Groups and Permissions No Longer Relevant with Microsoft 365 Permissions?

Balancing Default Permission Inheritance and Granular Access Control

All project team members should have access to all project information on the SharePoint site, but there is often confidential information that not everyone should or may have access to.

By default, all SharePoint sites, lists, and libraries in a site collection inherit permissions settings from whatever is directly above them in the site hierarchy. In a default installation, objects in a site collection inherit permissions from the site collection root.

A list inherits permissions from the site that contains. An item inherits permissions from the list to which it belongs. In all cases, the object (site, list, or library) from which permissions are inherited is known as the parent.

It’s ideal if user groups and their permission levels are the same for the whole SharePoint site. This is also the default setting in SharePoint.

In some cases, your site might contain content (libraries, lists or documents) only meant for certain users or groups. For example, if you have a list or a library on your site that contains sensitive data, you might want to restrict access to that data. In this case, it is useful to assign different permission levels to groups for certain lists or document libraries or delete a group, e.g. the Member Group from a library with confidential content.

Examples of sensitive data that your SharePoint project site can contain and that require special protection and restricted access may include:

1. Financial Information: Budget details, financial forecasts, expense reports, Daily Rates of contractors and invoices.
2. Personal Identifiable Information (PII): Employee records, contact information, Social Security numbers, and other personal data.
3. Proprietary Business Information: Trade secrets, business strategies, and confidential business plans.
4. Legal Documents: Contracts, non-disclosure agreements, legal correspondences, and compliance documentation.
5. Intellectual Property: Patents, trademarks, copyrights, and other intellectual property assets.
6. Project Plans and Reports: Detailed project plans, progress reports, and post-mortem analyses that may contain sensitive operational details.
7. Client Information: Confidential client data, project details, contracts, and communication records.
8. Health Information: Any health-related data that could fall under regulations like HIPAA.
9. Security Information: Access credentials, security protocols, and IT infrastructure details.
10. Audit and Compliance Records: Internal audit reports, compliance checklists, and findings

How to Break Permission Inheritance

To restrict access, you have to:

1.    Break permission inheritance of the respective list or library

2.    Edit permissions for this list or library in their library or list settings

Here is a use case: The user group “Members” have, for example, generally “Edit” rights to the full site. However, they should not have access to the Steering Committee Documents library. That means, you have to break the inheritance to the Steering Committee Library and then have to remove there the permission for the user group “Members”.

Another use case: The group “Members” should only see the PMO documents, but they must not change them. The group “Audit and Risk” should only see all documents of the entire site (Read). Only the user group “Program Management” is allowed to see the contracts and SOW’s with external contractors. Only the site “Owners” have access to confidential documents.
This means, you have to break the inheritance to many libraries and lists of your site to fulfill these requirements. However, I recommend that you do this as little as possible

How to implement this is explained here: Customize permissions for a SharePoint list or library (Microsoft)

You can set permission at the item level (e.g. single document or list item). Do this only in very seldom cases. This permission is very laborious to administrate, and you will lose very fast the overview which documents or items have unique permission.

Be aware, with breaking the permission inheritance, you can only influence the permission of the group on a library, list, or item, but this has no influence on the SharePoint group itself.

Users should have only the permission levels they need to perform their assigned tasks.

Best Practices for SharePoint Permission Design

• Establish a clear hierarchy of permissions and inherited permissions as much as possible
• Arrange sites, subsites, lists and libraries so they can share most permissions
• Break permission inheritance as infrequently as possible
• Assign permissions at the highest possible level
• Minimize unique and fine-grained permissions
• Avoid breaking inheritance to single list or document library items

Further Reading:
Understanding permission levels in SharePoint (Microsoft)

Best Practices for Authorizing User Access to SharePoint:

• Do follow the principle of least privilege. Users should have only the permission levels they need to perform their assigned tasks.
• Do limit the number of people in the Owners group (Full Control)—but have at least two.
• Do consider using Active Directory (AD) groups to secure SharePoint resources across multiple site collections when a standard set of users requires similar access.
• Reuse existing, organizational role-based AD groups where feasible, rather than creating new AD groups just for SharePoint.
• Don’t assign permissions directly to individual users. Instead, add them to an appropriate SharePoint group.
• Don’t assign permissions directly to AD groups. Instead, add AD groups as a member of SharePoint group.
• Don’t customize the default permission-levels. Instead, create new custom permission-levels, if required.

After you have read the last few bullet points, you will realize that you may have to break the inheritance to some libraries and lists on your site. But I recommend you to do it as little as possible.