How to Handle an Unwanted Sensitivity Label

Don’t Delete a Sensitivity Label Unless You Absolutely Must

An organization found that it had defined four sensitivity labels to protect information when they only needed three. The question is then what to do with the unwanted label?

The most important step is not to do anything rash like rushing to delete the label. Office documents and PDFs might be protected using rights-management-based encryption applied by the label. Deleting the label from a tenant will have consequences such as users losing access to information when an app attempts to validate their right to open a file.

Remove Unwanted Labels from Publishing Policies

Sensitivity labels become available to users through label publishing policies. A label can be included into multiple label publishing policies, each of which is targeted at different sets of users or groups. Apps check these policies periodically to know what labels they can present to users through their UI. It doesn’t matter which policy a label is published through because this is just a mechanism to make the labels available. What’s more important is the application of labels to files and messages, and stopping further objects from receiving the unwanted label is what we should concentrate on first.

To do this, check each label publishing policy to find which policies include the label. Then update the policies to remove the label. Six hours or after the publication of the updated policies, apps will drop the label from the set presented to users.

The sensitivity label is still active insofar as the usage rights defined in its settings remain active for the files assigned the label. It’s important to remember that the usage rights defined in a label at the time it is assigned to a file govern the access people have to that file. To ensure protection no matter where a file goes, the usage rights are part of the file metadata. If you change the usage rights for a label afterward, the new rights apply only to files assigned the label following the update. You can’t therefore do something like remove encryption and the usage rights from a label and expect this update to percolate and apply to all files where the label is present.

The way usage rights work is important for tenants who use Copilot for Microsoft. If a sensitivity label contains rights that allow VIEW and EXTRACT access to ‘anyone in the organization’ or ‘all authenticated users,’ those rights allow Copilot to search and use the protected content in its responses. Updating the label to remove the ‘allow all’ access usage rights means that newly protected content is unavailable to Copilot, but older content remains available.

Find the Locations of Labeled Content

Depending on how long the unwanted sensitivity label has been available to users, it might be stamped on thousands of files or just a few. To discover where labeled files exist, you can use SharePoint Search or a content search. A full description of how to do this is in this article. In summary, you must find the identifier (GUID) for the unwanted label and use it to search.

To find the identifier (called the ImmutableId), run these PowerShell commands to connect to Exchange Online, then the compliance endpoint, and finally fetch label information:

Connect-ExchangeOnline
Connect-IPPSSession
Get-Label | Format-Table ImmutableId, DisplayName

ImmutableId                          DisplayName
-----------                          -----------
2fe7f66d-096a-469e-835f-595532b63560 Public
8b652c9a-a8b7-40ec-bb1a-c5334b1b7fef No Encryption
a49e1277-93db-4a2f-8105-43c5196b4fef Non-business use
fb0975b2-1ea1-4c3c-850c-e859e690d282 Partner-Accessible Content
e42fd42e-7240-4df0-9d8f-d14658bcf7ce General Access
27451a5b-5823-4853-bcd4-2204d03ab477 Internal

Remember that SharePoint Search automatically applies security trimming, so the only files it displays are those that the signed-in user can access. Nevertheless, this is a good first indication of label usage. A content search using the same keyword criteria will find labeled files in all sites and report them in its search statistics (Figure 2). Even better, you can download a CSV file with the top locations report containing details of the top 1,000 locations where labeled files exist.

Because it’s based on an estimate search, the top locations report might not find every single file with a specific label. To be sure of finding everything, you need to perform an export search. This will take longer than the estimate search, but the export report (a CSV file) is more accurate, and the report includes details of the individual files with the labels rather than just a count of labeled files per location. You don’t need to export all the files, just the export report.

Deciding What to Do with Labeled Files

At this point, you know how many files exist with the unwanted sensitivity label and where they are. The next decision is what to do with the files. You could simply leave the files alone and wait for the natural lifecycle of documents to reduce the number of files in use. Retention policies that remove files after a certain period can accelerate this process, but it’s also true that user-applied retention labels can keep files around for longer than anticipated.

My preference is to do nothing. Because the usage rights are in document metadata, apps will continue to consume the metadata and ensure that only those granted usage rights access the protected content. However, if the organization decides that it is better to replace the label with another sensitivity label, this will need manual intervention. Two methods are available:

• End users can replace the label for the documents they own. It’s possible to create a list of target documents for a user to process from the data in the export report or by running a script to generate a report of files in document libraries.
• SharePoint administrators to change the label of any document using the Unlock-SPOSensitivityLabelEncryptedFile cmdlet.

A Graph API is available to apply sensitivity labels to files. However, the API is metered and requires approval from Microsoft, so it’s not appropriate in this case. Auto-label policies can’t help either because they cannot apply labels to files where an existing label is in place. This prohibition is absolute when a user applies a label to a file. An auto-label policy can replace a label that was previously assigned by an auto-label policy provided the new label has a higher priority, which might not be the case.

The technique outlined in this Microsoft Technical Community article is outdated and doesn’t work due to a change in the location where Office documents store sensitivity label metadata. Unfortunately, it’s a reminder that not everything you read on the internet will work, including information found on a Microsoft website (or even this one).

Email with Unwanted Sensitivity Labels

Unwanted sensitivity labels can also protect email. In this situation, a strong case exists for removing the label from active use and leaving time to take care of the problem. Emails tend to be less persistent objects than documents are. It’s also not possible to change the sensitivity label assigned to a sent message. On the upside, organizations often have more aggressive retention policies to remove email from user mailboxes, so the issue will dissipate over time.

Fools Rush In Where Intelligent Administrators Pause to Think

To emphasize the point made earlier, there’s great value in removing unwanted labels from publishing policies and leaving them in place while you gather information to make an informed decision about what to do next. Coordinating the relabeling of thousands of documents will require considerable effort for both document owners and administrators. Avoiding that work and letting retention policies take care of the problem seems like a good idea to me.