M365 PlaybooksPurview · SharePoint · Teams · Exchange· Plan · Labels and policies
Design your labels and label policies
Purpose
Give everyone one simple, shared way to say how sensitive information is, and decide how much the organization will do for them by default. Labels describe sensitivity; label policies decide whether people use them well. Together they are what DLP, encryption and Copilot protections rely on, so a taxonomy people understand and policies that fit how they work are worth getting right before anything is built.
Overview
Five or fewer labels with plain names, the protection each applies, what label policies do by default, and which applications are in scope.
- Effort
- About 10 to 15 person-days
- Duration
- 4 to 6 weeks
- Complexity
- Medium
- Who's in the room
- Information security lead (taxonomy owner), records or privacy officer, legal, Purview admin, communications lead, two or three department representatives
- Beyond E5
- Nothing beyond Microsoft 365 E5. Meeting options in labels need Teams Premium, and Copilot features need Microsoft 365 Copilot licences, if those are in scope.
Risk of not doing it
Without agreed labels and policies, departments invent their own markings, protection is applied inconsistently, and the controls that rely on labels have nothing reliable to act on.
Key activities
The plan in order: what must be true first, what to decide, then how to configure the pilot and production.
Prerequisites
Gather the rules your labels must reflect
Collect what already defines sensitivity: any classification policy or security marking scheme, privacy obligations, records requirements, and contract clauses on partner or client information. The labels have to satisfy all of them with as few labels as possible, so knowing the list up front avoids a late redesign.
Find out what you are protecting
Purview's data explorer shows which sensitive information types already appear across email, SharePoint and OneDrive, and where. Pair it with short conversations with the departments that handle the most sensitive material. You need enough evidence to decide which labels need real protection and which only need a marking.
Decisions
Decision: How many labels?
Microsoft notes that labels work noticeably less well when people see more than five main labels, or more than five sublabels under one. It suggests names such as Personal, Public, General, Confidential and Highly Confidential. Use sublabels only where protection differs; a parent label can't be applied by itself, and Microsoft is replacing parent labels with label groups.
Options
- Mirror every existing classification level
- Five or fewer main labels, sublabels only where protection differs
Recommended default: Five or fewer main labels, sublabels only where protection differs
Decision: Which labels encrypt?
Encryption travels with the file but limits who can open it, complicates sharing with partners, and Copilot only uses encrypted content when the person has both the VIEW and EXTRACT rights. Permissions the admin defines in the label work better than letting people set their own. Keep encryption for the tier where an unauthorized reader would cause real harm.
Options
- Encrypt every label above Public
- Encrypt only the top tier, with admin-defined permissions
- No encryption at first
Recommended default: Encrypt only the top tier, with admin-defined permissions
Decision: Which applications are in the first release?
Labels behave differently in each place, and each brings its own requirements. Files and email carry markings and encryption. A label on a site, group or team locks its privacy and controls guests and sharing, and owners can change those settings by changing the label, but the files inside aren't labelled by it. Meeting options in labels need Teams Premium. In Power BI a label protects exported data, not access. Default labels on SharePoint libraries need a plan for which libraries and how their owners are told. Decide what goes first and what follows.
Options
- Everything at once
- Files and email first, then sites and groups, then the rest
- Files and email only
Recommended default: Files and email first, then sites and groups, then the rest
Decision: What do label policies do by default?
Label policies decide what people experience. Microsoft advises as few policies as possible, often one. Recommended defaults: a non-encrypting default label such as General for documents and email; a justification when someone removes or lowers a label (on by default); email recommending its attachment's label; and mandatory labelling only for groups that must label everything, because without a default it frustrates people, and it makes Print to PDF unavailable.
Options
- No default, labelling optional
- Mandatory labelling for everyone
- Default label and justification; mandatory only where needed
Recommended default: Default label and justification; mandatory only where needed
Decision: Do labels need more than one language?
Label names and tooltips for files and email can be shown in several languages, but you supply the translations; nothing is translated automatically. Labels for sites and groups show only their original language. In a bilingual organization, translate file and email labels and give container labels names that work in both languages.
Options
- One language only
- Translated file and email labels; bilingual names for container labels
Recommended default: Translated file and email labels; bilingual names for container labels
Decision: Is automatic labelling in scope?
E5 includes automatic labelling, in Office apps and for stored content. It belongs in the Refine stage, once manual labelling is stable, but the decision affects design now: each label that will be applied automatically needs conditions that clearly match it, such as specific sensitive information types.
Options
- Not planned
- Planned for Refine; design labels with it in mind
- From day one
Recommended default: Planned for Refine; design labels with it in mind
Decision: Who owns the labels?
Labels sit between security, records, privacy and the people doing the work, so they drift when nobody owns them. Name one owner who decides on changes, with records, privacy and legal as reviewers. IT administers labels but shouldn't decide what they mean.
Options
- IT owns and decides
- Information security owns; records, privacy and legal review
Recommended default: Information security owns; records, privacy and legal review
Pilot configuration
Test names and tooltips with real people
Give 15 to 20 anonymized real examples to people from several departments and ask them to pick a label from names and tooltips alone. Where they disagree, the name or tooltip is wrong, not the people. Rewrite until most testers agree on most examples.
Production configuration
Approve the label and policy specification
Record every label (name, tooltip, protection, priority with the most restrictive last, languages) and every policy setting in one specification, with the first-release scope. Have the owner and reviewers approve it, and hand it to the Prepare stage for testing.
Make it enforceable
The decisions become label policy settings: a default label, justification to lower a label, and mandatory labelling where needed. Until they are tested in Prepare and published in Deploy, they are a document, and a document alone doesn't change behaviour.
Partly enforced. The gaps are a risk until a mechanism covers them.
Approval and readiness
Draft the specification
Labels, protection, policies and first-release scope in one document.
Move on when: Every label and setting has a reason
Test names with real peopleChange: Explain
Run the naming test and revise.
Move on when: Most testers pick the intended label
Review with legal, privacy and records
Show how each obligation is met.
Move on when: No open objections
Approve with the sponsorChange: Inform
Fifteen minutes on the labels, defaults and cost of not doing it.
Move on when: The specification is approved for Prepare
Common challenges
If youCopy an existing classification scheme one-to-one
What tends to happenPeople face ten labels, pick the first that seems close, and labels stop meaning anything.
A better approachKeep five or fewer main labels and map the old categories to them in the guide.
If youEncrypt most labels to be safe
What tends to happenSharing and co-editing get harder, so people lower labels to get work done.
A better approachEncrypt only the top tier; protect the rest with markings and DLP.
If youMake labelling mandatory with no default
What tends to happenEvery save and send is interrupted, and people pick whatever closes the prompt.
A better approachSet a non-encrypting default and ask for a reason only when a label is lowered.
If youPlan in one language for a bilingual workforce
What tends to happenHalf the organization sees labels in a language they don't work in, and container labels can't be translated later.
A better approachDecide languages now, and name container labels to work in both.
Checkpoints
Pilot
- Can testers pick the intended label from names and tooltips alone?
- Does every encrypting label have a reason and a defined audience?
Production
- Is the specification approved, with priority order and languages?
- Are the first-release applications and default settings decided?
- Is automatic labelling recorded as in or out of scope?
Success measures
Capture a baseline before you start, or you won't be able to show the change.
| Measure | Where you see it | Good direction |
|---|---|---|
| Testers choosing the intended label | Naming test results | Up |
| Main labels in the taxonomy | Specification (five or fewer) | Steady |
| Open objections from legal, privacy and records | Review log | Down |
Ready-to-use text
Label and policy specification columns
Label | Tooltip (EN) | Tooltip (FR) | Who it's for | Protection (marking / encryption / who can open) | Priority | Applies to (files, email, sites, meetings, Power BI) | Automatic labelling later (yes/no, conditions) || Policy | Targets | Default label | Mandatory | Justification | Help link
Tooltip pattern
[Label]: for [who can see it]. For example: [everyday example], [everyday example]. This label [adds a footer / restricts who can open the file].
Additional reading
Plan
Changelog
Changelog (2 versions)
| Version | Date | Author | Change |
|---|---|---|---|
| 2 | Sev Derghazarian | Now covers labels and label policies together, plus requirements per application, languages and automatic labelling scope. Testing moved to the new Prepare stage. | |
| 1 | Sev Derghazarian | First version. Facts checked against Microsoft Learn on 2026-10-15. |