SharePoint Permissions: Best Practices for Modern Information Architecture
Permissions and security in SharePoint have always been a little tricky. This is in part because we find ourselves trying to make security fit into the organic patterns we as humans work in. But security tends to be more rigid.
In our organizational constructs we may be able to contribute in some places but not in others, yet we put all our “stuff” into big buckets and apply permissions around the structure. This has been interpreted as granular permissions in our SharePoint architecture (e.g., yes, you may edit in this library except in folders A, D, and H… oh but it is ok in subfolders A.1 and D.4). This pattern has been widely repeated on sites and subsites as well.
I can describe the user experience for this in a few words: Complicated, confusing, and frustrating.
In recent years you’ve probably heard a lot of emphasis being put on flat architecture. There are several reasons why flattening out site and library architecture is beneficial. In my opinion, the security and permission advantages are the most practical and important reasons. Before we dive into the modern world, let us cover the basic tried and true security best practices.
Let’s Talk Best Practices for SharePoint Security!
The best practice for security in SharePoint is and has always been to secure the largest object possible and to avoid granular permissions.
It makes sense because SharePoint operates on the basis of inheritance. Top-level sites push features and permissions down to the objects and content of the site by default. Lists and libraries inherit from the site, whereas folders (hopefully used very sparingly) inherit from the list/library. Meanwhile, items and files inherit from the list/library (or folders if applicable).
When I apply different permissions to a list or library, folder, or item, I am breaking the inheritance of permissions from the site. Basically, I’m poking holes in the fabric of our site permissions.
The more we poke holes in that fabric the more management that site will require. Are we creating more permissions groups? Those must be managed. When new team members are brought on, they have to be individually added to the areas where granular permissions are added.
From a support perspective, I can’t begin to tell you the number of times I have been called in to untangle the knots of broken permissions created on sites and in libraries. Users are frustrated because they can’t get to what they need and the question starts being asked, “Why is SharePoint so hard to use?”
If we step back and look at best practices, we can begin to simplify the permissions. I have a few tips that will help you along the way.
Build for Security
The inverse of this may be: Don’t build by the organizational chart.
If we build out our architecture to meet security needs, then we won’t have as much a need to introduce granular permissions.
A company’s organizational chart shows who reports to who, but it doesn’t reflect who can access, edit, consume, or own that area’s documentation. The VP of IT doesn’t need to be an owner of the IT site. They aren’t creating lists, libraries, or defining metadata. More than likely they are consuming that data.
Ask the Important Questions
Consider asking, “Who needs access to this? What type of access?” When the request for granular permissions comes up—and it will—verify:
- Is this a security need or a security want?
- If it’s a need, is it truly a breach of security if everyone with access to the site can access this content with their default site permissions?
Most of the time, all those libraries or folders that we broke permissions for should have been libraries on their own site. It’s not uncommon to have a subset of folders with the same permissions and lists have granular permissions that match the folders, all with the purpose of giving a particular audience on the site secured access to the content of these lists and libraries. Why not just put it all on a site with the permissions set up correctly? You can even use links to help the business users move between the sites.
This eliminates the risk of the wrong people accidentally finding stuff on a site that they shouldn’t. It also reduces the management overhead of permissions. Notice how we just described flat architecture!
Those are the basics and apply to classic as well as modern SharePoint. Now, let’s talk more specifically about security in modern SharePoint Online. There are similarities and differences.
SharePoint Security & Permissions for Modern Architecture
First, as a quick reminder: SharePoint is still SharePoint. But it has evolved a bit. As I mentioned earlier, the focus is on creating a flat information architecture (IA). No more subsites, no more deeply nested folders (please, stop the nesting; it’s for your benefit!).
Modern SharePoint sites still have our trusty site owners, site members, and site visitors.
We build information architecture to be modular. One big reason for the deemphasis of subsites is because there’s more to the intranet than SharePoint. We have Microsoft Teams, Planner, and Stream, just to name a few. Microsoft has focused on these features and functionality at top-level sites. thankfully, we don’t have to manage the permissions for all these applications one by one. Microsoft 365 Groups acts as a security service to allow the management of permissions across the Microsoft 365 toolsets.
Once we adopt this methodology into our IA, managing permissions gets much easier. We use communication sites for hosting content that everyone in the organization should have access to and team sites for department, business unit, or project collaborative content that is secured to specific groups of people. Personally, I like to start with Microsoft Teams for the collaboration areas. When I create a team, I’m also getting a SharePoint team site, Planner plan, group inbox in Outlook, and OneNote notebook. As I add people to the team, I’m really adding them to the Microsoft 365 Group that’s tied to all the other associated apps. Centralized permissions management!
Communication sites don’t get Microsoft 365 Groups. They stay lightweight since the heavy lifting of collaboration happens on our team sites.
As you start building, if you feel that the architecture is getting too wide and you need that old, classic association that subsites and top-level sites had, look at hub sites to meet that need. This webinar discusses how hub sites allow us to join related sites together for consistent navigation, focused search, and content rollups. Since that webinar was recorded Microsoft has rolled out a Hub Visitors group, allowing us to create a group with read access to the sites in a hub.
Let’s review:
- The best practice is to secure the largest object possible.
- Modern SharePoint architecture is flat.
- Flat IA allows our SharePoint sites to leverage all the features and functionality Microsoft 365 has to offer.
- No more tangled knots of broken permissions between sites/subsites or sites/libraries/folders
It is absolutely different but as I said before, it’s still SharePoint. Take time to plan engage your business users to find out how they work and with whom, and use that information to create an information architecture that enables them to work without the headaches of broken permissions. Modern IA provides the security and the flexibility we need to enhance business processes and streamline collaboration.
SharePoint permissions are more of an art than a science, but there are best practices that can help you streamline management. Download our free eBook, Ultimate Guide to SharePoint Permissions, get tips and tools on how to best use permissions to secure your collaboration.
