# Design a sensitivity label taxonomy people use - URL: https://m365playbooks.com/playbooks/design-a-sensitivity-label-taxonomy-people-use/ - Topic: Sensitivity labels (Program) - Product: Purview - Stage: Plan - Last reviewed: October 15, 2026 - Version: 1 - Written by: Sev Derghazarian ## 1. 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. ## 2. 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. ## 3. Key activities ### Prerequisites 1. **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. Who: Information security lead. Produces: A one-page inventory of the obligations the labels must meet. 2. **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. Who: Purview admin with the information security lead. Produces: A short summary of where sensitive information lives and who handles it. 3. **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. Who: Purview admin. Produces: Confirmed licences, admin roles, and a list of devices that need Microsoft 365 Apps. ### Decisions 4. **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. Who: Taxonomy owner. Produces: An agreed list of main labels and sublabels. 5. **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. Who: Taxonomy owner with legal. Produces: A protection setting for every label, with the reason for each. 6. **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. Who: Taxonomy owner. Produces: Agreed label policy settings. 7. **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. Who: Executive sponsor. Produces: A named taxonomy owner and reviewers. ### Pilot configuration 8. **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. Who: Communications lead with the information security lead. Produces: Revised label names and tooltips, and the test results. 9. **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. Who: Communications lead. Produces: A published labelling guide ready to be linked from the label policy. ### Production configuration 10. **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. Who: Taxonomy owner. Produces: An approved label specification. 11. **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. Who: Taxonomy owner with the Purview admin. Produces: A deployment backlog and a review date. 12. **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._ ## 4. Approval and readiness 1. **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. 2. **Test with people from several departments** (Change: 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. 3. **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. 4. **Approve with the sponsor** (Change: 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. 5. **Tell people what's coming** (Change: 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. ## 5. Common challenges - **If you** Copy an existing classification scheme one-to-one. What tends to happen: People face ten or more labels, pick the first one that seems close, and labelled data stops meaning anything.. A better approach: Keep five or fewer main labels and map the old categories to them in the labelling guide. - **If you** Encrypt most labels to be safe. What tends to happen: Sharing with partners and co-editing get harder, so people lower labels just to get work done.. A better approach: Encrypt only the top tier and protect the rest with visual markings and DLP. - **If you** Name labels after internal policy codes. What tends to happen: People guess, and the same document gets three different labels in three departments.. A better approach: Use plain names, write tooltips with everyday examples, and test both with the people who will use them. - **If you** Make labelling mandatory with no default. What tends to happen: People are interrupted on every save and send, and choose whatever closes the prompt fastest.. A better approach: Set a non-encrypting default and ask for a justification only when someone lowers or removes a label. - **If you** Let the taxonomy belong to IT alone. What tends to happen: Labels drift from legal and records obligations, and nobody can approve a change.. A better approach: Name an owner in information security, with records, privacy and legal as reviewers. ## 6. 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? ## 7. Success measures Capture a baseline before you start, or you won't be able to show the change. - Testers choosing the intended label (Where you see it: Naming test results; Good direction: Up) - Main labels in the taxonomy (Where you see it: Label specification (five or fewer); Good direction: Steady) - Competing marking schemes still in use (Where you see it: Department policy review; Good direction: Down) - Open objections from legal, privacy and records (Where you see it: Review log; Good direction: 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. **Ready-to-use text: 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]. ## 8. Additional reading **Plan:** - [Learn about sensitivity labels](https://learn.microsoft.com/en-us/purview/sensitivity-labels) - [Get started with sensitivity labels](https://learn.microsoft.com/en-us/purview/get-started-with-sensitivity-labels) - [Learn about the default sensitivity labels and policies](https://learn.microsoft.com/en-us/purview/default-sensitivity-labels-policies) - [Introduction to secure by default with Microsoft Purview](https://learn.microsoft.com/en-us/purview/deploymentmodels/depmod-secure-by-default-intro) - [Microsoft Purview service description](https://learn.microsoft.com/en-us/office365/servicedescriptions/microsoft-365-service-descriptions/microsoft-365-tenantlevel-services-licensing-guidance/microsoft-purview-service-description) **Configure:** - [Create and publish sensitivity labels](https://learn.microsoft.com/en-us/purview/create-sensitivity-labels) - [Apply encryption using sensitivity labels](https://learn.microsoft.com/en-us/purview/encryption-sensitivity-labels) **Monitor:** - [Deploy an information protection solution with Microsoft Purview](https://learn.microsoft.com/en-us/purview/information-protection-solution) ## Changelog - Version 1, 2026-10-15, Sev Derghazarian: First version. Facts checked against Microsoft Learn on 2026-10-15.