People-First Purview (Technical): Sensitivity Labels as Architecture
- E.C. Scherer
- Dec 29, 2025
- 6 min read
Most organizations treat sensitivity labels like a file cabinet or sticky notes. Something you slap on a document to keep things organized.
That’s a mistake.
Sensitivity labels are one of the biggest lines of defense in your Microsoft Purview deployment. They shape reporting, enforcement, user experience, and every downstream control that depends on context. Once they are live, changing them is expensive. Not technically, but socially.
That’s why label design is an architecture decision, not an admin task.
Where Bad Label Design Shows Up First
When labels are designed poorly, you do not feel it in dashboards. You feel it in support tickets.
Users get locked out of documents they need. People are confused about which label to choose. Legal asks why two labels sound identical but behave differently.
By the time DLP or auto labeling gets blamed, the real problem already happened upstream.
Overcomplicated labels create friction long before they create protection.
Stop Classifying Data Types With Labels
One of the fastest ways to get into trouble is talking about labels like this:
“This is our PII label.” “This is our client data label.” “This is our HIPAA label.”
That framing tells me the organization is classifying data types instead of defining sensitivity levels.
Client data can be public or confidential. A full name is not automatically protected PII. Users should not be deciding when data crosses a legal threshold.
Sensitivity labels exist to express organizational intent and risk tolerance. Purview already knows how to detect PHI, PII, PCI, and other sensitive information types in the background.
Let it do that work quietly.
Labels should stay clean, reusable, and human readable.
Start With Policy, Not the Portal
My first step is never clicking into Microsoft Purview.
It’s a whiteboard.
We start by walking through the data classification policy.
A good policy has already done the hard work of defining what constitutes public, confidential, and highly confidential data.
A great policy goes further and clearly spells out controls like encryption expectations and internal versus external access.
Labels should map directly to that policy.
When Legal or Compliance pushes back later, nothing beats being able to say, “Here’s the policy. Here’s the label. They match.”
If you cannot point to the line in the policy a label represents, that label is a liability.
Minimum Viable Label Sets Beat Perfect Ones
People get stuck on label count. That is usually the wrong thing to worry about.
I have seen organizations with three labels and two sublabels each that make me just as nervous as environments with twenty labels. The difference is not quantity. It is how people think about them.
If labels force users to debate which regulation applies, the design has already failed.
My baseline model is simple:
Top level labels represent sensitivity. Sublabels represent collaboration scenarios.
For example:
Confidential / Internal
Confidential / External
Highly Confidential / External Approved Domains
This preserves workflow continuity without forcing users to become compliance experts.
What I will not do is map sublabels to data types. Confidential / PII does not mean anything useful to most users. And the moment a document contains multiple types of sensitive information, the model collapses.
Mandatory Brain Break
A hatchling common snapping turtle (Chelydra serpentina), about 3.5 inches long pictured by @ecs_nature.
Snapping turtles react defensively at every stage of life. What changes isn’t the behavior, it’s how much context we have to interpret it. Without context, a reaction looks like risk. With context, it’s just a system responding to its environment. A reminder that early signals still need observation before enforcement.
Scope Before Protection
Once labels exist, the instinct is to turn everything on.
That is where most programs hurt themselves.
The biggest mistake organizations make after creating labels is mandatory labeling without a plan to recommend or auto apply labels. That move feels decisive. It also guarantees frustration.
Mandatory labeling only works when it is paired with intent, guidance, and automation.
Otherwise, you are outsourcing classification decisions to users who do not want that responsibility and should not have it.
That said, if a label is supposed to apply protection, it should do so from day one. If Highly Confidential / Internal is meant to block external access, it should actually block external access. That just means taking the time to test, validate, and pilot before rolling it out broadly.
Users should only have to learn labels once.
Why Encryption Breaks First
Encryption is usually where early enforcement causes the most pain.
Not because encryption is bad, but because it exposes architectural gaps immediately.
If an organization does not have a clear B2B identity model, visibility into external users, or the ability to revoke access in real time, external labels turn into roadblocks instead of safeguards.
What happens next is predictable. Users manually scope permissions. Exceptions pile up. Support tickets explode. The label gets blamed.
A healthy collaboration model sounds like this:
“We know this domain. We know these users. They get editor rights, and we can revoke access at any time.”
If you cannot say that yet, broad encryption enforcement will create more workarounds than protection.
Mandatory Does Not Mean Everywhere
I will never advocate for mandatory labeling on emails or meetings.
Those are most organizations’ primary communication channels. Slowing them down indiscriminately is a great way to lose support fast.
What does work is making labels available on emails and meetings, using recommended labeling based on sensitive information types, and keeping the experience lightweight.
For files and documents, I am much firmer. If you are going to require labels anywhere, that is the place. Even then, users deserve help. “We detected a few SSNs in this document. Would you like to label it Highly Confidential / Internal?” is guidance, not nagging.
If an organization is not working toward auto labeling, mandatory labeling will never scale.
Auto Labeling Is Earned
Auto labeling makes people nervous for good reasons. The fear is not the technology. The fear is breaking workflows or losing access.
I am comfortable letting auto labeling apply labels only after simulation mode has been run and validated. Simulation should confirm what you already understand about how data is used. It should not reveal surprises.
I always start with files and documents. I look at which departments consistently work with sensitive data and what I know should stay internal, while explicitly noting exceptions.
Auto labeling fails most often when it is deployed without a clear understanding of how users actually handle sensitive data. Automation amplifies assumptions. Good or bad.
Users do not need to think about auto labeling. They need to know labels exist, what they mean, and how to change them if necessary. Beyond that, automation can quietly do its job.
If auto labeling causes access issues that are not tied to user education gaps, it gets turned off immediately. That is not failure. That is responsible operation.
Labels Are Inputs, Not Controls
The biggest long term mistake organizations make with sensitivity labels is using them to classify data types instead of sensitivity levels.
Used correctly, labels are very good at:
Showing where sensitive data lives
Prioritizing systems during incident response
Providing consistent signal for DLP and Insider Risk
Adding context to security decisions
Labels should own access to data. They should influence sharing through DLP. They should gently nudge user behavior by signaling caution.
They should not be the only enforcement mechanism, a proxy for intent, or a disciplinary tool.
Labels are part of the puzzle. Important pieces, even border pieces, but not the whole picture. For compliance especially, knowing what sensitive information types are involved often matters more than the label applied.
My mental model is simple:
Labels exist to discover and inform, not to be the only stopgap between you and the wild west of the internet.
Final Advice
If I have said it once, I have said it a million times.
Sensitivity labels are the single most important part of your Purview deployment.
Do them right the first time or prepare to spend a lot of time in PowerShell undoing your own work.
Design them intentionally. Map them to policy. Let them inform decisions instead of trying to make them on their own.
Everything else works better when labels are solid.
Next in the technical series: People-First Purview (Technical): Insider Risk as Signal, Not Surveillance
Next in the strategy series: People-First Purview: DLP Without Breaking Trust
Comments