6.1 Configure Publishing Policies for Sensitivity Labels
Key Takeaways
- Sensitivity labels are published to users and groups in Microsoft Entra ID, not to locations the way retention labels are.
- Completing Create policy in the Microsoft Purview portal publishes the policy immediately; there is no separate republish action.
- Allow up to 24 hours for label and policy changes to propagate; group-membership scenarios can take 24–48 hours.
- Justification for removing or replacing a label with a lower-priority label applies to files, emails, and meetings, not to Teams or SharePoint containers.
- A user in multiple publishing policies receives the union of labels; conflicting settings use the policy with the highest order number.
6.1 Configure Publishing Policies for Sensitivity Labels
Quick Answer: Creating a sensitivity label is not enough. You must add it to a label policy (publishing policy) and assign that policy to users or groups. Completing the Create policy wizard in the Microsoft Purview portal publishes the policy immediately—there is no extra republish button.
Labels versus publishing policies
Sensitivity labels hold the classification itself: the name users see, the scope (files, emails, groups and sites, meetings, and related assets), encryption, and content markings. A publishing policy is the distribution object. It decides which people can select those labels in supporting apps, and it attaches policy-level settings such as a default label, mandatory labeling, and a justification prompt when someone downgrades a label.
Until a label is in a published policy, it does not appear for users to choose in Office, Teams, SharePoint, Outlook, or Power BI. That is different from retention labels, which you publish to locations such as Exchange mailboxes or SharePoint sites. Sensitivity labels are published to users and groups in Microsoft Entra ID. Apps that support sensitivity labels then show those labels to the assigned people.
Microsoft’s operational guidance is to keep the number of publishing policies small. Create additional policies only when a population needs different labels or different policy settings—for example, a Highly Confidential label published only to Legal, or a stricter default label for Finance. It is common to run one organization-wide policy plus a small number of higher-priority departmental policies.
Some tenants receive default labels and a default label policy automatically. Even if you already created labels, review that default configuration; you can recreate the same settings manually to accelerate a first deployment. Do not treat those defaults as a substitute for designing scopes, encryption, and who should see each label.
Where you create and edit a publishing policy
In the Microsoft Purview portal, go to Solutions > Information Protection > Publishing policies. On the Label policies page, select Publish label to start Create policy.
The wizard typically walks through these choices:
- Select the sensitivity labels to include.
- Name the policy (and optionally describe it).
- Assign administrative units if your organization uses them in Microsoft Entra ID. An account that is itself scoped to administrative units must select one or more units. If you are not restricting the policy, keep Full directory.
- Choose the users and groups who receive the labels.
- Configure the policy settings that match the scopes of the labels you selected.
Policy settings are scope-aware. If you selected only labels scoped to Files & other data assets, you will not see container settings such as Apply this label by default to groups and sites or Require users to apply a label to their groups and sites. Labels configured for Microsoft Purview Data Map assets (preview) have no associated publishing policy settings.
Completing Create policy automatically publishes the policy. To change a live policy, edit it. There is no separate publish or republish control. If you edit a label that is already published, you do not add it to a new policy for the same users—the updated label settings replicate to those users and services.
On the Sensitivity labels page, do not select Publish labels (or Publish label while editing a label) unless you actually need a new policy. Extra policies are how conflicting defaults and mandatory settings creep into a tenant.
You can also create and maintain policies with Security & Compliance PowerShell (New-LabelPolicy, Set-LabelPolicy), including advanced settings that the portal does not expose. Built-in labeling and the Microsoft Purview Information Protection client each document their own advanced settings; do not assume every PowerShell key applies to both.
Who you can publish to
A publishing policy can target:
- Individual users
- Email-enabled security groups
- Distribution groups
- Microsoft 365 groups, including groups with dynamic membership
The default is all users in the organization. Use extra policies when a subset needs additional labels or different policy settings.
Everyone in the same tenant can see the name of a sensitivity label that is already applied to content, even if that label was never published to them. They do not see sensitivity labels from other organizations. That matters for shared files: unpublishing a label hides it from the picker, but people can still recognize an applied name on content they can open.
Default label, mandatory labeling, justification, and help
These four policy settings show up constantly in SC-401 scenarios.
Default label. You can specify a default for unlabeled documents and Loop components and pages, emails and meeting invites, new containers (after you enable sensitivity labels for containers), and Power BI content. You may use one label for all five item types or different labels. Users can change a default to better match the item. A default is useful as a baseline of protection, but without training it produces inaccurate labels. Microsoft specifically warns that choosing a label that applies encryption as the default for documents is usually a poor idea, because many organizations share with external users who may lack supporting apps or an account that can be authorized. If you use sublabels, do not configure the parent label as a default—parent labels cannot be applied to content.
Justification for changing a label. For files, emails, and meetings—not for groups and sites used by Teams and SharePoint—a user who removes a label or replaces it with a lower-priority label must provide a justification. Example: a document labeled Confidential (order number 3) is changed to Public (order number 1). In Office apps the prompt is triggered once per app session. With the Microsoft Purview Information Protection client, the prompt is triggered for each file. Administrators can read the justification together with the label change in activity explorer.
Mandatory labeling. Require a label before users can save files, send emails or meeting invites, create new groups or sites, or use unlabeled content in Power BI. For documents and emails, the required label can be chosen manually, applied automatically from a condition, or assigned by the default-label setting. For containers, a label must be assigned when the group or site is created. Mandatory labeling increases coverage, but without training it also increases inaccurate labels. Unless you also set a corresponding default label, users see frequent prompts.
Custom help link. A Learn More URL can appear after the list of available sensitivity labels in Office apps when users are unsure which label to use.
| Policy setting | Where it applies | Exam trap |
|---|---|---|
| Default label | Documents and Loop pages, emails and meeting invites, new containers, Power BI content | Do not default a parent label, and avoid an encrypting default on documents unless you have a sharing plan |
| Justification for change | Files, emails, and meetings | Does not apply to Teams / SharePoint container labels |
| Mandatory labeling | Files, emails, meetings, new groups or sites, Power BI | Pair it with a default label or users hit prompts on every save or send |
| Help URL | Office apps | Shown after the published label list |
| Policy order | Conflicting settings for the same user | Highest order number (bottom of the list) wins |
Policy priority when a user is in more than one policy
Label policies appear as a list. The policy at the top has the lowest order number and the lowest priority. The policy at the bottom has the highest order number and wins when settings conflict.
A publishing policy is a package of (1) a set of labels, (2) the users and groups assigned, and (3) the scope plus policy settings for that scope. A user included in multiple policies receives all of the sensitivity labels from those policies. If two assigned policies disagree on a setting—different default labels, different mandatory flags, different justification behavior—the setting from the policy with the highest order number is applied. Highest priority wins per setting, not by merging.
A typical design places an organization-wide “standard” policy at order 0, an IT policy at order 1, and a Legal policy at order 2. If a user is in both IT and Legal, Legal’s conflicting settings apply. If you do not see the behavior you expect, reorder policies with Move up / Move down on the Label policies page before you assume the labels themselves are wrong.
How long publication takes
Allow 24 hours for labels and label policy settings to propagate through the services. Microsoft calls out many external dependencies with their own timing cycles, so wait that period before spending time troubleshooting a change you just made. Some scenarios are faster: new and deleted sensitivity labels for Word, Excel, and PowerPoint on the web can replicate within the hour. Configurations that depend on populating a new group, group membership changes, or network replication latency can take 24–48 hours.
Unpublish versus delete
In production you rarely delete labels. During testing you might remove a label from a policy or delete the label. Those are not the same operation.
Removing a label from a policy is the lower-risk action, and you can add the label back later. You cannot delete a label that is still in a label policy.
After you unpublish a label, users no longer see it to select in Office apps once the policy refreshes. Labels already applied stay on the content or container. Users of built-in labeling in desktop Word, Excel, and PowerPoint still see the applied name on the status bar. An applied container label continues to protect the Teams or SharePoint site.
Deleting a label is different. If the label applied encryption, the underlying protection template is archived so previously protected content can still be opened. Because of that archived template, you cannot create a new label with the same name. Do not delete the archived protection template with PowerShell unless you are sure you will never need to open content encrypted with it.
For documents in SharePoint or OneDrive after you have enabled sensitivity labels for Office files, opening in Office for the web after a delete may no longer show the applied label, and the Sensitivity column may no longer display the name. If the deleted label applied encryption and the service can process the contents, encryption can be removed. Files stored outside those services, and emails, keep label metadata, but apps can no longer map the label ID to a display name; encryption remains if the label had encrypted the item. For containers, deletion removes the label and stops enforcing its settings, typically 48–72 hours for SharePoint sites and often faster for Teams and Microsoft 365 Groups. Until that process finishes, users might be unable to open content that the container label previously protected. Deleted labels can show as GUIDs in content explorer and activity explorer because the GUID-to-name mapping is gone.
As with all label changes, unpublishing or deleting takes time to replicate. Plan maintenance windows around the 24-hour (and, for container deletion, multi-day) windows rather than expecting an instant cutover.
Sensitivity label publishing policies are assigned to which of the following?
A publishing policy is configured to require a justification when users change a sensitivity label. When does that prompt apply?
A user is assigned two publishing policies that specify different default sensitivity labels. Which default label does the user receive?