Creating a sensitivity label for Groups and Sites is a relatively new feature within Microsoft 365 compliance. This feature allows sensitivity control to be applied to features in M365 that are backed by a Microsoft 365 Group (Teams and SharePoint sites) and SharePoint Online and OneDrive for Business. Currently, the feature is not enabled by default. It needs to be enabled. Check out “Enable Sensitivity Labels in Microsoft 365 Groups and SharePoint Sites“. In this post, I’ll cover the steps for applying a sensitivity label to a site itself.
Sensitivity Labels for Groups and Sites
It is now possible to create a sensitivity label that does more than protect the documents within your SharePoint, OneDrive, Teams, and Exchange. A sensitivity label in Microsoft 365 can now provide reporting and protection of the SharePoint Site or group itself. This is also known as container-level information protection.
Note: This option is not available to classic sites.
With a site/group sensitivity label, you can:
- Control the accessibility of a Team and group
- A public Team that has a private sensitivity label applied to it will end up becoming private because the label overrides the configuration.
- Control External Access
- If a site, group, or Team is open to external access, a sensitivity label can also override that configuration.
- SharePoint site external sharing
- While external users can be granted access to a site by manually adding them through an administrative process, users can still share content with external users. A site sensitivity label can control this.
- Control access to content for users on unmanaged devices
- You can control users’ access to your Microsoft 365 features via a conditional access policy, but that requires much higher administrative access than a site owner will likely have. However, with a sensitivity label, you can control access to your site’s/group’s content by configuring it to block or limit access from unmanaged devices
- Control authentication context
- Allows for additional control of content at the app level. Adding authentication context controls enforces an extra layer of protection by using additional security checks where required (like accessing a site or group).
- Authentication context control is still in preview
Note: While unmanaged device and authentication context processes don’t require an administrator to create a conditional access policy, the label itself works with conditional access to provide the controls.
Group and Site Sensitivity Disabled by Default
By default, the site and group sensitivity labels are disabled. The easiest way to determine if it is enabled in your environment is by navigating to https://compliance.microsoft.com/informationprotection. If the site and group sensitivity is disabled, you will have a message letting you know the feature is now available:
I have created a post to provide you with step-by-step instructions on enabling sensitivity controls for your groups and sites. You can access the post here.
Creating a Sensitivity Label for Groups and Sites
Now that the group and site sensitivity labels are enabled. Let’s create one. I have a file/email sensitivity label within my organization that sets the content as internal only. It doesn’t encrypt, but it does provide watermarks and footers so that users are aware they are working with internal data and act accordingly. Additionally, that can be used to assist with DLP policies (but we’ll cover that another day). In this post, I’ll create a similar sensitivity label for groups and sites. The label will have the following configurations:
- Ensure the Team or group is private
- Disable external sharing (it’s internal only after all)
I won’t worry about controlling the authentication context or unmanaged devices at this level. I would suggest you consider that for your more sensitive data.
- Login to the information protection section of the Compliance Console (https://compliance.microsoft.com/informationprotection)
- Click on “+ Create label”
- Provide the sensitivity label with a unique internal name (“Internal Use Only Site”), a display name (“Internal Use Only”), and a meaningful description.
Note: The internal name must be unique, but the display name will not have to be. If you have two Internal Use Only labels, that is ok because the users will only see the one based on where it is being applied (file/email label in Exchange, Word, or site/group label for a SharePoint site)
- Click Next.
- Remove the checkmark for “Files & emails”, but enable (or leave enabled) “Groups & sites”
- Click Next through to the Groups & sites configuration page. Note that the options are greyed out on the Files & emails page because we did not enable that option previously.
- Ensure the options “Privacy and external user access settings” and “External sharing and Conditional Access settings” are both enabled. We will configure options to ensure the site and content are not shared externally.
- Next, set the site’s privacy to the option required (I chose private in this example).
- Public – Anyone can find and access the team.
- Private – Access must be granted by an owner or administrator
- None – This option allows the members of the team to set the privacy settings
- Ensure “Let Microsoft 365 Group owners add people outside your organization to the group as guests.” is NOT checked as we don’t want the Group or Team to be shared externally.
- Place a checkmark in “Control external sharing from labeled SharePoint sites” to enable the sharing options for the sensitivity label.
- Select the option “Only people in your organization” because this ensures that the user has to have an account to access the site; thus, no external access is allowed.
- You can enable or disable “Use Azure AD Conditional Access to protect labeled SharePoint sites” as necessary. This option controls how users can connect if they access the resource with a device that your organization doesn’t manage. For example, you may wish to block any editing or downloading of content if an employee logs in with their PC. This option doesn’t block internal users from accessing the data, but it does block them from editing the content if not on an assigned device.
- Once complete, click on Next until at the summary page.
- Review the settings and click “Create label”.
- Once the label is created, move the label to the desired location in the list.
Note: you may be wondering why the order for site sensitivity is important. I’ll cover that in another post, but trust me; it is as important as your file and email sensitivity labels.
Once the label is created, you can publish it to users who should be setting the sensitivity on sites, groups, and Teams.
Thanks for reading!
Comments
This is a great post that provides the relevant information. Thanks Dave. Is there a post about how the sensitivity labels differ between information protection and information governance? Also, if I retrieve content via MS Graph API or SharePoint REST using SPFx, are there any considerations to account for if a list item has sensitivity applied? Also, can a list item without a file (generic list) have this label applied?
Thanks
Hello,
I believe you are mixing up a bit with retention labels here. Sensitivity labels are created within the information protection page. Retention labels, used for ensuring content is maintained for as long as required, are created in the information governance (and record management) pages. Additionally, your second question appears to be asking if you can assign sensitivity to a list item (not a file in a document library). This is not possible with sensitivity labels. Sensitivity labels are applied to files, not rows in a list. The exception is Azure Purview which has the ability to protect database data, but SharePoint lists are not included in the supported data.
Hope this helps.
Ah I see, thanks for the clarification on the part about sensitivity label not being applicable to list items. I never thought of it that way. It’s an overall great read, thank you for sharing.