Making Sensitivity Label Management Easier with Updated Purview Features
In this blog:
Why sensitivity labels in M365 are easy to apply but hard to do
The two new Microsoft Purview features and how they work
What risks and guardrails to consider before enabling these features
Sensitivity labels are often introduced with the best of intentions: protect information, reduce risk, and apply consistent controls across Microsoft 365. But over time, environments change, or business priorities change and label schemas need refining.
In this situation, organizations find themselves stuck with labels that are difficult to undo or change at scale.
Recently, Microsoft introduced two features in Microsoft Purview to address this exact problem. They can be incredibly powerful — and potentially problematic — if misunderstood.
This post highlights what they are, why they matter, and what to watch out for before enabling them.
The problem: labels are easy to apply, and hard to redesign
Why would an organization want to redesign or clean up their tenant's sensitivity labels? Common scenarios include:
Labels applied too aggressively, resulting in high false positives
Manual labels were applied that can’t now be overridden by updated policies
Mergers, tenant consolidations, or reorganizations that require reclassification at scale
Label schemas that evolved, but content never caught up
Until recently, administrators had limited options to safely unwind or correct these situations without relying on users or risky scripting approaches.
New feature #1: Bulk “remove labels”
Microsoft recently introduced the ability to bulk remove sensitivity labels as part of auto‑labeling policy configuration. This capability is intended as a safety‑net operation for scenarios such as:
Recovering from policy misconfiguration or corruption
Reverting widespread false positives
Preparing content ahead of mergers or tenant consolidations
Resetting content to enable a cleaner re‑classification
In short, it allows organizations to wipe labels at scale so they can start fresh, which wasn’t easily feasible before without significant effort and risk.
This is powerful, but it also means you can undo months (or years) of classification work in one policy if you’re not careful!
Be careful with the remove labels policy!
New feature #2: Override Existing (even manual!) labels
The second feature addresses another long‑standing rule in Microsoft Purview: the inability for automatic policies to override manually applied labels. Now, with the recent updates in Purview auto-labelling policies, administrators can configure policies that automatically replace existing labels, even if they were applied manually.
This is especially useful when:
Label schemas are updated or renamed
Updates are needed to the user-applied labels
Shareability or protection requirements change
Legacy or outdated labels need correction without user intervention
From an operational standpoint, this finally gives admins real control over label lifecycle management. Similar to the remove label feature though, this can have unintended consequence if misapplied.
Please note that this feature observes the priority sequence; labels are replaced only when the existing label has a lower priority.
Where to find these settings
Both features live in the Microsoft Purview portal, within Auto‑labeling policies.
Remove labels is presented as an option early in policy configuration:
Overriding existing labels appears under Additional label settings:
The placement is subtle, and it’s easy to miss how impactful these options are if you’re moving quickly through the wizard.
Workflow Deep Dive
Let’s look at the conceptual workflows for using these features in Microsoft Purview. The intent here is not to provide a click-by-click guide, but to explain how the feature behaves, what decisions administrators are making at each stage, and where risk is introduced.
Removing Sensitivity Labels at Scale
At a high level, label removal is implemented through a service-side auto-labeling policy configured to remove existing sensitivity labels from files at rest in supported locations such as SharePoint Online and OneDrive. This represents a shift from earlier approaches that relied on PowerShell, client-side tooling, or manual remediation.
The workflow begins with defining scope. Administrators must explicitly choose which locations are in scope (for example, specific SharePoint sites or OneDrive accounts). This is a critical control point. Broad scoping decisions can have tenant-wide impact, particularly if encryption is involved, because removing a label may also remove associated protection settings.
Next, conditions are defined to determine which content is targeted. These conditions may include sensitive information types, classifiers, file properties, or other metadata. Even though the end goal is label removal, the policy still relies on matching logic to identify candidate content. Overly broad conditions can result in unintended content being modified.
Before any action is taken, the policy runs in simulation mode. Simulation allows administrators to preview which files would be affected without making changes. This step should be treated as mandatory. Simulation results should be reviewed carefully, ideally with compliance or information governance stakeholders, to validate that the right content is being targeted.
Once the policy is published, label removal occurs asynchronously. Changes may take time to propagate depending on content volume and service processing. Importantly, there is no undo button. If labels are removed incorrectly, administrators must rely on reclassification through new policies or manual intervention.
Overriding existing and manually applied labels
Historically, manual labels took precedence and could not be overridden automatically. This new capability fundamentally changes that behavior.
The workflow starts with creating or editing an auto-labeling policy and navigating to the additional label settings section (see screenshot above). Here, administrators can explicitly enable replacement of existing labels. This setting applies regardless of how the label was originally applied, whether automatically or manually.
As with label removal, scope definition is the first major decision point. Policies can target SharePoint sites, OneDrive locations, or other supported workloads. Scoping should be as narrow as possible during early testing to avoid unexpected reclassification of business-critical content.
Conditions are then defined to determine when replacement occurs. These conditions might be based on updated sensitive information definitions, business rules, or changes in classification logic. When a match is found, the existing label is replaced with the new label specified in the policy.
Simulation mode plays a critical role here as well. Simulation helps validate that replacement behavior aligns with expectations and does not unintentionally downgrade or upgrade content classification. This is especially important in environments where labels drive access controls, external sharing restrictions, or downstream records management.
After publishing, replacement occurs automatically over time. Users are not prompted, and no justification is requested, even if the original label was applied manually. This has significant implications for user trust and change management. Organizations should communicate clearly when label override policies are introduced to avoid confusion or support escalations.
A word of caution: don’t muck it up!
Both workflows introduce powerful administrative control, but they also increase the risk of misconfiguration. As a result, operational guardrails are essential.
First, simulation should always be used and results reviewed by more than one stakeholder. Treat simulation output as a validation artifact, not a formality.
Second, policies should be deployed in phases. Start with a small, well-understood scope such as a pilot site or test library before expanding to broader locations.
Third, administrators should understand downstream dependencies. Sensitivity labels often integrate with retention labels, records management, eDiscovery, and sharing controls. Removing or replacing a label may have cascading effects beyond classification alone.
Finally, documentation and change management still matter. These features change long-standing behavior in Microsoft Purview. Users and site owners should be informed when automatic overrides or removals are introduced so that changes to content classification do not appear arbitrary or erroneous.
If you’re responsible for sensitivity labels, it’s worth slowing down and fully understanding what these options do before turning them on in production.
Final thoughts
For organizations that have struggled to adapt their sensitivity labeling strategy over time, these updated Purview labelling features are a big step forward. They finally acknowledge that classification is not static and that admins need safe ways to course correct.
Also remember: with great power comes the ability to very quickly make a mess.
If you’re working with sensitivity labels today, these are features you’ll want to understand deeply before using. Reach out to us if you would like a deep dive of these capabilities!
Learn more about these updates to auto-labeling policies:
