With Microsoft Purview’s "Secure by Default" initiative from the engineering team at Microsoft, creating and publishing sensitivity labels has become simpler and more efficient. Now, you can cover all prerequisites and set up the 12 recommended labels, publishing them to end users in just a few clicks. This streamlined process means that even organisations with minimal administrative effort can achieve robust data protection.
However, if you'd like to take the recommended or manual route, that requires some extra settings and knowledge. It is for this very reason that I have written up my tips on how to properly deploy, customise and manage sensitivity labels based on the common mistakes I see people make in Microsoft Purview.
Introduction
This post isn’t a step-by-step guide for implementing sensitivity labels; instead, it’s a collection of my top 26 mistakes I often see people make when setting up their label taxonomy. These insights come from my own experience and real-world scenarios, so while they reflect what has worked (and sometimes hasn’t) for me, they might not align with everyone’s approach.
Sensitivity labels
Definition
Sensitivity Labels are metadata tags applied to documents and other content, serving as a classification mechanism for data. Sensitivity labels help define the level of protection, access controls, and handling procedures for the information they are applied to.
Types of labelling
Sensitivity labelling comes in two main forms: manual and automatic. Manual labelling requires users to manually select and assign a label to files, emails, or containers.
Automatic labelling, on the other hand, applies labels automatically based on predefined conditions, either on the client side or server side, ensuring protection without user intervention.
Labelling contexts
Sensitivity labels can be used across three primary contexts:
Item Labels: Applied to emails, meetings, files, and more recently, expanded to include assets on non-Microsoft platforms like Fabric, Azure, and AWS.
Container Labels: These are used for Microsoft Teams, Microsoft 365 Groups, and SharePoint sites.
Schematized Data Assets: Include assets like SQL databases and Azure Synapse within the Microsoft Purview Data Map.
Top 26 mistakes I see people make in Purview, and tips how to remediate those issues:
1. Not knowing the license requirements For manual sensitivity labelling, the following licenses grant user rights:
Microsoft 365: E5, A5, G5, E3, A3, G3, F1, F3, Business Premium, and OneDrive for Business (Plan 2)
Enterprise Mobility + Security: E3, E5
Office 365: E5, A5, E3, A3
Azure Information Protection (AIP): Plan 1, Plan 2
To enable automatic client-side labelling, users need a license for Azure Information Protection P2, which is included in the following plans:
Enterprise Mobility + Security: E5, A5, G5
Microsoft 365: E5, A5, G5
Microsoft 365 Compliance: E5, A5, G5, F5
Microsoft 365 Security & Compliance: F5
Microsoft 365 Information Protection and Governance: E5, F5, G5
Note: Automatic server-side labelling requires an Information Protection for Office 365 - Premium license (MIP_S_CLP2 or efb0351d-3b08-4503-993d-383af8de41e3).
2. Unsure about which permissions are needed in Purview and SharePoint
As with any administrative task, having the correct permissions within the admin portals is essential to create, publish, and manage labels. I follow the principle of least privilege, using roles that provide only the necessary permissions.
To access the admin portal for creating and managing sensitivity labels, you can assign users to these role groups:
Information Protection
Information Protection Admins
Information Protection Analysts
Information Protection Investigators
Information Protection Readers
Alternatively, users can be added to the Compliance Data Administrator, Compliance Administrator, or Security Administrator role groups.
For more details, refer to these Microsoft resources:
Once a sensitivity label is applied to a site, you need specific roles to change it in SharePoint or Teams:
For a group-connected site: Microsoft 365 group Owners
For a site that isn’t group-connected: SharePoint site admin
3. Not covering all prerequisites for sensitivity labels
To implement and support sensitivity labels across the Microsoft ecosystem, you’ll need to meet certain prerequisites. This post will outline the tasks required without diving into setup details (a separate post will cover those steps). Depending on your organisation’s structure and data needs, some items below may be optional, but I recommend leveraging all available capabilities to maximise your investment.
Prerequisites Checklist:
Ensure apps meet minimum versions required for new labelling metadata.
Use the latest Microsoft 365 Apps for enterprise.
Verify that any deployed labelling apps or solutions are on a minimum supported version of the MIP SDK.
Enable co-authoring support (enables multiple people to work on the same document simultaneously for improved real-time collaboration).
Enable container labels (to be able to configure privacy, access control, and other settings to protect labelled Teams, Microsoft 365 Groups, and SharePoint sites. Allows you to determine if for example an M365 Group is public vs. private/ if anyone or new/existing guests can join the group/site).
Enable sensitivity labels for Office files in SharePoint and OneDrive (so that your users can apply sensitivity labels in Office for the web).
Enable PDF support.
Enable labelling for schematized data assets (eg. Azure Blob Storage, Azure Cosmos, MySQL, Amazon RDS, etc.).
4. Failing to publish sensitivity labels in label policies
Simply creating labels isn’t enough - publishing them in label policies is necessary to make them available for end users.
Label policies dictate how users are granted the authority to apply sensitivity labels, whether manually or automatically through their Office apps. It's essential to clarify that label policies govern the application of labels, not the consumption of labelled content, which is controlled by the permissions embedded within each label.
Once you publish sensitivity labels, it typically takes about 24 hours for end users to see them in their Office 365 applications.
Note: In some projects, I’ve seen delays where labels took up to 3 days to appear for end users.
If it’s been 3 days, and you’ve confirmed all prerequisites, published labels to the correct user group, and ensured those users have the supported version of Office 365 - but the labels still don’t appear - consider logging a support ticket with Microsoft.
5. Not understanding encryption in sensitivity labels
Sensitivity labels with encryption ensure that protection stays with files as they move, providing consistent security whether shared internally, externally, or stored on cloud services.
However, encrypted sensitivity labels may not be fully compatible with all platforms and applications. Some third-party tools and services might lack the necessary framework to recognise or handle encrypted labels effectively. While Microsoft applications like Word, Excel, PowerPoint, and Outlook support encrypted sensitivity labels seamlessly, integrating these labels into other applications can be challenging. Users may experience issues when trying to access encrypted content in applications that don’t fully support these labels. Compatibility problems can also occur with older software versions that don’t support the latest encryption standards tied to sensitivity labels. Additionally, some cloud services and storage platforms may not completely support encrypted sensitivity labels, which can create obstacles when sharing or collaborating on encrypted files, especially with people outside your organisation.
For encrypted files and emails that need to be shared externally, remember that recipients must have the necessary permissions to access that content.
a. If you're using the "Assign permissions now" option in your encrypted label's settings, recipients need to be assigned the correct permissions in advance. It is the compliance admin's responsibility to add specific users or domains to the list here:
↓
↓
b. If you're using the "Let users assign permissions when they apply the label" option, which is commonly used in the "Specific people"/ "Recipient only" labels, then your end users will be prompted to choose recipients and specify permissions before sharing the content with people inside or outside the organisation. In this case, the responsibility to assign appropriate permissions falls on the end user who is trying to share a file or an email.
↓
↓
6. Improperly configuring label permissions and settings
Setting accurate permissions for sensitivity labels is vital, especially with encrypted content. It’s essential to define the right access for users or groups, including whether access should expire or allow offline use. Permissions are structured by roles:
Owner (formerly Co-owner): can change the label and decrypt content
Editor (formerly Co-author): can edit content but not change labels or decrypt
Restricted Editor (formerly Reviewer): limited to specific content views
Viewer: read only permission
Custom: gives you an option to customise permissions
While many permissions are straightforward, some may produce unexpected results.
Tatu Seppälä has a comprehensive series titled "Demystifying Microsoft Purview Sensitivity Label Encryption", where he goes into detail about each sensitivity label permission. I highly recommend checking out his post if you want a deeper understanding of the permissions involved.
In terms of label permissions, I generally recommend assigning Owner and Editor permissions to internal users. Lower permission levels are usually unnecessary unless you're dealing with highly specific departmental labels. Since only Owners can change the label or decrypt content, it's wise to assign this permission to key team members, ensuring they can modify or access files if the original file owner is unavailable (e.g., on leave or no longer with the organisation).
For external collaborators, I would assign Restricted Editor or Viewer permissions, and specify trusted vendor domains or use the "Authenticated Users" setting for broader access. Keep in mind that the "All users and groups in your organisation" option will include licensed contractors and other licensed external users in your tenant. To avoid unintended access, consider setting up mail-enabled security groups specifically for internal staff, as these tend to work better than distribution groups.
Finally, when setting access controls for labels where users can assign permissions themselves, such as Recipient Only labels, review the options for Outlook (where you might enforce "Do Not Forward" or "Encrypt Only") and prompts users to specify permissions in Word, PowerPoint, and Excel to ensure consistency across platforms.
7. Always allowing offline access to encrypted content
When defining offline access, avoid setting it to "Always." Instead, allow offline access for a limited time, requiring users to reauthenticate after a specified period, which strengthens security against token theft. Offline access set to "Never" may cause issues for users without a reliable internet connection (e.g., during travel).
8. Lacking clear label and label policy naming conventions
Sensitivity labels must have unique names, as duplicate names are not allowed. Sub-labels inherit the name of their parent label, which can lead to conflicts. For example, if you have Confidential/Anyone (unprotected) and attempt to create Highly Confidential/Anyone (unprotected), you may need to tweak naming, such as adding a subtle extra space, using lowercase, or changing “unprotected” to “unencrypted” for differentiation.
9. Not knowing how to avoid conflicts with MFA, Conditional Access, and encryption
Although combining multifactor authentication (MFA), conditional access, and sensitivity labels enhances security, issues can arise - particularly with Outlook desktop apps that struggle to handle MFA prompts required by conditional access. To prevent problems, exclude the Microsoft Rights Management Services app from conditional access policies that enforce MFA. This ensures Outlook can retrieve licenses without interruption, maintaining secure yet functional access to labelled content.
App name: Microsoft Rights Management Services
App ID: 00000012-0000-0000-c000-000000000000
10. Failing to handle email journaling appropriately
If using an external archiving solution for Exchange Online, ensure protection is removed from encrypted emails before they are archived. This can be configured via PowerShell to make sure emails are properly journaled without encryption issues.
I also wrote a blog about it, which you can read here.
11. Rolling out item labels too quickly
Roll out sensitivity labels in stages. Start with a smaller group of users as a proof of concept, allowing for testing and refinements. Instead of enabling labels for everyone at once, deploy them incrementally to ease adoption and ensure a smoother transition.
12. Neglecting effective user communication and training
Before launching labels organisation-wide, invest in user communication and training. Users should understand how to apply labels correctly. Provide helpful descriptions within the labels, which appear directly in apps and can aid users in choosing the appropriate label.
13. Unfamiliar with auto-labelling limits and lacking a naming structure
Auto-labelling in SharePoint and OneDrive has a limit of 100 policies per tenant, with each policy covering up to 100 locations. If you need more, create additional policies for different site sets. Naming conventions are also important to avoid duplication, as each policy and rule name must be unique. There is also and a maximum of 100,000 automatically labeled files in your tenant per day.
Existing files stored in an online repository will not be automatically labeled until they are opened, allowing a label to be applied. If an auto-labeling policy is already in place, any new file will be automatically labeled (subject to label priority and whether a manual label has already been applied - see fact number 16 for override scenarios). To label existing files, you can deploy a script to access them, download and re-upload them, or move them temporarily to a test site before returning them to their original location.
Before applying an auto-labeling policy, I strongly advise testing it in a controlled environment - whether a test tenant or a test site. Run a simulation first, and once ready, publish the auto-labeling policy. When you're confident that data is being labeled as expected, follow the same steps in your production environment: run a simulation before enforcing the policy. It’s also wise to proceed gradually. Focus on ensuring data is classified accurately to avoid the risk of mislabeling thousands of files. In the long run, a slower, methodical approach allows you to fine-tune custom data classifications and refine sensitive info types, trainable classifiers, or EDM classifiers, minimising false positives and avoiding the hassle of re-labeling or correcting mistakes.
14. Incorrectly applying parent labels in auto-labelling
Parent labels (those with sublabels) cannot be set to apply automatically or as recommendations in Office apps. If applied automatically, the label will not function properly on content. Stick with sublabels for auto-labelling needs.
15. Not understanding the difference between client-side and service-side auto-labelling
Sensitivity labels can be auto-applied either on the client side or service side:
Client-Side Auto-Labelling: Applies to emails and files as users edit, reply, or forward.
Service-Side Auto-Labelling: Labels files saved in SharePoint or OneDrive, and emails processed by Exchange Online.
Choose based on whether labelling is required during content creation (client-side) or after saving or sending (service-side), all subject to licensing.
16. Unaware of override options in auto-labelling
In cases where auto-labelling may not be accurate, override options let users manually adjust sensitivity labels.
Auto-labelling respects any manually applied labels, keeping the user’s choice intact.
It replaces automatically applied labels only if the new label has a higher priority. However, if a higher-priority label was applied manually, it won’t override it.
For a comprehensive comparison across various scenarios and override options, please refer to the table provided below, which includes details on both label settings and overrides within auto-labelling policies.
Existing label | Override with label setting: Auto-labelling for files and emails | Override with policy: Auto-labelling |
Manually applied, any priority | Word, Excel, PowerPoint: No Outlook: No | SharePoint and OneDrive: No Exchange: No by default, but configurable |
Automatically applied or default label from policy, lower priority | Word, Excel, PowerPoint: Yes* Outlook: Yes* | SharePoint and OneDrive: Yes Exchange: Yes |
Automatically applied or default label from policy, higher priority | Word, Excel, PowerPoint: No Outlook: No | SharePoint and OneDrive: No Exchange: No by default, but configurable |
*There's an exception for labels that share the same parent label.
17. Failing to deploy the Microsoft Purview browser extension
I recommend deploying the Microsoft Purview browser extension for non-native browsers like Google Chrome or Firefox to fully leverage the capabilities of Microsoft Information Protection, Data Loss Prevention, Insider Risk Management, Microsoft Defender for Cloud Apps, and Conditional Access. By deploying the extension, you gain additional control, such as the ability to block the upload of labeled files to unapproved cloud service domains.
For more information, you can refer to the official guide: Get started with the Microsoft Purview extension for Chrome.
18. Confused about a sub-label creation
Ensure a parent label exists before creating sublabels for refined data classification hierarchies.
Child labels (also called sub-labels) automatically inherit the name of their parent label. For instance, if you create a parent label named "Confidential" and then set up a child label like "Confidential/Anyone," you only need to enter "Anyone" as the name. The "Confidential" part will be automatically inherited from the parent label, so there's no need to include it again.
19. Not integrating MIP with other solutions
Microsoft Information Protection (MIP), which sensitivity labels are part of, can integrate with Data Loss Prevention, Insider Risk Management, Data Lifecycle Management and Defender for Cloud Apps, enhancing organisation-wide data protection.
20. Incorrectly using the "email label inheritance" & "default email label" options
Avoid “Same as document” as the default email label within label policy settings due to policy conflicts when publishing multiple label policies.
Set email defaults to “None” or a specific label and enable attachment inheritance for consistent protection.
21. Failing to deploy the AIP Scanner for on-prem repositories
Azure Information Protection (AIP) Scanner is a tool within AIP designed to discover, classify, label, and protect sensitive information stored in on-premises file repositories. It scans data repositories such as file servers, SharePoint on-premises, and other locations to apply AIP labels and policies.
The AIP scanner is an on-premises extension of the AIP client, available for download at the following URL at time of documentation: https://www.microsoft.com/en-us/download/details.aspx?id=53018 .
The scanner can look at on-premises network file shares and SharePoint Server repositories. It can be configured to report back only sensitive information types, or it can automatically label files too.
22. Not using AIP Super User (with PIM)
The AIP Super User, with Full Control over files containing sensitivity labels from the same tenant, serves as a last-resort access point during investigations and other critical situations. Access to the AIP Super User role is highly privileged and requires careful management.
I recommend using a Microsoft 365 group in conjunction with Entra ID's Privileged Identity Management (PIM), implementing time-limited eligibility for group membership, similar to the approach for Entra ID PIM roles. However, it’s important to note that this may not be feasible if Entra ID P2 is unavailable for administrative users.
When enabling the AIP Super User and utilising Azure PIM for this feature, be sure to follow the guidance provided here: Using Azure PIM for the AIP Super User Feature.
Securing Privileged Access: Global and SharePoint Online administrators possess similar decryption rights for content stored in SharePoint Online and OneDrive for Business (Unlock-SPOSensitivityLabelEncryptedFile). Therefore, it is strongly recommended that their privileged access be protected using similar security controls.
23. Unaware of the importance of label and label policy priority
When evaluating multiple conditions that apply to more than one label, the order of labels becomes crucial as it directly influences the label's priority and importance. Labels positioned at the lowest level signify the least sensitivity and carry the lowest priority, whereas those at the highest level indicate the highest sensitivity and hold the highest priority. In the context of auto-labelling policies on the service side, the label with the highest order number takes precedence. On the client side, when multiple sublabels from the same parent label match the conditions, the behaviour varies depending on whether the file is labelled or unlabelled. If the file is unlabelled, the highest order sublabel configured for automatic labelling is selected. Conversely, if the file is already labelled, no action is taken, and the existing sublabel remains unchanged.
24. Unfamiliar with PDF labelling and encryption
You can apply the same sensitivity labels to PDF files as you do with Office 365 files, like Word, Excel, PowerPoint. However, there are some limitations to it.
PDF conversions inherit labels and encryption where applied. Label functionality extends across Microsoft Office apps and supported scenarios on Windows, iOS, Android, and the web.
PDF limitations include no support for Print-to-PDF with encryption, and some legacy labels may require re-uploading for SharePoint/OneDrive recognition.
Nikki Chapple has an excellent blog that guides you through using sensitivity labels with PDF files, covering the entire process step-by-step. Check it out here.
25. Unaware of label limitations
There are several limitations and caveats to sensitivity labels. The key ones include:
Existing files encrypted with older labels from the Azure portal won't automatically get sensitivity labels. Re-uploading them to SharePoint or OneDrive is required to apply labels.
Office for the web cannot apply labels with user-defined permissions. Files with labels set for access expiration or Double Key Encryption cannot be processed by SharePoint and OneDrive and won’t display labels.
Print and screen capture aren't supported for encrypted documents in Office for the web, but clipboard copying is restricted.
Offline or sleep mode may cause save issues for desktop and mobile apps. Files encrypted with certain methods (e.g., Double Key Encryption) can't be opened in Office for the web.
Labels in other languages aren't supported. Deleting labels in SharePoint or OneDrive removes labels and encryption, but files stored outside these services remain encrypted.
To learn more, please refer to the official Microsoft documentation.
References:
26. Failing to set the default sensitivity label for document libraries
Credit to Nikki Chapple for suggesting this, as number 26!
To apply a default sensitivity label to a SharePoint document library, you need higher licensing, such as Microsoft 365 E5, to access this feature. The default sensitivity label for a document library is not automatically linked to the container’s sensitivity label (e.g., a Microsoft Teams site). This means if you assign a confidential label to a Team for managing external sharing and guest access, it won’t automatically apply the same label to the associated document library. You’ll need to manually configure the default sensitivity label for the document library in a separate step to ensure the appropriate protection is applied to the documents stored there.
References: