People-First Purview (Strategy): Labeling
- E.C. Scherer
- Dec 28, 2025
- 5 min read
Updated: Jan 13
Make It Work or Know How to Pivot
I’m going to start with the uncomfortable part.
If users are complaining that they have to apply a sensitivity label before they can even save a file, the problem isn’t resistance. It’s the design isn't thinking about "people-first."
That complaint usually means one of three things happened:
auto-labeling wasn’t trusted, so it wasn’t deployed
labeling was turned on because “best practice” said it should be
or no one tested this with people who don’t live in security tools all day
None of those are user failures. They’re implementation decisions.
Why users skip labels (and why that matters)
Users don’t skip labels because they’re careless. They skip labels because they’re under pressure.
They need to send the invoice. They need to get paid. They need to onboard someone now. They’re five minutes from a deadline and something is blocking “Save.”
When security adds friction at that moment, users don’t slow down and reflect. They route around it.
The idea that labeling becomes “muscle memory” only applies to security teams. For everyone else, it becomes a recurring annoyance they adapt to, not a habit they embrace.
That’s the reality you have to design for.
What sensitivity labels are actually for
Sensitivity labels are not a test users pass.
They’re metadata. Metadata should be inferred.
The system should do the first round of thinking. Humans should confirm or adjust when it matters.
“Yes, this is Highly Confidential / Internal Only.”
“No, this is Highly Confidential / External.”
That interaction is reasonable. Asking users to classify data from scratch every time is not.
K.I.S.S. (keep it simple, silly)
Data created → Auto-label kicks in → User confirms or adjusts → DLP responds based on labelWhy this series starts with people-first labeling
Labeling comes first because labeling is how you learn what data actually matters to your organization.
Not every full name is HIPAA.
Not every SSN is data your org is responsible for.
If that were true, none of us could email ourselves a W-2.
Labels give you discovery with context:
what data is sensitive to you
where it lives
who works with it
how it moves
Without that foundation, everything else is guesswork.
The most common labeling mistake I see
Labels that:
don’t align to the data classification policy
aren’t backed by auto-labeling or recommendations
rely entirely on users doing the right thing
That isn’t a people-first strategy. That’s hope.
If the system isn’t doing any of the work, the program won’t scale.
Labels should enable work, not block it
Before I design labels, I ask departments how data actually moves.
Not how policy says it should. How it really does.
Short and Sweet
Build off this
Question | Answer |
What sensitive data do you send externally? | |
Who do you send it to? | |
What breaks if this is blocked? | |
Are there deadlines that make delays unacceptable? | |
Is monitoring first acceptable before enforcement? |
The Full Questionnaire
...or copy off my test
Question Area | Question | Why We Ask This |
Data Types | What types of sensitive data does your team create or handle? (Invoices, contracts, HR records, financial data, student data, etc.) | Helps determine which sensitivity labels and detections actually apply |
External Sharing | Does your team send sensitive data outside the organization? | Identifies workflows that must be enabled, not blocked |
Recipients | Who do you send this data to? (Vendors, customers, partners, regulators) | Informs domain allowlists and label-based DLP exceptions |
Frequency | How often does this sharing occur? (Daily, weekly, monthly, ad hoc) | Helps assess risk and prioritize enforcement vs monitoring |
Time Sensitivity | Are there deadlines where delays would impact operations or revenue? | Highlights where friction will cause workarounds |
Tools Used | Where does this data live and move? (Email, SharePoint, OneDrive, Teams, third-party apps) | Ensures policies are scoped to the right locations |
What Breaks | What would stop working if this data could not be shared externally? | Identifies business-critical exceptions |
Current Workarounds | Are there any existing workarounds when security controls block work? | Early warning sign of trust erosion |
Approved Destinations | Are there known external domains or partners that should always be allowed? | Enables label-based and domain-scoped DLP rules |
Audit vs Enforcement | Would monitoring first be acceptable before enforcing restrictions? | Sets expectations for phased rollout |
Escalation Path | Who should security contact if a workflow is blocked incorrectly? | Reduces frustration and ticket churn |
Success Criteria | What does “this is working” look like for your team? | Aligns security metrics with business reality |
This step changes policies more than any compliance requirement ever has.
Because now you’re designing controls around real workflows, not assumptions.
When labeling gets rejected or watered down
Sometimes leadership says no. Sometimes labels are optional. Sometimes they exist only to satisfy an audit.
When that happens, I don’t pretend labeling is working. I pivot.
If labeling is too much friction, then we need:
managed devices
endpoint DLP
DLP in alert or monitor mode
Not because it’s ideal, but because visibility matters.
I would rather prevent issues. But if prevention is off the table, I at least want to see where data is going so we can respond early and intelligently.
A program with no safety net isn’t bold. It’s fragile.
Auto-labeling: audit first, always
Auto-labeling should start in audit mode. Everywhere.
Every organization is surprised by what they find:
sensitive data in places they forgot about
systems that need exceptions
teams handling high-risk data they never scoped
From there, you pilot intentionally. Legal. HR. Finance. Sales. Teams that handle sensitive data and still need to collaborate externally.
The goal isn't perfection. It's understanding.
Labels as controlled exceptions
Here’s where labeling starts to earn trust.
Some teams have to send sensitive data externally. That shouldn’t be a fight. It should be designed.
This label allows Finance to send invoices externally. This label bypasses a DLP rule by design. This label restricts sharing to specific domains.
If you haven’t mapped those workflows, you don’t have a data security program. You have a theory.
How you know you’ve gone too far
If labels don’t match:
the classification policy
the training language
what a normal person can understand
Users don’t just complain. They stop reporting issues. They start working around the tools. They stop trusting the program.
At that point, more enforcement makes things worse, not better.
What I tell security leaders to measure instead
Stop asking whether users are manually labeling “correctly.”
Start asking whether labels are:
auto-applied
auto-recommended
present before users have to think about them
Turn on auto-labeling in simulation for the data you actually care about. Map labels to DLP policies that support real workflows.
Finance sending credit card numbers to approved vendors because the data is labeled correctly isn’t a failure.
It’s the control working as intended.
The takeaway
People-first labeling doesn’t lower standards.
It makes them survivable.
It shifts responsibility away from individual users and onto systems that can actually carry it.
Next in this series: People-First DLP, where we take what labeling teaches us and apply it using Microsoft Purview as a guardrail, not a brick wall.
Comments