Manual First, Then Automatic? The Right Rollout Order for Sensitivity Labels in Purview

The responses shifted the conversation from a question about user behavior to a question about classification quality. Several participants emphasized that the biggest risk doesn't sit with the user, but with the classification configuration itself: default Sensitive Information Types typically miss a lot of genuinely sensitive data while also generating plenty of false positives. Without tuned detection rules and a thoughtful file plan, any rollout sequence is inherently shaky according to the responses, regardless of whether that sequence is manual-first or automatic-first.

A second recurring point was that "wrong labels" was largely seen as a solved problem, thanks to two built-in safety nets that were explained further in the discussion: a recommendation mode on the user side and a simulation mode on the service side.

A third point concerned sequencing: several participants advised piloting based on risk, selecting by department and data type such as legal, finance, HR and engineering, rather than a random group of users. It was also explicitly advised to deliberately keep encryption, mandatory labeling and container labels out of the first wave. A concrete anecdote was shared about an entire department being unable to edit documents for hours after one of these settings was turned on too early, as an illustration of why these specific settings cause helpdesk pain.

Microsoft Learn distinguishes two fundamentally different forms of automatic labeling, and that distinction shapes the entire strategy. Client-side automatic labeling works inside Office applications such as Word, Excel, PowerPoint and Outlook while the user is working: the user sees a recommendation and can accept or dismiss it, safe to try out through recommendation mode. This form depends on minimum app versions. Service-side automatic labeling works through an auto-labeling policy on data at rest in SharePoint and OneDrive and data in transit in Exchange, without user interaction, and works tenant-wide regardless of app version. Only the service-side variant also supports file types such as PDFs and images.

On overwriting existing labels, the documentation is explicit: an auto-labeling policy never removes a label in a way that leaves content unlabeled. Manually applied labels are never replaced by automatic labeling, regardless of priority. Automatically or default applied labels with a lower priority can be overwritten by both client-side and service-side automatic labeling, with one exception for sublabels under the same parent label. Automatically applied labels with a higher priority are never overwritten.

Service-side automatic labeling also has a specific setting to still upgrade an earlier, lower-priority manual label: the option to override a manually applied label that has lower priority. That setting is off by default and has to be turned on deliberately.

Both automation forms support a dry run. Auto-labeling policies don't support recommended labeling themselves, so an admin first runs the policy in simulation mode to see what would happen to the real data, without any label actually being applied. Client-side recommendation mode interrupts the user's workflow slightly, but according to the documentation is an effective way to teach users in the moment which sensitive data they're handling, which improves the accuracy of future labeling.

The answer to the core concern about wrong labels is more nuanced than "prevent" or "allow": the system is deliberately asymmetric by design. Under-classification, a user picking a label that's too low, is recoverable through a service-side auto-labeling policy with the right override setting turned on. Over-classification, a user deliberately or accidentally picking a label that's too high, is never automatically reverted. That's a deliberate, safe design choice: the system would rather fail on the side of too much protection than too little.

"You are not dependent on flawless manual labeling for your policy to be effective."

This asymmetry changes the character of the sequencing question. The concern that manual labeling first "contaminates" data in a way that makes automation harder later is largely unfounded: under-classification is technically recoverable, and over-classification is, by design, the safer failure mode. What isn't recoverable through label settings alone is a poorly tuned classification engine. Default Sensitive Information Types often miss real sensitive data while generating just as much noise in the other direction, so any rollout sequence stands or falls on how well those detection rules are tuned, using Exact Data Match for proprietary datasets and trainable classifiers where needed, trained and validated on production-like data before automatic labeling is turned loose on mail or SharePoint.

A file plan is the second foundation. Sensitive Information Types typically cover only one label well, such as personal data; the other labels in a taxonomy need a business definition that only the business itself can provide. That makes mislabeling primarily a training and business problem, not an IT blocker to engineer around with ever stricter technical rules.

Simulation mode and recommendation mode together form the architectural safety net that makes the original sequencing question largely moot. Instead of choosing between "fully manual first" or "automatic from day one," an organization can turn on manual labeling with recommendation mode for users from the start, while simultaneously running service-side auto-labeling in simulation mode to see what the engine would do without enforcing anything. Enforcement follows only once the false positive rate is low enough and users, in practice, mostly pick the same label the engine would suggest, starting with one or two high-confidence scenarios rather than organization-wide.

Sequencing by risk therefore works better than sequencing by user count. Instead of 10, then 150, then everyone, the preferred sequence is a pilot by department and data type, with a taxonomy that starts small and recognizable, and a first wave limited to visible markings such as a header, footer or watermark. Encryption, mandatory labeling and container labels belong deliberately in later waves, since these are exactly the settings that cause immediate helpdesk pain when activated too early, such as a department temporarily unable to edit documents. Licensing requirements deserve early attention at a scale of thousands of endpoints: service-side auto-labeling and trainable classifiers typically sit in a higher Purview license tier, which partly determines whether early automation is feasible within budget.