Deploy scalable ring‑fenced Purview operations with Administrative Units
As Microsoft Purview deployments mature, many organisations encounter the same scaling challenge: how do you decentralize operations without fragmenting governance or losing visibility? Administrative Units (AUs) provide a native way to solve this by enabling ring‑fenced operations—allowing teams to operate independently within clearly defined boundaries, while preserving central oversight. This post focuses on the why behind using Administrative Units in Microsoft Purview, with a particular emphasis on scalable, ring‑fenced operations. We’ll walk through three reference architectures that illustrate how Administrative Units support real‑world operating models—without requiring multiple tenants or separate DLP platforms. note: this article and visuals will focus on Administrative Units support in Purview Data Loss Prevention. However, Administrative Units are supported in additional solutions of Microsoft Purview. Refer to Administrative units in Microsoft Purview | Microsoft Learn for more details and support. Why Administrative Units matter for scalable operations Many large organisations operate with decentralized compliance and DLP teams, often aligned to regions, business units, or regulated functions. Historically, this led to one of two sub‑optimal patterns: Multiple, disconnected DLP solutions or tenants Centralized teams managing policies and alerts for parts of the business they don’t own Administrative Units change this model by allowing organisations to: Partition users (and supported resources) into logical units Assign restricted administrators who can only see and act within their unit Apply both global and AU‑scoped policies together, with predictable behavior From a Purview perspective, this enables true business function autonomy, enforced through RBAC and data visibility boundaries, while keeping global services—such as classification—centralized. Reference architecture 1: Layered governance with ring‑fenced operations Scenario An organisation wants to migrate from multiple legacy DLP solutions into Microsoft Purview while preserving independent operations for each business function or region. Architecture highlights This model introduces three distinct layers: Central governance (Global) Global administrators define baseline policies applicable across the tenant Shared services such as classifiers and reusable components remain central Central teams retain cross‑tenant monitoring and reporting capabilities Administrative Units (per business function) Each business function or region is mapped to an Administrative Unit RBAC, policy visibility, and alert management are strictly scoped to the AU Policies created here only affect users within that unit Business function‑level operations Scoped DLP admins manage local policies Alerts and incidents are handled by the owning team Controls can be tuned to meet specific regulatory or operational needs Why this matters This architecture enables a phased migration: Start with a single entity Gradually scale across additional business functions Avoid policy sprawl by consolidating and retiring legacy configurations Crucially, tenant‑wide limits and global services remain unchanged, ensuring consistent performance as scale increases. Reference architecture 2: Ring‑fencing user activity visibility to sub‑business functions Scenario “We have dedicated DLP analysts for executives. DLP alerts and activities for these users must only be visible to that team.” Architecture highlights This model refines the first architecture and allowing to have DLP analysts for a subset of users only. Executive users are placed into a dedicated Administrative Unit representing a subset of users of a business unit. Policies can be published to multiple Administrative Units (ex: Americas + Americas - Execs) In this model: Some DLP administrators may be assigned to multiple AUs so they can publish policies across them Users must belong to a single AU to ensure clean visibility boundaries Why this matters This pattern is particularly effective for: Executive monitoring HR or Legal teams Highly sensitive populations It delivers strict separation of duties without duplicating policies or creating isolated tenants, and aligns with how Purview scopes alerts, activity explorer, and audit data when Administrative Units are used. Reference architecture 3: User activity visibility for multi‑AU users Scenario Some users operate across multiple business functions—for example, executives or shared service leaders—while still requiring controlled visibility for analysts. Architecture highlights User activities are stamped with the sum of all Administrative Units the user belonged to at the time of the activity Scoped DLP administrators: Can only create policies affecting users within their assigned AU. However the sum of their policies will be applicable. Scoped DLP analysts: See all activities for users in their AU, even if those activities were generated by policies scoped to a different AU. Why this matters This model ensures: No loss of investigative context for analysts Predictable visibility when users span multiple organizational boundaries Continued enforcement of AU‑based separation of duties It also reinforces a key principle: Administrative Units control visibility and management scope — not the existence of the underlying activity data. Once a user's in scope of a policy, its related activities/alerts are visible to DLP analysts allowed to review this user's activities. When not to use Administrative Units Administrative Units are a powerful enabler for decentralized, ring‑fenced operations—but they are not required in every Purview deployment. You may choose not to introduce Administrative Units in the following situations: Single, centralized compliance team. If one team owns all policy creation, alert triage, and investigations across the organisation—and there is no requirement to restrict visibility—Administrative Units add limited value. In this model, global role groups already provide sufficient control. No need for visibility or management separation. Administrative Units are primarily about scoping visibility and permissions. If all administrators are expected to see all users, alerts, and activities, AU‑based scoping may introduce unnecessary complexity without operational benefit. Early or small‑scale Purview deployments. Organisations at an early stage of Purview adoption—running a small number of global policies—may find it simpler to start without AUs and introduce them later as operating models mature. Administrative Units do not change tenant limits or global services, so adoption can be phased over time. Requirements driven purely by policy targeting. If the primary requirement is targeting users dynamically for policy application (rather than restricting administrator access or visibility), adaptive scopes alone may be sufficient. Administrative Units become relevant when who can see and manage data is as important as which users are in scope. In short, Administrative Units are best introduced when organisations need to scale operations with clear ownership boundaries, not simply to organise users. Centralized vs. Decentralized Functions in a Ring‑Fenced Operating Model A scalable Microsoft Purview operating model relies on a deliberate split between functions that remain centralized at the tenant level and those that are decentralized to business functions or regions via Administrative Units (AUs). This balance enables autonomy without fragmentation, preserving global consistency while allowing teams to operate independently within defined boundaries. Functions that Remain Centralized Certain capabilities are intentionally retained at the global (tenant) level to ensure consistency, performance, and governance across the organisation. These functions are not delegated to Administrative Units: Global governance and baseline policy definition Central teams define tenant‑wide baseline policies that apply consistently across all users, regardless of AU membership. This ensures minimum protection standards and avoids divergent interpretations of risk. Shared services and reusable components Core services such as classifiers and other reusable components remain centralized to prevent duplication, reduce administrative overhead, and maintain consistent detection behavior across the tenant. Cross‑tenant monitoring and reporting Central teams retain visibility across Administrative Units for monitoring, reporting, and oversight purposes, ensuring that decentralization does not result in blind spots at the organizational level. Tenant‑wide limits and platform behavior Administrative Units do not alter tenant‑wide service limits or global platform characteristics. Keeping these aspects centralized ensures predictable performance and scalability as additional business functions are onboarded. Functions that Are Decentralized via Administrative Units Operational responsibility is decentralized to business functions or regions by mapping them to Administrative Units, with strict scoping enforced through RBAC and data visibility boundaries: Policy creation and management scoped to the AU Business function teams can create and manage policies that only affect users within their Administrative Unit, allowing controls to be tailored to local regulatory or operational requirements without impacting other parts of the organisation. Scoped visibility of alerts, activities, and incidents Administrators and analysts assigned to an AU can only see alerts, activities, and incidents for users in that unit. This enforces separation of duties and prevents unintended access to sensitive data belonging to other functions. Local alert handling and incident response Decentralized teams own the investigation and remediation of alerts generated within their AU, enabling faster response times and clearer accountability. Operational tuning per business function Controls can be adjusted within an AU to reflect specific risk tolerances, regulatory obligations, or operational realities, without creating policy sprawl or requiring separate tenants. Why This Split Matters By clearly separating centralized governance and shared services from decentralized, AU‑scoped operations, organisations can scale Purview deployments in a phased and controlled manner—starting with a single business function and expanding over time—while maintaining consistent governance, visibility, and performance across the tenant. Key takeaways Administrative Units in Microsoft Purview are not just a permissions feature—they are an operating model enabler. Used correctly, they allow organisations to: Scale decentralized operations with confidence Enforce ring‑fenced visibility and management boundaries Combine global consistency with local autonomy For organisations planning large‑scale Purview deployments or consolidating legacy compliance tooling, Administrative Units provide a foundational architecture for sustainable growth. Learn more Administrative units in Microsoft Purview (presentation) Administrative units in Microsoft Purview | Microsoft LearnMicrosoft Purview Referential Architecture Diagrams
Microsoft Purview architecture diagrams provide a reference view of how classification, sensitivity labelling, Data Loss Prevention (DLP), Insider Risk Management, and Microsoft 365 Copilot protections work together across Microsoft 365 workloads. They illustrate how organisations can consistently identify, label, and protect sensitive data across endpoints, email, collaboration services, browsers, and AI‑assisted workflows—without prescribing a single deployment model. Classification generates sensitivity signals, labels express organizational protection intent, and DLP enforces that intent in real time across devices, apps, and services. Together, these patterns show how Copilot inherits existing security controls so AI‑generated content remains governed within the same compliance boundaries as organizational data.Data Security Posture Reports
Proving Your Data Security Posture with Confidence Microsoft Purview Posture Reports help organizations prove (not just assume) that their data security controls are working. They provide a clear, outcome‑based view of how effectively sensitivity labels and Data Loss Prevention (DLP) policies are protecting sensitive data across Microsoft 365. Rather than focusing on individual events or alerts, Posture Reports answer a higher‑level question: Are our data protection controls consistently applied and enforced across the organization? We designed Posture Reports to give security, compliance, and business leaders a defensible, measurable view of data security posture, especially critical as organizations adopt Copilot and other AI tools. Purview reporting offers unified data security insights, helping teams identify and address top risks quickly. By consolidating intelligence, it highlights vulnerabilities so you can take prompt action. With contextual information and measurable results, Purview streamlines responses to threats, improves resilience, and supports a proactive security strategy. Microsoft Purview reporting dashboards drive security decisions because they convert massive, fragmented security telemetry into decision‑ready insights: what’s happening, where the risk is, whether controls are effective, and what to do next. For insights on customizing these reports, check out this article. Where can I access these reports? Three Locations: Purview.microsoft.com -> Information Protection -> Reports Purview.microsoft.com -> Data Loss Prevention -> Posture Reports Purview.microsoft.com -> DSPM -> Reports Posture Reports Basics The out-of-box (OOB) reports are built with a combination of Metric and Analytic cards. Note: these reports are refreshed hourly. What is a Metric Card? What is an Analytic Card? Metric cards are designed to highlight a single, high‑level value or KPI and are also the foundation for building custom cards that combine metrics with trend context. Analytics cards provide richer visualizations that help users explore patterns and trends in the data. What they do: A Metric card is used to create a card that pairs a primary metric with its historical trend This allows users to answer not just “What is the value?” but also “Is it improving or declining?” Metric cards are commonly used for adoption, growth, and compliance health indicators These cards focus on showing trends over time What they do: Show distributions, breakdowns, or trends over time Enable comparison across locations, labels, or workloads Support investigation and analysis rather than just reporting These are useful when you need a visual representation rather than a single metric. Display data using charts such as bars, lines, or other visual formats These cards are commonly used for trend analysis, distribution views, and comparative reporting. Both make patterns easier to understand. Report Insights The following table goes into each OOB report and breaks down different viewpoints to help understand how to use them. Report Where it shows Data Security Decision Intent Why What it shows Key Metrics Filter by Label distribution and adoption in Microsoft 365 DSPM Reports Information Protection Reports Expand auto labeling to high volume unlabeled areas Simplify or consolidate confusing labels Look for high label coverage areas as additional enforcement opportunities Prioritize training/auto-labeling in areas with low label adoption Label coverage is the foundational signal for downstream controls Label activities by workload Sensitivity labels by platform for endpoint devices Sensitivity label usage Label activities by application methods Total labeled items Auto-labeled items Manually labeled items Labeled by default How applied Activity Location Platform Sensitivity label Sensitive info type Policy Rule How applied detail Sensitive info type confidence User Auto-labeling coverage DSPM Reports Information Protection Reports Which auto-labeling polices to promote from audit to enforce Where false positives need tuning before enforcement Which sensitive data types are under-protected Whether auto-labeling can safely scale further Can we trust our classification signal enough to automate protection? Auto-labeling by enforcement (which are in sim mode vs. enforcement mode) Auto-labeled items by policies Top auto-labeling policies (most active auto-labeling policies by number of items they have labeled) Auto-labeling policies by platform for endpoint devices Total labeled items Auto-labeled items Auto-labeled emails Auto-labeled files How applied Activity Location Platform Sensitivity label Sensitive info type Policy Rule How applied detail Sensitive info type confidence User Sensitivity Label Changes DSPM Reports Information Protection Reports Whether to restrict or justify label downgrades Where insider risk controls may be needed (users downgrading heavily) Which labels need stronger default enforcement? Whether user behavior is increasing data exposure Label changes are often an early warning signal of oversharing or misuse Sensitivity label transition trends (timelines for label upgraded/downgraded/removed over time) Sensitivity label removed across workloads (where labels have been removed) Types of Sensitivity labels downgraded (to which sensitivity labels items were often downgraded) Sensitivity label downgrade methods (Analyze sensitivity label downgrades by application method/workload. Dual chart helps identify if this is happening manual or automatic) Sensitivity label downgrades by user (which users are most frequently downgrading) Labels upgraded Labels removed Labels downgraded Labels downgraded manually How applied Activity Location Platform Sensitivity label Sensitive info type Policy Rule How applied detail Sensitive info type confidence User Top users triggering DLP Policies DSPM Reports Data Loss Prevention Posture Reports Whether activity reflects risky behavior or broken workflows Which users or roles need targeted controls or guidance If DLP policies are too broad or too noisy If insider risk investigations should be warranted or considered Distinguish Real risk vs policy misalignment vs. normal business activity DLP Policies Triggered by Users (DLP rule match per rule) Unique users involved in triggers Total users with repeated triggers Policy Location (Workload) Endpoint Device Activity Most triggered DLP Rules or Activities DSPM Reports Data Loss Prevention Posture Reports Which policies need tuning or scoping Where enforcement can be strengthened safely Which risks are systemic vs. isolated Whether DLP is actually aligned to sensitive data High volume DLP rules should drive prioritization, not alert fatigue Top DLP Rules Triggered DLP Rules Triggered by Device Activity (most common endpoint activities triggered) Total rules triggered Unique users involved in triggers Total protective actions taken Policy Location (Workload) Endpoint Device Activity Most triggered DLP policies DSPM Reports Data Loss Prevention Posture Reports Are my highest‑priority policies aligned to real user behavior Shows whether your most critical policies are: Actively protecting data, or rarely triggered (possibly mis-scoped or irrelevant) Which DLP policies are most actively protecting sensitive data, is this the highest risk? DLP Policies Triggered by Workload Total policy trigger volume Unique users involved in triggers Total rules triggered Policy Location (Workload) Endpoint Device Activity Customer Use Cases What are some customer concerns Posture Reports address OOB? Use Case Situation Guidance Labeling & auto-labeling program rollout: “Are we increasing coverage and preventing drift?” Customer situation: A customer is rolling out sensitivity labels and auto-labeling. Leadership asks: “Are we labeling more content?” Security asks: “Are sensitive items still unprotected?” And compliance asks: “Are users downgrading labels?” In posture reports, Information Protection coverage includes label distribution/adoption, auto-labeling posture, and posture drift through label transitions (e.g., label downgrades). This maps directly to “coverage + drift + enforcement” conversations. The built-in IP posture set also calls out label distribution and adoption, auto-labeling policy coverage, and sensitivity label activity as core reports. For “active data” posture, the design intent explicitly includes questions like “What % of my active data estate is labeled vs not labeled?” and “What %/count of unlabeled data has sensitive info?” and “How is labeling protection trending over 30 days?”: perfect for proving program progress (or identifying gaps). DLP tuning & noise reduction: “Which policies/rules are actually firing, and who’s tripping them?” Customer situation: The DLP admin is overwhelmed: policies exist, but they don’t know which ones are actually driving volume (or pain), and which users are repeatedly triggering violations. They need to prioritize tuning based on real-world triggers. Surfaces most triggered DLP rules, most triggered DLP policies, and top users triggering DLP policies. This is directly aligned to the operational question “Are our policies effective?” The service-description blurb explicitly frames DLP posture reports as highlighting most triggered rules, highest-volume policies, and top policy violators. This is exactly what admins use to decide what to tune first. Helps teams move from anecdotal “DLP is noisy” to a ranked view of where to focus (policy/rule/user). CISO Reports, “Are we safer this quarter?” posture readout Customer situation: A CISO (or compliance leader) needs a repeatable, executive-ready snapshot of how the organization is protecting sensitive data, without stitching together audit logs, Activity Explorer screenshots, and spreadsheets. Posture Reports are explicitly positioned as “executive-ready visibility” across Information Protection + DLP. Provides OOB, executive-ready visibility into data protection posture across Information Protection and Data Loss Prevention, so the CISO can answer “Is Purview doing what we intend it to do?” and “Where are the gaps?” quickly. Enables a consistent monthly/quarterly narrative from built-in metrics and trends, with hourly refresh called out as a customer/partner value driver (great for “freshness” credibility in leadership reviews). Uses a rolling window approach; guidance is to save/export what you want to retain for future reference (great for recurring readouts). Frequently Asked Questions (FAQs) Question Guidance What is the least permission required to see Posture Report section for DLP? Information Protection Reader We can see Activity Explorer details inside the reports in a non-simplified view, where all confidential information is visible. If someone has the Security Reader role, will they be able to see these things? Security Reader can see Activity Explorer content surfaced inside Posture Reports, including user/activity-level details that may expose sensitive metadata. If you want a role that can view posture reports but not see confidential item-level signals, Security Reader is not the safe minimum; Information Protection Reader is. Why are our DLP "Device Posture" reports are not in the Posture Reports and only on the DLP Overview page? It will move. Right now, the traffic on home page is high, so we launched there. There will eventually be a deep clone into our "Posture Reports" section, however, it will take some time before it shows up. Can I get reports going back longer than 30 days? We're working on increasing this number but at this time, the reports go back a max of 30 days. Is there any impact on tenant performance when enabling new reporting features? How quickly will reports populate after enabling the feature? No significant impact is expected. If labeling, scanning, and/or DLP policies are already active, reports populate instantly when the feature is enabled (assuming E5 is in place). No additional intrusive operations are performed on the tenant. Can we customize these reports? We have a current public preview in place for posture report customization. Stay tuned for more updates as we continue to build out Microsoft Purview Reporting. Co-Authors: Kevin Kirkpatrick and Jane Switzer
Endpoint DLP Collection Evidence on Devices
Hello team, I am trying to setup the feature collect evidence when endpoint DLP match. Official feature documentation: https://learn.microsoft.com/en-us/purview/dlp-copy-matched-items-learn https://learn.microsoft.com/en-us/purview/dlp-copy-matched-items-get-started unfortunately, it is not working as described in the official documentation, I opened ticket with Microsoft support and MIcrosoft Service Hub, Unfortunatetly, they don't know how to setup it, or they are unable to solve the issue. Support ticket: TrackingID#26040XXXXXXX9201 Service Hub ticket: https://support.serviceshub.microsoft.com/supportforbusiness/onboarding?origin=/supportforbusiness/create TrackingID#26040XXXXXXXX924 I follow the steps to configure: based on the Microsoft documentation, I should be able to see the evidence in Activity explorer or Purview DLP alert or Defender Alerts/Incidents.
[HELP] "Action required for browser protections" alert
Hello! I have an Endpoint DLP policy with Device location. After several scoping changes (device groups, inclusions/exclusions) to narrow it to a specific target group, the orange alert appeared: Action required for browser protections. One or more policies were not applied in Edge for Business. This could be due to a policy sync issue, lack of required permissions, or an issue with the server. Either resync these policies or contact an admin with the required permissions to resync. After resyncing, you might still see this message for up to 1 day while the system completes the sync and activates protections. The policies were working before. Clicked Resync multiple times, only for the error to return. Please help![HELP]"Action required for browser protections" alert
Hello! I have an Endpoint DLP policy with the Devices location. After multiple scoping changes (device groups, inclusions/exclusions) to narrow it to a specific target group, the alert appeared: Action required for browser protections. One or more policies were not applied in Edge for Business. This could be due to a policy sync issue, lack of required permissions, or an issue with the server. Either resync these policies or contact an admin with the required permissions to resync. After resyncing, you might still see this message for up to 1 day while the system completes the sync and activates protections. The policies were working before. Clicked Resync multiple times, banner disappears briefly, only to return. Please help!
DLP for SaaS Apps - Endpoint DLP/MDE + Purview Browser Extension
I need help verifying my understanding of how Purview tools control file upload/download and clipboard copy/paste actions. Here's the situation: Goal: Block file upload/download, copy/paste of sensitive data to/from SaaS apps. Deployment: Rolling out MDE (in Passive mode) or Endpoint DLP (Onboarding device to Purview) and the Purview browser extension for Chrome/Firefox. My Understanding: Copy Control: Handled by Endpoint DLP/MDE on the endpoint. Upload/Download/Paste Control: Requires the Purview browser extension (or native browser support Edge/Safari). Specific Question: The browser extension isn't available for macOS. I've read that MDE on macOS can handle everything (file upload/download and clipboard control). Could someone confirm if the table I've created correctly reflects this? Summary of Clipboard (Copy/Paste) Enforcement Operation Windows (Onboarded) macOS (Onboarded) Note Copy to Clipboard Endpoint Endpoint DLP Sensor Endpoint DLP Sensor Prevents data from reaching the clipboard Paste into SaaS Apps (Chrome/Firefox) Browser Extension Endpoint DLP Sensor Blocks paste into SaaS apps. Paste into SaaS Apps (MS Edge/Safari) Native on Edge Native on Edge/Safari Built-in integration; no extension needed.
Aggregate alerts not showing up for Email DLP
Hi, I’m unable to see the “Aggregate alerts” option while configuring an Email DLP policy, although the same option is visible for Endpoint DLP. The available license is Microsoft 365 E5 Information Protection and DLP (add-on). If this is a licensing limitation, why am I still able to see the option for Endpoint DLP but not for Email DLP? Screen short showing option for Endpoint DLP alertsIssue with the Canadian Drivers License SIT
Did any face an issue with the Canadian Driver's License SIT in the DLP policy? We see a lot of false positives especially around BC province number, NB, PrinceEdward Island and Saskatchewan. These provinces has just digits which can flag any kind of digits. Even if we use some custom RegEx and reduced keyword list, it still flags a lot of false positives. We see this as more and more customers are not happy with it. Has anyone found a breakthrough or best solution for deploying the Canadian Driver's License DLP?
Unknown DLP Policies Triggering IRM Alerts
Two unknown DLP policies are triggering high severity IRM alerts, and these policies are not showing in our DLP policy list. The policies names are: FileCopiedToRemovableMedia (Preview) FileUploadedToCloud (Preview) Additionally, there are no associated events in Activity Explorer. These alerts are causing confusion with our Security operations because they result in Sentinel incidents.
