Keep your information architecture secure with permissions
You already know that security matters. You already know (we hope!) that the Microsoft 365 suite comes with the ability to set permissions in a number of different ways. But it’s much harder to be sure that your permissions settings are actually doing what you think they are – and the larger your organization is, the greater the risk.
That’s why permissions are a crucial part of your organization’s information architecture.
What are permissions?
At their most basic levels, permissions in Microsoft 365 platforms like SharePoint and Teams are settings that control:
- What you can see
- What actions you can take
In M365, it’s possible to assign permissions on a role or user level. Here are some examples of permissions at different levels:
- Permissions at a role level. Your manager adds you and all your customer service team coworkers to the SharePoint group ‘Customer Service Site Members’, which is part of the Customer Service site. SharePoint is set up to grant everyone in that group the role of Editor. You and your coworkers can view the customer service SharePoint site and edit the files.
- Permissions at a user level. Your coworker sends a link to a Word document in SharePoint with you. You can’t access it, so she adds your email address to the list of users who can edit the document.
Side note: permissions are part of what defines an intranet! What makes an intranet an intranet, besides the content it contains, is that it’s open to an entire organization – to all internal users. All the information in it is accessible to all employees. An example of an intranet could be an education platform or a central location for training documents, employee handbooks, benefits information, etc.
Why should I care?
Do you care about security and compliance? Inconsistent or improperly configured permissions leave your business open to security vulnerabilities and compliance violations.
What about speed? Not having permissions policies can lead to lots of user- and folder-level permissions assignments – which in turn leads to sites and libraries that load impossibly slowly or refuse to sync.
And how about efficiency? Automating permissions can save a lot of time and brain power, freeing your teams up to focus on their jobs instead of emailing IT for help for the 40th time.
Permissions best practices
To keep your SharePoint or Teams sites’ permissions from becoming hopelessly snarled — or to claw back some order from the chaos — these permissions best practices are good places to start.
Think about permissions at the beginning of anything you build
Permissions shape the structure of any SharePoint site or Teams channel. Consider permissions when designing the architecture of anything new — permissions should never be an afterthought. You might also want to read about scoping to help you make decisions at the beginning of a new project.
Always assign permissions by group, not by user
Yes, even if a group only contains one user! This builds a structure for onboarding and offboarding. If that single user leaves, or if their role expands to multiple employees, it’s easier and more consistent to add a new person in that job role to the same groups than to reassign all the permissions to the user by hand. When looking at list of users in the admin console, you should be able to tell everything that person has access to by what groups they are a member of.
Avoid excessive granularity
Microsoft lets you assign permissions at the file and folder level, but that doesn’t mean doing so is a good idea. Lots of permissions assignments on individual files and folders will make your SharePoint sites sluggish, and create a nightmare if you need to grant or revoke permissions in bulk or make other big permissions changes.
Create clear and organized naming conventions for your security groups
This is especially important for SharePoint. We suggest tying your naming conventions to an app or a feature by creating a prefix. For example, we label SharePoint Online permission groups with the prefix SPO, as in “spo-salespeople”. Exchange Online security groups can start with EXO, like “exo-csuite”.
Mind the differences between Teams and SharePoint
When setting permissions in SharePoint and Teams, you’ll want to pay attention to the details.
- Teams has no read-only access. This means you can’t set a “visitor” role in Teams, just in SharePoint.
- SharePoint permissions can be much more granular. Teams can have owners, members, and guests, and their permissions are much more rigidly set than in SharePoint. In SharePoint, you can set extremely specific permissions for each role, down to whether users can delete files they didn’t create.
Microsoft 365 experts for permissions strategies and automation
Well-crafted permissions are crucial for security, compliance, the speed of your SharePoint sites, and the efficiency of your organization. If you’re feeling overwhelmed by the possibilities, facing a site with a snarl of individually assigned permissions, or need help establishing permissions-based automations for your organization, give Wellington Street Consulting a call. We’ll make it simple.
