You ask, we answer · 14 October 2026

Purview DLP admin units are coming for Copilot and Cowork — can BU security own policies without tenant-wide rights?

We run multi-BU tenants with Entra administrative units today. Copilot DLP is still tenant-scoped in Learn. Roadmap says AU support for Copilot, Copilot Chat and Cowork DLP is previewing — how do we plan decentralised DLP admins without breaking tenant-wide baselines?
purviewdlpadmin-unitscopilotgovernance

Grounded with: Microsoft 365 Roadmap 575287 Microsoft Purview: Data Loss Prevention-Admin Units Support for Copilot & Cowork DLP (In development, Preview October 2026 / GA November 2026); Microsoft Learn — Learn about using Microsoft Purview DLP to protect interactions with Microsoft 365 Copilot, Copilot Chat, and Cowork (current note: Copilot location does not yet support Admin units); Administrative units in Microsoft Purview; DLP policy reference — Administrative Unit restricted policies; Microsoft Purview service description — DLP for Microsoft Copilot

DIGITAL SKILL WORKS LTD / 12 PANES


You’re right to want decentralised Copilot DLP without handing every regional compliance lead Global Admin. Multi-BU tenants already use Entra administrative units for labels, Exchange and SharePoint DLP; Copilot as a location has been the awkward tenant-wide hold-out.

Here’s what’s going on. Roadmap 575287 (Microsoft Purview: Data Loss Prevention-Admin Units Support for Copilot & Cowork DLP) is In development, with Preview in October 2026 and GA in November 2026 (Worldwide). MRC says Purview DLP is extending Administrative Units support to Microsoft 365 Copilot, Copilot Chat and Cowork, so organisations can delegate management of supported Copilot DLP policies to administrators within their assigned AUs — regional, departmental or regulatory boundaries — without granting tenant-wide policy-management permissions. Existing tenant-wide policies continue to apply, and AU-scoped management is optional.

Learn today is honest about the lag: the page Learn about using Microsoft Purview Data Loss Prevention to protect interactions with Microsoft 365 Copilot, Copilot Chat, and Cowork still states that the Microsoft 365 Copilot and Copilot Chat policy location doesn’t support Admin units. That is the current product fact until 575287 lands in your tenant. Until then, plan from MRC plus the existing AU model documented for broader DLP (Administrative units in Microsoft Purview, DLP policy reference). Copilot DLP already covers blocking SITs in prompts and web search, excluding labelled files and emails from processing, and (in preview) excluding external email from grounding — all under the Custom template’s Copilot location, with policy updates taking up to about four hours to reflect.

Steady before scale puts Security and GRC in front of “give every BU their own Copilot DLP playground.” Tenant-wide baselines should stay the floor; AU policies are for local tightening, not for inventing weaker islands.

Options that actually work:

  1. Keep tenant-wide Copilot DLP as the non-negotiable floor. Highly Confidential / Personal label blocks, core SIT prompt blocks, and external-email grounding rules stay unrestricted-admin owned. AU admins add stricter local rules where regulators demand them — they don’t unwind the floor.
  2. Map AUs to real accountability before Preview. Name which Entra AUs map to which BUs, which Purview role groups those AU-restricted admins sit in, and who still sees tenant-wide alerts. MRC enables delegation; it does not invent your RACI.
  3. Pilot one AU in Preview, not every geography. Turn on AU-scoped Copilot DLP management for a single regulatory BU, compare alert visibility and policy simulation against the tenant baseline, then expand. Optional means you can wait.
  4. Clone tenant policies per AU and hope nobody drifts. Fast — and how “local innovation” becomes three incompatible prompt-block lists.

12 Panes action / comms: Tell Security: 575287 is delegation of supported Copilot DLP policy management inside AUs; tenant-wide policies still apply — design the floor first. Tell GRC: Update the AI register with which Copilot DLP controls are tenant-owned vs AU-owned, and when Learn drops the “no Admin units” sentence for your rings. Tell BU compliance leads: You will manage policies for your unit’s users — not rewrite the enterprise baseline. Leadership: This is Steady Security for multi-BU tenants, not a reason to delay Copilot DLP until every AU is perfect.

Benefits / risks: Regional and departmental admins stop needing tenant-wide Purview rights for Copilot locations; Learn and portal UX will trail MRC through Preview; which exact Copilot DLP conditions become AU-manageable is “supported” per Microsoft — verify in Preview rather than assuming every SIT and label action scopes the same way; licensing for Copilot DLP features still follows Purview/Copilot SKU guidance — AUs don’t invent rights your tenant never bought.

I’d suggest a half-day Steady workshop before GA: draw the tenant-wide Copilot DLP floor, list candidate AUs, assign one pilot AU admin role group, and write the “no weaker than floor” rule into GRC. Once Preview appears, test one labelled-file block and one SIT prompt block under that AU before you scale.

DIGITAL SKILL WORKS LTD / 12 PANES · You ask, we answer

All answers Ask a question