We’ve had Sensitivity Labels in Microsoft 365 for years and we’ve had the concept of Data Classification around even longer. Traditionally, we think of applying Sensitivity Labels to content we work with every day like emails and documents. It both protects those items as well as to inform their recipients of their sensitivity and the care with which they should be handled.
However, we’ve also been able to apply Sensitivity Labels to collaboration spaces such as Microsoft Teams and SharePoint Sites, and more recently as a default to SharePoint Document Libraries to protect those spaces by automatically enforcing data protection policies.
Although labels for Teams and Sites have been around for a couple of years, and labels on libraries have been around for a few months, many organizations are still discovering that this is an option. They’re still learning about how Sensitivity Labels on Teams, Sites and Libraries are different from those on documents and emails and how they can help automatically enforce policies. Let’s look into how we can better protect our content spaces in Microsoft 365 with Microsoft Purview Sensitivity Labels.
The benefits of applying Sensitivity Labels to our Collaboration spaces is that it enables data protection policies to be automatically enforced on those spaces, and it informs users that are collaborating within them of what the highest level of information sensitivity they should be storing there. The Data Protection policies that get enforced are different depending on the collaboration space we’re working with.
Sensitivity Labels for Microsoft Teams
Before Sensitivity Labels for Teams were introduced, we could enable or disable external guest access for all Teams. With Sensitivity Labels, we can now enable users to share with external guests only within specific Teams where the organization has determined its permitted. As well, we can automatically enforce data protection policies on those Teams so that sharing information has the appropriate controls in place.
For Microsoft Teams specifically, when a Sensitivity Label is applied there are 2 policies that can be enforced depending on the configuration of the label:
- Is the Team required to be Public, Private or can the creator choose
- Are Team Owners permitted to add external guests to the team
In my environment I’ve created 3 labels: General, Confidential and Restricted. General requires a team to be public whereas Confidential or Restricted requires a Team to be private. Here is what the user experience looks like for the users that will create a Team once this has been configured. You can see in the labels description what the enforced privacy setting is.
As well, when you select a label, only the permitted privacy setting is available with all others being disabled.
Once your team is created, we can see the Sensitivity of it in the top right hand corner, which informs users of its sensitivity. This can relate to many things, but for many organization it represents the highest level of sensitive information that may be stored in this Team. For example, in my case I could store General and Confidential information in this team, but I would not be permitted to store Restricted information. This helps to direct users on where to store different levels of sensitive information, so that the right data protection policies are enforced depending on the organization’s requirements.
REMEMBER: applying a sensitivity label to a Team does not change the sensitivity of the files stored within the team. It only enforces the policies discussed above.
IMPORTANT NOTES:
- When you configure your labels for Collaboration Spaces, you need to publish them to the users that will be creating a Team or Site for them to have those as options.
- A private channel in a Team will inherit the label from its parent Team. An owner can navigate to the SharePoint site underlying that private channel and change the label, but the label change will not be reflected in the Team.
- A shared channel will inherit the label from its parent Team, and the label cannot be changed on the shared channel.
Sensitivity Labels for SharePoint Sites
Similarly with SharePoint sites, we can automatically enforce data protection policies based on the Sensitivity Label that’s selected when a site is created or modified. And since a SharePoint site underlies a Team, these policies are also enforced on the file repository for an associated Team.
For SharePoint sites specifically, when a Sensitivity Label is applied there are 3 policies that can be enforced depending on the configuration of the label:
- What type of external sharing is enabled – you must select one of the following options:
- Anyone Links (anonymous guest access – no authentication is required)
- New and Existing Guests (I usually recommend this option because owners can add new guests and they are required to authenticate)
- Existing Guests (you need a separate process end an owner wants to add a new guest)
- Only people in your organization (no external sharing is allowed)
- What is the experience for users that are using Unmanaged Devices – Unmanaged Devices are those which are not Hybrid Azure AD Joined, or are not Intune Managed. There are 3 options for the Unmanaged Device policy:
- Allow full access to the site from an unmanaged device – this is usually reserved for very public sites, with only publicly available information
- Block all access to the site from an unmanaged device – this is configured for sites with our most sensitive information
- Allow web-only access – this allows a user to access a site from the web browser only, view or edit information in online versions of Word, Excel and PowerPoint only, and it prevents any downloading of information to the unmanaged device.
- Alternatively to the Unmanaged Device policy, you can also connect the label to an Authentication Context instead to enforce granular Azure AD Conditional Access policies when a user tries to access specific SharePoint sites.
Again, the benefit here is that you don’t have to take a “big hammer” approach, and either enable or disable external sharing or enforce an unmanaged devices policy for all sites. You can enforce specific policies on specific sites depending on the sensitivity of the information stored within.
REMEMBER: applying a sensitivity label to a Site does not change the sensitivity of the files stored within it. It only enforces the policies discussed above.
When a sensitivity label is applied to site, it appears within the site here:
Global External Sharing Settings vs Label Settings
Its important to note that for the external sharing settings of a Sensitivity Label to be enforced on a site, the global setting for External Sharing must be at least as permissive or more than the label’s setting. For example, if a label’s setting is to allow ‘New and Existing Guests’ and that is applied to a site but the Global Setting is configured as allow ‘Only people in your organization’ then the ‘New and Existing Guests’ setting will not be applied external sharing will still be disabled on the site. So, if we wish to use Sensitivity Labels on sites to permit different types of external sharing, then our global setting in the M365 Admin Center or the SharePoint Admin Center must opened up and set to New and Existing Guests.
The following is a set of scenarios to illustrate this point:
Leverage the Authentication Context to Enforce Granular Policies
The option to select an Authentication Context is really interesting because it allows us to get very granular with the Azure AD Conditional Access policies that can be enforced on a particular site. For steps on how to configure an Azure AD Authentication Context and Conditional Access Policies see my blog here Govern and Secure SharePoint and OneDrive with Microsoft Syntex – SharePoint Advanced Management, and specifically check out step 3. Conditional Access Policies for SharePoint and OneDrive.
This can be really useful to enable use cases like:
- Require external guests to have to accept a Terms of Use policy and MFA every time they access a particular set of externally shared sites. Internal users would be subject to different conditional access policies.
- Require internal users to have to utilize a FIDO2 key with a fingerprint reader (or other strict authentication protocol) whenever they access highly sensitive sites. Other sites that are not as sensitive would not require such a strong security measure.
- Require that users accessing certain highly classified sites be within a particular countries borders or trusted location. If they are outside of that countries borders or a trusted location, they may not access those sites.
Sensitivity Labels for Document Libraries
We are able to also configure a default Sensitivity Label for a Document Library in SharePoint. This label represents one method in which we can automatically classify files for sensitivity because the label is automatically be applied to files when they are uploaded or edited within the library.
It has sometimes been referred to as “Location Based Sensitivity Labels” because the label applied depends on the location in which a user stores a file.
As we build out our SharePoint sites, we’ll often have libraries that represents certain types of documents or content types, like contracts, employee personnel files, agreements, project plans, brochures, financial statements, invoices, etc. Since we often recommend keeping the number of sensitivity labels small, to something between 3 and 5, it follows that may of these content types are often classified the same way – for example, most contracts are often classified as Confidential, and most or all employee personnel files are often classified as Private, etc.
So we can see how using a default Sensitivity Label on a library that is designed for storing particular types of content can be an easy way to ensure that these documents are classified and classified with the right sensitivity label.
This feature represents a real simplification in how Sensitivity Labels can be automatically applied. As well, as you design your Information Architecture for SharePoint Online, you are encouraged to also include a recommended or default Sensitivity Label for particular libraries that are designed to store sensitive documents.
There are some IMPORTANT NOTES to keep in mind when considering using a default Sensitivity Label on a Document Library:
- A label is applied when a document is uploaded to a library, or when it is created/edited within a library. It is not applied to documents already stored at rest within a library when the label is configured.
- A default label on the library will only override an existing label on a file if the label was not manually applied by a user (under any circumstances) or if the label was automatically applied and is a lower priority than the default label.
- The default label currently only applies to Microsoft Office Files (Word, Excel, PowerPoint). It does not yet apply to PDF files.
- A Syntex- SharePoint Advanced Management or Microsoft 365 E5 license (or equivalent) is required to utilize this feature.
Additional notes are included in the blog that is referenced below, in Prepare for Sensitivity Labels for Document Libraries.
Prepare for Sensitivity Labels on SharePoint Document Libraries
To prepare for and configure Sensitivity Labels for SharePoint document libraries, there are some initial configuration steps that must be taken. Please refer to my blog here on what those steps are and how to implement them: Prepare for Sensitivity Labels on SharePoint Document Libraries.
Prepare for Sensitivity Labels in Microsoft Teams and SharePoint Sites
To prepare for and configure Sensitivity Labels for Microsoft Teams and SharePoint Sites, there are some initial configuration steps that must be taken here as well. Please also refer to my blog here on what those steps are and how to implement them: Prepare for Sensitivity Labels in Microsoft Teams and SharePoint Sites.
