9.2 Roles and Permissions for Data Loss Prevention

The second DLP bullet on the July 28, 2026 outline is Implement roles and permissions for data loss prevention. This is a Microsoft Purview portal problem under Settings > Roles and scopes > Role groups, not an Exchange mail-flow permission and not a reason to hand out Global Administrator. Microsoft's permissions article (updated 2026-07-30) repeats the least-privilege warning: minimize Global Administrator; grant only the tasks the person must perform.

A role is a named bundle of tasks. DLP Compliance Management is the role that views and edits settings and reports for DLP policies. View-Only DLP Compliance Management views those settings and reports. A role group is a container of roles plus members. You usually add people to a built-in group. You can also Create role group, add only DLP Compliance Management, and that is the scalpel when the stem says "DLP policies and nothing else." To view or edit role groups at all, the operator needs Role Management (shipped with Organization Management) or Global Administrator. Do not put Role Management on every DLP operator.

Who can create unrestricted DLP policies

Microsoft's Create and deploy DLP policies article (updated 2026-06-26) lists the role groups whose members can create and deploy policies:

• Compliance administrator
• Compliance data administrator
• Information Protection
• Information Protection Admin
• Security administrator

Those names are the Purview role groups (Information Protection Admin is the admin-shaped Information Protection group). They are also the groups Microsoft's Q&A guidance cites when a Global Administrator still cannot open DLP > Policies: Entra directory roles alone are not a substitute for a Purview DLP-capable group. Put the account in one of the groups above, then retry.

Granular roles Microsoft lists next to that create list: DLP Compliance Management, Information Protection Admin, Information Protection Analyst, Information Protection Investigator, and Information Protection Reader. Granular role groups: Information Protection, Information Protection Admins, Information Protection Analysts, Information Protection Investigators, and Information Protection Readers. Read the flyout. Being in the Information Protection family is not permission to write a policy.

DLP Compliance Management versus Compliance Administrator versus view-only

Memorize the Defender / Purview role table wording:

Exam trap: Compliance Administrator includes DLP Compliance Management, so it can create policies. The stem that asks for least privilege wants DLP Compliance Management on a custom role group, or Information Protection Admins when labels travel with DLP. The stem that asks who can see policies but not change them wants View-Only DLP Compliance Management, Information Protection Analysts/Investigators/Readers (view-only on definitions), or Global Reader — not Compliance Administrator.

Information Protection Analysts can work the DLP alerts dashboard and activity explorer. That is operations. It is not Create policy. If the item mixes "investigate DLP alerts" with "do not let them edit the HIPAA policy," Analysts or Investigators are the group; DLP Compliance Management is the wrong gift.

Microsoft Entra roles in the Purview portal

Roles and scopes also lists Microsoft Entra roles. Compliance Administrator and Compliance Data Administrator in Entra map to the Purview groups of the same name. Security Administrator maps to Security Administrator. Global Reader maps to Global Reader. Global Administrator maps into Organization Management and more. Use Entra when the person's job is already that directory role. Do not stack Entra Compliance Administrator on top of a carefully scoped Purview group and assume the scope survives.

Microsoft documents role precedence in the Purview permissions article:

• Assign Compliance Administrator in Entra and a scoped Compliance Administrator in Purview, and the Entra role wins. Effective access is unscoped. Administrative units do not apply.
• Assign Global Reader in Entra and a scoped DLP Compliance Management assignment in Purview, and overlapping features or APIs grant unscoped access to that data.
• When both scoped Purview assignments and Entra roles exist, Entra always takes precedence for overlapping capabilities.

That is the multinational exam item: you built France-only DLP admins, then someone added Entra Compliance Administrator "just in case," and those admins can suddenly see Germany's policies.

Privileged Identity Management (PIM) for Groups can make an Entra security group eligible for just-in-time membership, and you can assign that group to a Purview role group. Direct user assignments to Purview role groups are not activated the same way as PIM for Entra roles. Temporary permissions on Purview role groups can expire automatically: administrators set an expiration between one day and two years. Built-in and custom groups support this except eDiscovery Administrator and eDiscovery Manager. There is no expiry reminder; My Permissions shows the latest expiration across assignments.

Copilot DLP policies add two more names you may see: Microsoft Entra AI Administrator and Purview Data Security AI Admin / Data Security AI Admins, alongside the usual Compliance / Information Protection / Security Administrator groups. Least privilege for Copilot DLP is still not Global Administrator.

Administrative units

Administrative units are created in Microsoft Entra ID (P1 or P2). Purview then lets you Assign admin units on supported role-group members. DLP is a supported solution: role groups and DLP policies. Restricted administrators pick one or more of their units as the initial policy scope. Unrestricted administrators can target the entire directory or optionally pick units.

Microsoft's DLP policy reference splits administrators like this:

• Unrestricted administrator: create and scope policies to the whole organization, edit all DLP policies, create AU-scoped policies, view all DLP alerts and events.
• Administrative unit restricted administrator: must still belong to a DLP-capable role or role group; can create and scope policies only to assigned units, edit only those policies, and view alerts and events only from those policies.

After you assign units to a member, that restricted admin cannot see or edit existing unscoped policies. Those policies keep working; unrestricted admins still see them. Historical activity explorer and alert data for the whole tenant also stays with unrestricted admins. Going forward, the restricted admin sees data for their units only. If you are an AU-restricted admin, the DLP alerts dashboard shows only your unit's alerts.

Assign admin units requires the Role management role. Supported built-in groups for AU assignment include Compliance Administrator, Compliance Data Administrators, Global Reader, the Information Protection family, Organization Management, Security Administrator, Security Operator, and Security Reader. Custom role groups can always assign admin units.

Location support is not universal. Exchange, SharePoint, OneDrive, Teams, and Devices support administrative units. Fabric and Power BI, on-premises repositories, Instances, managed/unmanaged cloud apps, and Microsoft 365 Copilot and Copilot Chat do not. You cannot promise a France-only Copilot DLP policy via admin units. SharePoint sites can be associated to an AU in Purview; a DLP policy assigned to that AU then applies to all sites in the unit, with no extra site include/exclude. Site queries can take up to five days to populate — wait before you attach the policy. Microsoft Defender XDR supports administrative units for DLP (not for Insider Risk Management) and documents a ceiling of 100 administrative units.

Worked example: Adele is in Information Protection Admins with the France AU assigned. She can create a HIPAA DLP policy for France users and see France alerts. She cannot open the tenant-wide credit-card policy that an unrestricted Compliance Administrator created last year. If you also grant Adele Entra Compliance Administrator, Microsoft's precedence rule makes her unscoped: the France AU no longer hides Germany.

What these permissions do not replace

Purview DLP roles do not replace Exchange admin center permissions for mail-flow rules. They do not onboard devices (endpoint DLP has its own permission list in that chapter). They do not make Adaptive Protection, rule precedence, or MDCA file policies appear — those remain the next chapter's skills. They do not let an Information Protection Reader author a policy because the group name contains Information Protection.

When you can name DLP Compliance Management versus View-Only DLP Compliance Management versus the wide Compliance Administrator group, and you can explain how administrative units collapse under an Entra directory role, you have this blueprint bullet.