HOWTO: Teach users to correctly pick a Sensitivity Label

Teaching users how to correctly choose a sensitivity label is one of the most critical parts of any Microsoft Purview implementation.

The labels themselves may be technically configured correctly, but the deployment will still fail if users do not understand how to apply them. First impressions matter. The process needs to feel simple, predictable, and easy to explain, even when the underlying classification model is not always intuitive.

I have always used what I call the Sensitivity/Audience Rule.

Sensitivity First

Start by identifying the sensitivity of the information.

Do not begin by asking who the document will be sent to, instead ask how sensitive is the information itself?

Is it intended for: Public consumption? Internal use? Confidential business information that requires additional protection or special handling?

This first decision establishes the level of protection the information requires.

A document does not become public simply because someone wants to send it outside the organization. Likewise, a document is not automatically confidential just because it is currently being shared with a small group of people.

The contents determine the sensitivity.

Audience Second

Once the sensitivity has been determined, select the appropriate audience.

Who should be allowed to access this information?

Will it be: Shared externally? Available to everyone inside the organization? Limited to a specific team? Restricted to a smaller group of individuals? Accessible only by the people who were specifically named or granted access?

The audience determines how broadly the information may be shared within the selected sensitivity level.

For example, a document may contain confidential information but still need to be shared with an approved external partner. In that case, the correct label is not based only on the fact that the recipient is external. The user must first identify the document as confidential and then select the confidential label intended for approved external sharing.

Why this works

I have been involved at either an architect or implementer level in these kinds of rollouts about a dozen times, with the smallest being ~100 users and the largest about 300 thousand. One common theme was confusion when trying to evaluate sensitivity, audience, sharing permissions, and everything else lumped up into a few short training sessions. Users are more likely to choose the correct label when the decision is broken into two separate questions.

Separating the process into two steps gives users a repeatable method they can apply to email, documents, spreadsheets, presentations, and other information. The names of the labels may differ between applications, but the decision process remains the same:

Why this doesn’t work

This doesn’t work with some label policies, especially really simple flat ones, where instead of simplifying it, it makes the process complicated for no reason. When there are only 2-3 options, breaking it down is not necessary.

This also fails where you have a complex setup that’s not correctly designed. This is why it’s so difficult to join a project like this already in progress where there were mistakes made early in the architecture phase and now the implementation is failing.