A sensitivity label should answer a practical question: how should this information be handled? In Microsoft Purview, labels can classify content and, when configured, apply controls such as encryption and content markings. They can also control supported settings for collaboration containers, including Microsoft Teams, Microsoft 365 groups and SharePoint sites. The label name communicates intent; its configuration determines what actually happens.
Part 2 of the Microsoft Purview Deep Dive moves from the data security and compliance map to implementation. The objective is not to publish the largest possible label catalogue. It is to establish a classification model that people understand, apply protection where justified, and validate the results before expanding deployment. Treat this as a joint information governance, security and workplace delivery project—not simply a portal configuration exercise.
1. Design the classification model before creating labels
Begin with information handling requirements rather than product settings. Identify the information your organisation creates, its intended audiences, the consequences of inappropriate disclosure and the workflows that must remain possible. Use representative documents and emails from business teams to test whether the proposed categories are understandable.
An illustrative starting point is Public, Internal, Confidential and Highly Confidential. These names are design examples, not mandatory Microsoft categories. Each label needs a plain-language definition, an accountable business owner and examples of when it should—and should not—be used. Define handling expectations separately from the technical controls so that stakeholders can distinguish policy intent from enforcement.
Public: information approved for unrestricted distribution. Applying the label does not itself publish the information or grant access.
Internal: routine business information intended for internal use. Decide explicitly whether this is classification only or whether technical restrictions are required.
Confidential: information requiring a defined business audience, with protection selected according to collaboration needs.
Highly Confidential: information requiring tightly controlled access and additional validation of recipients and supported workflows.
Use sublabels only when they represent a meaningful handling distinction. For example, separate employee-only and approved-partner protection options may be useful under Confidential. A parent label with sublabels acts as a grouping rather than a selectable label for content. Excessive nesting or near-identical choices makes the classification decision harder.
Order labels deliberately. Microsoft Purview uses label priority in behaviours such as automatic labelling, and the ordering identifies lower and higher sensitivity. A label's position does not make its protection stronger: a highly ranked label without encryption remains unencrypted. Review ordering and configuration together.
2. Separate content labels from container controls
Label scope determines where a label can apply and which settings are available. Decide whether each label is intended for files and other supported content, collaboration containers, or both. Review the scopes available in your tenant rather than assuming that every label should appear everywhere. Additional capabilities, such as meeting protection, have their own application and licensing requirements.
For files and emails, labels can provide classification metadata, configured content markings and encryption. Support varies by application, platform, file type and feature. Build your compatibility requirements around the actual versions and clients people use, including Office desktop applications, Office for the web and mobile applications where relevant.
For Microsoft Teams, Microsoft 365 groups and SharePoint sites, sensitivity labels can configure supported container settings such as privacy and external user access. Some controls depend on other services or prerequisites. For example, a label-based authentication context requires the associated Microsoft Entra Conditional Access configuration; the label does not create that access policy.
The essential boundary is that a container label does not automatically label or encrypt the files inside the container. A Confidential site and a Confidential document are separate protection decisions. Design both layers intentionally: container settings govern the collaboration space, while file labels govern the supported content itself.
If labelled files will be stored in SharePoint and OneDrive, review and enable the documented sensitivity label integration as required. This allows those services to process supported labelled and encrypted files. It is a separate prerequisite from publishing labels to users, and it does not remove every limitation associated with encryption.
3. Configure protection around real collaboration
Classification and encryption are not interchangeable. A label can classify content without encrypting it, which can be a useful initial deployment choice. Conversely, a label configured with encryption affects who can open content and which actions they can perform. Do not add encryption merely because a label sounds sensitive; map it to an approved access requirement.
For labels that encrypt files and emails, determine whether administrators should assign permissions in the label configuration or whether users should assign permissions when applying the label. Administrator-defined permissions provide a consistent audience and rights model. User-defined permissions support more variable sharing requirements but place more responsibility on the person applying protection.
Define the permitted audience using maintained identities and groups. Confirm who owns membership and how changes are governed.
Specify required usage rights. Viewing, editing, copying and printing are different permissions; test the intended combinations rather than relying on the label name.
Evaluate content expiry and offline access settings where applicable. Validate their impact on travel, intermittent connectivity and long-running business processes.
Test external collaboration with actual partner identities and the applications those partners use. Successful internal testing does not establish external compatibility.
Content markings, including supported headers, footers and watermarks, can reinforce handling expectations. They are visual cues, not access controls, and their availability differs between files, emails and applications. Check placement, readability and interaction with existing document templates before enabling them broadly.
Include co-authoring, search, document previews and business integrations in protection testing. SharePoint and OneDrive support important collaboration scenarios for supported encrypted files, but restrictions still depend on encryption configuration and feature support. Processes that download, transform or generate documents need particular attention because they may not handle protected files in the same way as Office applications.
4. Publish through policies, not assumptions
Creating a label and publishing it are separate tasks. Labels define classification and protection settings. Label policies publish selected labels to selected users and configure behaviours such as default labels, mandatory labelling and justification for removing a label or lowering its classification.
Use the Microsoft Purview portal to create the initial labels and publish them to a controlled pilot group. Confirm the required administrative permissions and user licensing before deployment. Manual labelling, automatic labelling and advanced protection features do not all have identical entitlement requirements. Validate the specific capabilities you intend to use against Microsoft's current licensing guidance.
Choose defaults carefully. A default label can reduce effort, but it is not evidence that content has been assessed correctly. Mandatory labelling requires a classification decision in supported scenarios; it does not guarantee an accurate decision. Requiring justification for downgrading or removing labels supports accountability, but it should not be mistaken for a universal prohibition on those actions.
Document what happens when users are included in multiple publishing policies. Labels can be made available through multiple policies, while conflicting policy settings are resolved through policy priority. Review this explicitly for users who belong to both a broad organisational group and a specialist team.
Allow for policy propagation and client refresh. Label changes are not necessarily visible immediately; Microsoft documents that publication changes can take up to 24 hours. Include this interval in test scheduling before treating inconsistent client behaviour as a configuration failure.
5. Pilot, validate and expand in controlled stages
Start with a pilot that represents different working patterns: desktop and web users, mobile users where required, external collaboration, shared workspaces and teams handling sensitive information. Give participants a short decision guide using their own document examples. Ask them to explain why they selected a label; this exposes ambiguous definitions more effectively than checking whether a label was applied.
Use the following sequence as a practical deployment plan:
Baseline: inventory existing classification practices, relevant application versions, encryption workflows and SharePoint or OneDrive prerequisites. Identify the business owner for every proposed label.
Classification pilot: publish a small label set and validate visibility, descriptions, defaults and user decisions. Where appropriate, begin with classification-only labels to isolate usability issues.
Protection pilot: introduce the agreed encryption and container controls. Test successful access and expected denial with authorised and unauthorised accounts.
Workflow validation: test supported sharing, co-authoring, downloads, mobile access, offline use and business integrations. Record the application, identity, location and result for each test.
Controlled expansion: extend publication to successive groups only after resolving material failures. Introduce mandatory labelling or broader automation when support readiness and classification quality justify it.
For an administrative inventory, the following read-only command lists configured labels. Run it in an established Security & Compliance PowerShell session with appropriate permissions. It shows label configuration objects; it does not prove that a particular user's application has received the publishing policy.
Get-Label | Format-List Name, DisplayName, GuidKeep automatic labelling as a separate design decision. Client-side automatic or recommended labelling in supported Office applications differs from service-side auto-labelling for content in supported Microsoft 365 locations. Confirm licensing, supported conditions and workload behaviour before selecting either approach. Validate detection against representative content rather than assuming that a sensitive information type always identifies the intended business category.
Define recovery before expansion. Adjusting a publishing policy is not the same as removing labels or decrypting existing documents. An encrypted file does not become unencrypted simply because its label is no longer published to a user. Document how authorised staff will investigate access failures, correct misclassification and handle already protected content.
6. Rollout readiness checklist
Definitions: every selectable label has a clear purpose, business owner and realistic examples.
Scope: file and email protection is distinguished from Microsoft Teams, Microsoft 365 group and SharePoint site controls.
Access: encryption permissions, external identities and offline behaviour have been tested with representative accounts.
Compatibility: required Office clients, SharePoint and OneDrive behaviour, and business integrations have passed documented tests.
Publishing: pilot membership, overlapping policies, defaults, mandatory labelling and downgrade justification have been reviewed.
Operations: licensing, administrative permissions, support guidance, change ownership and recovery procedures are confirmed.
7. Conclusion: make labels dependable before making them universal
A successful sensitivity label rollout creates a dependable connection between business classification and technical handling. Keep the initial taxonomy understandable, separate container controls from content protection, and test encryption against actual collaboration patterns. Expand only when users can make sensible decisions and support teams can resolve predictable failures.
Labels also provide classification context that Microsoft Purview Data Loss Prevention policies can use. They do not automatically create those policies. Part 3 will build on this foundation by examining DLP for Exchange, SharePoint and Microsoft Teams, with controls designed around where information is shared and how it is used.
Microsoft Learn: Learn about sensitivity labels
Microsoft Learn: Create and configure sensitivity labels and their policies
Microsoft Learn: Manage sensitivity labels in Office apps
Microsoft Learn: Enable sensitivity labels for files in SharePoint and OneDrive
Originally published on Solution Savy. Need help with this? Book a consultation.
