For the uninformed, SharePoint’s massively configurable permission schema can be overwhelming. If you have recently taken on the responsibility of administrating your team’s SharePoint site and know very little about SharePoint permissions then this post is for you. SharePoint security is endlessly customizable and the user interface stinks, but with a little patience you can take control of your information.
Step 1: Choose a mantra – Security policies are set up to accomplish two goals: giving the right users access to information they need access to and stopping the wrong users from seeing information they should not see. Depending on the nature of your industry, company, or project you will probably find yourself leaning towards one of these goals. Do you want a site where only a few select people can view and edit documents? Do you want a site where many people will be able to stumble across and learn about what your team is doing? Your real mix will always be somewhere in between, but come to a general mantra on whether your information will be accessed on a need to know basis, or whether your information will be protected on an as needed basis. Is the general idea to restrict only when needed or to allow access only when needed? Write down your information security mantra and hold it up and use it to make decisions throughout the rest of this process.
(if your security and auditability is is of great concern read more: https://www.easydynamics.com/blog/secure-messaging-storage-audit-trail)
Some example information security mantras:
- Information should be open and findable unless specifically marked otherwise
- Access should be granted on a need to know basis
- We have an open side and a closed side of our information portal
Publish your security mantra, possibly on the home page of your portal. People who visit your site should understand the general security goals on information access and your mantra will be the supporting document behind all access policy decisions going forward.
Now that you have a basis to make information security decisions, it is time to start defining your user access groups.
Step 2: Define your groups – Group your users into pools of people that share permission levels. Remember that SharePoint groups are used primarily for security and the group/s a person is in should be a function of security and information access needs of that individual. This is slightly different than grouping users by project or job role. The overarching aim is to create as few groups as possible to achieve your access goals. Groups can be made up of Active Directory users or Active Directory user groups but SharePoint groups themselves cannot be nested. This means that your list of SharePoint groups will be a flat list that can be easily visualized and managed. This will come in handy on step 3 (spoiler).
If you do not existing knowledge of SharePoint groups or common permission levels users need, then this is a good time to stop and read a short article from Microsoft summarizing SharePoint groups.
Now that you understand how SharePoint groups work, it is time to create your own. Take an Excel sheet and make a list of each security group that you will need. In the second column write down a conceptual description of what each group will have access to.
- Visitors – These users will have read access to everything aside from the Team Document library but will not be able to make edits.
- Normal Contributors – These users will be able to read or write to most of the documents on my site. They will not be able to delete documents.
- Editors – These users will be able to edit any document in any way and they will be able to approve major versions of documents and delete documents.
- Project Editors – These users will be able to read all documents on the site but only able to edit documents associated with one specific project.
- Admins – These uses will be able to design the format of my site assign site permissions.
Now that you have your security mantra and a list of your user groups and general guidance on what kinds of access they will need, it is time to start building out your permissions matrix.
Part II coming soon…
- Step 3: Create a permissions matrix
- Step 4: Setup permissions
- Step 5: Test and apologize