M365 PlaybooksPurview· Plan
Design a sensitivity label taxonomy people use
Purpose
Give everyone in the organization one simple, shared way to say how sensitive a piece of information is, so the right protection travels with it: into an email, onto a partner's device, or into a Copilot answer. A taxonomy people understand is the foundation that DLP, encryption and safe use of AI all depend on. A taxonomy they don't understand produces confident-looking labels that mean nothing, which is worse than no labels at all.
Overview
A short label taxonomy with plain names, protection per label, an owner, and policy defaults, tested with the people who will apply it.
- 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
- Licensing
- Applying labels manually is included in Microsoft 365 E3, E5 and Business Premium, and Office 365 E3 and E5. Automatic labelling, default labels for SharePoint libraries, labels for scheduled meetings and the activity and data explorer reports need Microsoft 365 E5, Microsoft Purview Suite, or Microsoft 365 E5 Information Protection and Governance.
Risk of not doing it
Without an agreed taxonomy, departments invent their own markings, protection is applied inconsistently, and the controls that rely on labels (DLP, encryption, Copilot protections) 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 in your organization: any information classification policy, security marking scheme, privacy obligations, records requirements, and contract clauses that dictate how partner or client information is handled. Note where these rules overlap or contradict each other. The taxonomy you design has to satisfy all of them with as few labels as possible, so knowing the full list up front stops a late objection from legal or records from forcing a redesign.
Find out what you are actually protecting
Before naming labels, look at the information itself. With an E5-level licence, Purview's data explorer shows which sensitive information types already appear across email, SharePoint and OneDrive, and where. Without one, sample a few sites and mailboxes with their owners. Either way, talk to the departments that handle the most sensitive material. The aim is not a full inventory: it is enough evidence to decide which labels need real protection, such as encryption, and which only need a visual marking.
Confirm licensing, admin roles and Office versions
Applying labels by hand is included in Microsoft 365 E3, E5 and Business Premium. Automatic labelling needs an E5-level plan, so check which you have before promising it. Labels are built into Microsoft 365 Apps; the Azure Information Protection add-in is retired, and standalone (perpetual) editions of Office don't support sensitivity labels at all, so find any remaining perpetual installs now. Assign label administration through the Information Protection role groups, using the least privileged role that does the job. People who only apply labels need no admin role.
Decisions
Decision: How many labels?
Microsoft's own guidance is to keep labels to a minimum: their effectiveness drops noticeably when people see more than five main labels, or more than five sublabels under a main label. Microsoft suggests starting with names such as Personal, Public, General, Confidential and Highly Confidential, and its default labels follow that pattern. Use sublabels only where protection differs, for example who can open a Confidential file. Note that a parent label with sublabels is only a heading and can't be applied by itself; Microsoft is replacing parent labels with label groups.
Options
- Mirror every existing classification level and sub-category
- Five or fewer main labels, with sublabels only where protection differs
- Microsoft's default labels, unchanged
Recommended default: Five or fewer main labels, with sublabels only where protection differs
Decision: Which labels apply encryption?
Encryption is the strongest protection a label can apply because it travels with the file, but it also changes how the file behaves. It limits who can open it, can complicate sharing with people outside the organization, and Copilot only returns content from an encrypted file to someone who has both the VIEW and EXTRACT usage rights. Microsoft also advises against using a label that encrypts as the default for documents. Reserve encryption for the tier where an unauthorized reader would cause real harm, and protect the rest with visual markings and DLP.
Options
- Encrypt every label above Public
- Encrypt only the highest tier, with permissions defined by the admin
- No encryption at first; visual markings only
Recommended default: Encrypt only the highest tier, with permissions defined by the admin
Decision: What happens by default?
Label policies decide what people experience: a default label for new documents and email, whether a label is required before saving or sending (mandatory labelling), whether someone must give a reason to remove a label or choose a lower one, and a link to your own help page. Microsoft warns that mandatory labelling without a default label frustrates people. Its own example policy publishes all labels to all users with General as the default and a justification required to lower a label, which keeps everything labelled while letting people correct the exceptions.
Options
- No default label; labelling optional
- Mandatory labelling with no default
- A non-encrypting default such as General, with a justification to remove or lower a label
Recommended default: A non-encrypting default such as General, with a justification to remove or lower a label
Decision: Who owns the taxonomy?
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 new labels, renames and retirements, with records, privacy and legal as reviewers. IT administers the labels but should not 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
Microsoft recommends testing label names and tooltips with the people who will apply them, and it is the single most useful thing you can do at this stage. Give 15 to 20 real, anonymized examples (an email to a supplier, a draft budget, a staff list) to people from several departments and ask them to choose a label using only the names and tooltips. Wherever they disagree, the name or the tooltip is wrong, not the people. Rename and rewrite until most testers agree on most examples.
Write a one-page labelling guide
For each label, write who it's for, two or three everyday examples, and what it does to the file (a header, a watermark, or a restriction on who can open it). Keep it to one page. Label policies can link to your own help page, so this guide becomes the link people see next to the labels in their apps.
Production configuration
Approve the label specification
Record every label in one table: name, tooltip, purpose, protection (marking, encryption, who can open it), sublabels, and priority order. Priority matters: the most restrictive label goes last, and the order decides when people are asked for a justification, which label wins when several apply, and which label Copilot shows. Add the policy settings agreed above. Have the owner and reviewers approve it.
Hand the specification to the deployment team
Turn the specification into a deployment backlog: labels to create, policies to publish, and the platform prerequisites to schedule, such as turning on sensitivity labels for Office files in SharePoint and OneDrive and deciding on co-authoring for encrypted files. Agree when the taxonomy will be reviewed again.
Make it enforceable
The decisions here become label policy settings in the Deploy stage: a non-encrypting default label for documents and email, a justification to remove or lower a label, and a help link to the labelling guide. Until those policies are published, the taxonomy is a document, and a document alone does not change behaviour.
Partly enforced. The gaps are a risk until a mechanism covers them.
Approval and readiness
Draft the specification
Write the first version of the label table and policy settings from the decisions above.
Move on when: Every label has a purpose, a protection setting and a priority
Test with people from several departmentsChange: Explain
Run the naming test, revise, and repeat once if testers still disagree.
Move on when: Most testers choose the intended label for most examples
Review with legal, privacy and records
Walk reviewers through the obligations inventory and show how each one is met.
Move on when: No open objections from reviewers
Approve with the sponsorChange: Inform
Present the taxonomy, the defaults and the cost of not doing it, in fifteen minutes.
Move on when: The sponsor approves the specification and the deployment window
Tell people what's comingChange: Inform
Announce that labels are coming, why, and when the pilot starts, before anyone sees a new button.
Move on when: Staff have heard about labels from leadership before they appear
Common challenges
If youCopy an existing classification scheme one-to-one
What tends to happenPeople face ten or more labels, pick the first one that seems close, and labelled data stops meaning anything.
A better approachKeep five or fewer main labels and map the old categories to them in the labelling guide.
If youEncrypt most labels to be safe
What tends to happenSharing with partners and co-editing get harder, so people lower labels just to get work done.
A better approachEncrypt only the top tier and protect the rest with visual markings and DLP.
If youName labels after internal policy codes
What tends to happenPeople guess, and the same document gets three different labels in three departments.
A better approachUse plain names, write tooltips with everyday examples, and test both with the people who will use them.
If youMake labelling mandatory with no default
What tends to happenPeople are interrupted on every save and send, and choose whatever closes the prompt fastest.
A better approachSet a non-encrypting default and ask for a justification only when someone lowers or removes a label.
If youLet the taxonomy belong to IT alone
What tends to happenLabels drift from legal and records obligations, and nobody can approve a change.
A better approachName an owner in information security, with records, privacy and legal as reviewers.
Checkpoints
Pilot
- Can testers choose the intended label using only names and tooltips?
- Does every label that encrypts have a reason and a defined audience?
- Is the labelling guide one page, in plain language, with examples?
Production
- Is the label specification approved by the owner and all reviewers?
- Is the priority order recorded, with the most restrictive label last?
- Are the default label, justification and help link settings decided?
- Is there a deployment backlog with a date for the next review?
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 | Label specification (five or fewer) | Steady |
| Competing marking schemes still in use | Department policy review | Down |
| Open objections from legal, privacy and records | Review log | Down |
Ready-to-use text
Leadership briefing (one paragraph)
We are introducing sensitivity labels in Microsoft 365: a short set of labels, from Public to Highly Confidential, that people apply to documents and email. Most content will be labelled General automatically. Only the highest label restricts who can open a file. Labels let us protect what matters without blocking everyday work, and they are what our data loss prevention and Copilot protections rely on. We are asking for approval of the attached taxonomy and a pilot starting next quarter.
Tooltip pattern
[Label]: for [who can see it]. For example: [everyday example 1], [everyday example 2]. This label [what it does: adds a footer / restricts who can open the file].
Additional reading
Plan
Changelog
Changelog (1 version)
| Version | Date | Author | Change |
|---|---|---|---|
| 1 | Sev Derghazarian | First version. Facts checked against Microsoft Learn on 2026-10-15. |