5.1 Roles and Permissions for Sensitivity Labels

The first sensitivity-label bullet on the July 28, 2026 SC-401 outline is Implement roles and permissions for administering sensitivity labels. That skill is about who may open the label designer in the Microsoft Purview portal, not about who may click Confidential on a Word document. Microsoft's get-started article (updated 2026) states the permissions are required only to create and configure sensitivity labels and their label policies. They are not required to apply labels in apps or services.

Work in the current portal names. Sign in at the Microsoft Purview portal. Role groups live under Settings > Roles and scopes > Role groups. The labels themselves live under Solutions > Information Protection > Sensitivity labels. Microsoft recommends roles with the fewest permissions and specifically warns against using Global Administrator for day-to-day labeling work.

Role versus role group

A role is a named bundle of tasks. The role you will see on least-privilege exam items is Sensitivity Label Administrator: view, create, modify, and remove sensitivity labels. The read-only counterpart is Sensitivity Label Reader. Those names are roles, not the built-in groups you pick from a dropdown on day one.

A role group is a container of roles plus members. Microsoft ships Information Protection groups that already mix label work with DLP and classifiers. You can also Create role group, add only Sensitivity Label Administrator, and put the labeling operators in that custom group. To create or even view role groups, the operator needs Role Management, which ships in Organization Management, or must be a Global Administrator. Do not give every label designer Role Management.

Built-in Information Protection groups

Microsoft's get-started page lists these role groups as the Information Protection set you can use:

Exam trap: the get-started article lists Analysts, Investigators, and Readers next to Admins because they are the Information Protection family. Listing is not permission to create a label. Read the flyout description on the role group, or the Defender/Purview role-group table: Admins write labels; Analysts and Investigators read the configuration and work alerts; Readers see reports.

Broader compliance and security groups

Microsoft also documents that you can add users to Compliance Data Administrator, Compliance Administrator, or Security Administrator.

• Compliance Administrator is a wide compliance role group. It includes Information Protection Admin among many other roles (DLP, retention, holds, communication compliance, and more). It will let someone manage labels, and it will also let them manage a large slice of Purview they may not need.
• Compliance Data Administrator includes Sensitivity Label Administrator plus Information Protection Admin/Analyst/Reader and several preservation and DLP roles. Still broader than a custom label-only group.
• Security Administrator inherits from the Microsoft Entra Security Administrator role. The Purview copy of this group includes Sensitivity Label Administrator. Editing the Purview copy of Security Administrator changes only security and compliance areas in these portals, not every Entra capability — but it is still the wrong answer when the stem asks for least privilege.

Organization Management can also administer labels (it includes Sensitivity Label Administrator). Global admins are automatically members of Organization Management. Microsoft's permission docs tell you not to treat that as a labeling job description.

If the item says "Contoso wants one admin to create sensitivity labels and nothing else," the best fit is a custom role group with Sensitivity Label Administrator. If the same person already owns DLP policies and classifiers, Information Protection Admins is the built-in match. If the person must also run Content explorer and DLP investigations, that is the wider Information Protection group — still not Global Administrator.

What these permissions do not cover

Label-admin rights do not replace every neighboring permission:

• Applying a published label in Office, Teams, SharePoint, or Power BI is an end-user action. The user needs a work or school account, a license that includes labeling, and a label policy that publishes the label to them. They do not need Sensitivity Label Administrator.
• Enabling sensitivity labels for Microsoft 365 groups is a Microsoft Entra configuration plus the Security & Compliance PowerShell cmdlet Execute-AzureAdLabelSync. That enablement is a tenant prerequisite for container labels, not a substitute for Purview label-admin roles.
• Azure Rights Management super users can decrypt content for eDiscovery and recovery. That is an encryption-service role, not a Purview label designer role.
• Specific features (SharePoint/OneDrive labeling, co-authoring on encrypted files, Defender for Cloud Apps labeling) document extra permissions in their own articles. Do not assume Information Protection Admins covers every connected admin center.

Admins who manage labels also need a license that includes Microsoft Purview Information Protection labeling. Microsoft publishes feature-level licensing in the Purview service description and the related PDF; the exam does not ask you to invent a dollar amount or a secret SKU code.

Administrative units

Sensitivity labels support administrative units configured in Microsoft Entra ID. Two layers matter:

1. Admin scoping. Edit an Information Protection role group, select a member, and use Assign admin units. That admin can then manage only users in those units.
2. Policy scoping. When you create a sensitivity label policy or an auto-labeling policy, you can select administrative units. For Exchange and OneDrive, only users in those units are eligible. For SharePoint, only sites in those units are eligible.

Protection policies (Fabric/data-map protection policies) do not support administrative units. Microsoft documents that AU membership accuracy is an Entra dependency. The point of AUs is least privilege; a side effect is that you can publish a France-only label policy without enumerating every French group by hand.

Worked example: your account is in Information Protection Admins and is assigned AUs for France, Germany, and Spain. You create a label policy and see only those three units. You select France and leave users and groups at the default of all. The policy targets users in the France AU as Entra membership changes. You did not need Global Administrator, and you did not publish the label to Germany by accident.

Exam traps

• Global Administrator is required to create labels. It works. It is not least privilege. Microsoft's labeling article says to minimize Global Administrator.
• Information Protection Analysts create labels because they are in the Information Protection family. They have view-only access to label definitions.
• Help-desk staff need Sensitivity Label Administrator to apply Confidential in Outlook. Application in apps does not use that role.
• Role Management belongs on every label admin. Role Management is for people who create role groups, not for people who create labels.
• Confusing Compliance Administrator with Information Protection Admins. Both can administer labels. Compliance Administrator is the wide compliance hammer; Information Protection Admins is the information-protection hammer; Sensitivity Label Administrator is the scalpel.

When you can name the portal path, the difference between the Information Protection role groups, the Sensitivity Label Administrator role, and the fact that end users apply labels without those rights, you have this blueprint bullet.