SharePoint: Understanding the Permission Inheritance Hierarchy

Summary

This article provides information on the permissions inheritance hierarchy within SharePoint and how to plan your SharePoint site to ensure your information is secure.

Content

To ensure information is secure, it is important to understand the SharePoint Permission Inheritance Hierarchy. Information on a SharePoint site is contained in a subsite, list, library, folder, file, etc. These are all securable objects, meaning that permissions can be assigned to allow/restrict access. Owners of a SharePoint site can change permissions to allow/restrict access to information.

By default, permissions on subsites, lists, libraries, folder, etc. are inherited from their parent SharePoint site - the site that contains them. You can, however, break the inheritance for any secure object at a lower level in the hierarchy. After breaking the inheritance, you can create a unique permission assignment for that securable object. For more information about breaking permission inheritance and creating unique permission assignments, refer to SharePoint: Managing Inherited Permissions.

SharePoint sites themselves are securable objects that have assigned permissions. When you create a SharePoint site, an Office 365 Group is assigned. Members of that group can view and/or edit the contents of the site. Group members can also share a securable object (files, folders, etc.) with non-members. When a member shares a document or other individual item with a non-member, permission inheritance is automatically broken for that item. The inherited permissions are copied to the item, and permissions for the non-member are added (making it unique), but if permissions are changed to the parent item (folder, library, etc.), those changes are not applied to the non-member's shared item. For more information about securing access to site content for non-members, refer to SharePoint: Using the Manage Access Option to Manage File/Folder Permissions.

You can create other sites within the original site. These subsites inherit permissions from your initial SharePoint site. Any changes you make to the permissions on the parent site should be appropriate for the parent site and all subsites that inherit those permissions. A parent site and its subsite share the same set of permissions. This means that owners of subsite can change the permissions of the parent (original site) when they make changes to the permission of the sub-site. Owners can break the inheritance and create unique permissions for a sub-site.

Site to Subsite Inheritance Hierarchy

	Explanation
	Subsite 1 inherits permissions from the Top-Level Site. Any changes made to SharePoint groups and permission levels on the Top-Level Site also affect Subsite 1.
	Subsite 2 inherits permissions from its parent (Subsite 1). However, because Subsite 1 is also inheriting permissions from its parent, changes made to SharePoint groups and permissions levels on the Top-Level Site affect Subsite 2 also. This is because you cannot manage permissions on a sub-site that is inheriting permissions. Instead, you either manage the permissions of the parent (i.e. Top-Level Site) or you break the inheritance and create unique permissions.
	Subsite 3 has unique permissions. The sub-site owner broke inheritance and created these unique permissions. It does not inherit permissions from its parent site. Any changes made to the permission levels and SharePoint groups on Subsite 3 do not affect its parent site.
	Subsite 4 inherits permissions from Subsite 3, so any changes to permission levels or SharePoint groups on Subsite 3 affect both sites.

Each site/subsite contains additional securable objects which have a particular position in the site hierarchy.

Site/Subsite Securable Object Permission Inheritance Limitations

	Limitations
	When a list or library contains more than 100,000 items, you cannot break permissions inheritance on the list itself. When a list or library contains more than 100,000 items, you cannot re-inherit permissions on the list itself. When a folder contains more than 100,000 items, you cannot break permissions inheritance on that folder itself. When a folder contains more than 1100,000 items, you cannot re-inherit permissions on that folder itself. Note: Items within the library or folder hitting the limit (say a single file or folder) won't be impacted--so you could still, for example, break inheritance on any single file inside a library with greater than 100,000 items.

Lower-level securable objects automatically inherit permissions from their parent. For example, a list or library inherits permissions from the site, and list items and documents inherit permissions from the list, library, or folder that contains them. You can break this inheritance at any point in the hierarchy and assign unique permissions. When you break the inheritance, the securable object receives a copy of the parent's permissions and then you can edit those permissions to be unique. Any changes you make to the permissions on that securable object do not affect the parent. They each now have their own set of permissions.

Plan for permission inheritance

It is easiest to manage permissions at only the site level, whenever possible. This means you should create your site hierarchy in a way that allows you to assign permissions to sites that are appropriate to all securable objects within the site, such as lists, libraries, folders within lists or libraries, documents, and items. Although you can assign unique permissions on any securable object in the site hierarchy, to do so is more cumbersome than inheriting permissions. It gets more difficult when some lists or libraries within a site have fine-grained permissions applied or when some sites have sub-sites with unique permissions and some with inherited permissions.

As much as possible, arrange sites, sub-sites, lists, and libraries so that they can inherit most permissions. Put sensitive data into separate sub-sites, lists, libraries, and so on. For example, it is much easier to manage permissions using a hierarchy like the one shown in the following example, rather than mixing sensitive and non-sensitive data in the same sites, lists, and libraries.

• Site A Group homepage
• List A Non-sensitive data (inherited permissions from Site A)
• Document Library A Non-sensitive data (inherited permissions from Site A)
• Subsite B Sensitive data (broke inherited permissions from Site A and created unique permissions)
• List B Sensitive data (unique permissions inherited from Site B)
• Document Library B Sensitive data (unique permissions inherited from Site B)</li>

Notice that the list and library in Site A contain non-sensitive data and Subsite B was created below Site A to contain a list and library for storing sensitive data. In this scenario, you can assign permissions to Site A that are appropriate to List A and Document Library A and create unique permissions on Subsite B which are appropriate for List B and Document Library B.

Further Readings

SharePoint: Using the Manage Access Option to Manage File/Folder Permissions

SharePoint: Managing Inherited Permissions

Need additional help?

For additional Training please visit the Teaching & Learning Technologies Training site. 

To submit a support request, please fill out the Microsoft 365 Support webform with as much detail as possible, or contact the ET&S Help Desk team on your local campus. For password issues you must call or visit the Help Desk in person.