SharePoint Site Permissions and Security 101

SharePoint security uses the inheritance model. This model establishes access at the site level, then passes that access on down to all content inside the site (lists and libraries and the items within).

Compare it to a building where anyone can walk into the lobby. From there, you may or may not be able to go into higher floors or offices/rooms within offices/locked cabinets. 

The company owner or CEO can go anywhere/see anything in the building. His role is seamless- he never encounters a denial of access regardless of where he is in the building. 

A manager can replicate that behavior, but only so far- his role prevents him from entering certain parts of the building or seeing certain materials. The manager’s access is also seamless- up to the point at which his role prohibits him from going any higher. When he meets a locked door, he understands why- it’s part of the job.

General members of the public have the most limited role- beyond the lobby, they can’t do much. They may be able to observe or temporarily visit other parts of the building, but that access is carefully monitored.

Someone has planned all this ahead of time and put controls in place that enable these access roles. How would the building ensure its security if no planning had taken place?

This analogy carries over into the concept of a SharePoint site. Using roles in this manner provides a seamless, streamlined experience for users and ensures that they only have access to content relevant to their role within the site. It ensures the security of the information within the site. It requires (and assumes) thoughtful preparation by those managing the site. 


    • If your site’s purpose is not well-defined, you will likely struggle with this user role definition process.
    • It is therefore very important to understand what your site’s purpose is going to be (Why does the site exist? What processes does it support? Who are its particpants?) If you cannot articulate the purpose of your site and what its function is in the context of your business, you need to step back. Launching into site creation without a clear vision will get you into trouble.
  • During the site creation process, establish default user roles that align with these reasons and processes. Who are the executives? Who are the worker bees? Who are the observers? Identifying these roles will help you configure default SharePoint permissions.


I find many people immediately enter into a decision to use SharePoint with the attitude, “OK- now how can I hide this content?” To operate from this standpoint almost always ensures failure. You must take the opposite approach and plan for what will be accessible to the broader audience before you worry about what will NOT be accessible. Focus on the SHARED part of your site’s purpose, then from there you determine what pieces of the default permissions need to be removed or altered to produce the desired level of restriction. Go from the general to the specific.

SharePoint is a collaboration platform; therefore it WANTS you to build for sharing. (It’s called SharePoint, not HidePoint.) Everything about SharePoint native behavior is aligned toward an assumption that the reason sites exist is to connect people to content. The more you take advantage of this natural behavior the better your site will function. This can be a difficult concept to grasp but it must be internalized.


SharePoint groups allow site owners to manage permissions as a whole for all users who share the same role. It’s about the rule, not the exception. Don’t focus on one-offs or “sometimes” situations. Why open yourself up for an administrative burden?

Consider everyone who participates in your team/departmental processes & functions. People can be put into “buckets” (assigned common roles) according to what they do and how they do it. Since the data and documents you put on your site are related to these processes and functions, it makes perfect sense to orient your permission groups around these roles.

  • Once roles are defined, we can place people into SharePoint groups corresponding to these roles.
  • Assuming you have planned and organized your site’s content to follow default permission inheritance, all relevant content is automatically accessible to users whose job function aligns with your site roles.
  • When employees come on board or transfer, all you need to do is place them into the correct SharePoint group to allow them the site access they need to do their job.
  • Consider these scenarios:
    • New hire
      • When a new person is hired, match them to an existing role (“Admin Assistant”) within your department/team.
      • Add them to the site’s SharePoint group containing the other people already sharing that role (all the other Admin Assistants are in the Site Members group- so that’s where I will place the new hire).
      • The new hire automatically has the same access to content as all the other Admin Assistants.
    • Promotion
      • If the promotion changes the person’s role (Admin Assistant is now a manager), all you need to do is remove user from his/her current SharePoint group (Site Members) and add him/her the group corresponding to the persons who have the role to which the user was newly promoted (all the other managers are in the Site Owners group- so that’s where I put him).
      • The promoted person can now automatically access all the content available to person in the Manager role.
    • “Just like John”
      • You just want to make sure that a certain user has the same access across the site as another person (Jane needs to have the same access as John- how to we accomplish that?).
      • Find “John’s” SharePoint group and add the new user to that same group. It’s automatic.
    • When this model is NOT followed, it can be practically impossible to replicate access profiles or ensure consistency across your site.


A final caveat regarding user roles in the SharePoint context…  SharePoint best practice is to grant permission by the principle of least privilege. This means a user should have permissions to do what they need to do, and no more. By extension, people should have only the permissions to do what they understand, and no more. Do not set users up for failure by allowing them permissions beyond their current scope of comprehension.

No one should be offended if their permissions are “lower” than someone else’s. We have seen too many instances where users with too-high permissions inadvertently ruined all/part their site by trying to “fix” something they never should have been able to access in the first place. In fact, this is the #1 cause of support requests at my company. Don’t give the keys to unlicensed drivers. Don’t bow to the pressure of “Just grant me full control so I can get to that one file…” Good luck closing that barn door.

In almost every case, it is much more effective to manage access for groups of users than to try to control access for each individual person. Learning this lesson is very important. Lack of preparation with regard to permissions is the #1 reason behind most site problems and can result in significant administrative burden over the life of your site if not adequately planned and monitored.


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s