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
Microsoft