Scoping Office 365 Sensitivity Labels

The Evolution of Sensitivity Labels

When Microsoft launched sensitivity labels in late 2018, the implementation was simple: you defined labels that could mark and protect Office files and email and published them to users, who then applied the labels as needed. Over time, Microsoft has increased the usefulness of sensitivity labels by building native support for labels into Office clients and by giving SharePoint Online the ability to process encrypted content. Recently, support for large-scale application of sensitivity labels to data at rest has been added to address the need to mark and/or protect the masses of documents created before sensitivity labels existed.

The Power of Container Control

In addition to the application of labels to files and email, earlier this year Microsoft established labels as a mechanism to apply policy to “containers”: SharePoint Online team sites, Microsoft 365 Groups, and Teams. When an administrator creates a new container or edits the setting of an existing container, if the label contains container settings, those settings are applied to the container.

Giving sensitivity labels the ability to manage containers is a powerful concept. Today, the settings applied to a container are limited to controlling guest access, whether the group is public or private, and managing access to files from unmanaged devices.  The most recent setting is control over the sharing capability for SharePoint sites. This setting can already be manipulated with PowerShell and now it’s being added to the GUI. Over time, it’s not hard to imagine that Microsoft will add more controls to labels to make them an even more powerful management tool.

File and Container Confusion

Good as it is to be able to exert control over containers through sensitivity labels, the fact that labels can control both files and containers creates some potential for confusion. It’s important to design a set of labels to meet the needs of the organization. The question is whether to have clear separation between labels used for document/email marking and protection and those which manage containers.

Some labels do crossover. For example, a label called “Public” might be used to mark documents for public consumption and control containers accessible to guest users which hold low-importance files. Although a case can be made for crossover labels, I’m not sure that they are a good thing. Given the way that things are developing, it seems like a better idea to separate the two types of labels into a set used for documents/email and another set for containers. Isolating the two types makes their purpose clearer and administration more straightforward and it also means that users have a limited set of labels to choose from, making it easier for them to decide which label to apply.

Such is the benefit of hindsight. Sensitivity labels have been around for a few years now and it’s possible that some tenants have evolved their labels in a less-than-planned manner, largely because they never realized that Microsoft would a) introduce container control in labels and b) expand the set of controls. They might have edited a few labels to add container control, or added some new labels explicitly for container control, or just ignored the new capability and concentrated on document governance. Focusing on documents for now isn’t a bad strategy as it buys time to wait for Microsoft to build out the management framework for sensitivity labels.


Office 365 administrative interfaces distinguish between file labels and container labels (including crossover labels) when administrators apply labels to a new container or when editing a container. Office apps do the same and only expose labels for document control to users. What’s been missing is for administrative tools to clearly show the purpose of labels by exposing their scope, or what a label controls. This can be:

  • Both documents/email and containers.
  • Only documents/email
  • Only containers.

Scoping for the management of sensitivity labels is now in preview and should reach general availability in October 2020. The changes being made highlight the different uses for sensitivity labels and provide better guidance to administrators when they create or edit labels.

The New UI

The new interface introduces scoping as part of the process to create or edit a sensitivity label. You decide if the label should apply to files and email, groups (including teams) and sites, or both (Figure 1).

Image 1 Expand
Sensitivity Label Scope
Figure 1: The new UI to separate sensitivity label control over items and containers (image credit: Tony Redmond)

Once you’ve decided on the scope of a label, the UI presents the settings available for that scope. Figure 2 shows the settings available for sites, including the ability to set the sharing capability for sites assigned the label.

Image 2 Expand
Sensitivity Label Scope Sites Control 2
Figure 2: Setting label controls for sites (image credit: Tony Redmond)

It’s important to emphasize that you do not have to edit existing labels. By default, both scopes are available to existing labels. The new UI is used as the need arises to update sensitivity labels, which is an unusual event after labels are tested and published for production use.

Time to Review Sensitivity Labels

Even though sensitivity labels don’t tend to change often, because they now support scoping, it’s wise to review the set of labels currently in use and ask if any changes should be made. Perhaps some labels should be scoped for file and email only and others for containers. In making this choice, you should ensure that users aren’t impacted by the apparent disappearance of some labels. For instance, if you scope a label for containers that people have become accustomed to use with files and email, they will notice when that label no longer appears in the drop-down list revealed by the Sensitivity button in Office apps.

If you haven’t yet embraced sensitivity labels to protect valuable content in your Office 365 tenant, you don’t have to do anything. The application of sensitivity labels to files, email, and containers is covered by Office 365 E3 licenses while any Office 365 user can access information protected by a label. Office 365 E5 licenses are needed for auto-label functionality (applying a label to files based on their content). The Unified Azure Information Protection (AIP) client is needed to apply labels to files stored outside Office 365 and you’ll need AIP licenses to cover these actions. The AIP client is only available for Windows.

More to Come

Sensitivity labels have progressed a long way in the last two years. Many of the rough edges and irritations which existed on their introduction have disappeared. This doesn’t mean that implementing labels is always smooth sailing: nothing involving encryption ever is. But the growing maturity and capability of sensitivity labels makes them a valuable tool for tenants who want to protect sensitive and confidential material against unauthorized access.