Administrative Units vs. Full Directory, User and Group Targeting, Policy Priority, and Enterprise Governance
Introduction
Deploying Microsoft Purview Sensitivity Labels across a multinational enterprise requires more than creating labels and publishing them to users.
Large organizations often operate across multiple countries, business units, subsidiaries, and regulatory environments. Each may have different data protection requirements, while the organization still needs a consistent global classification framework.
One of the most important architectural decisions is how to design Sensitivity Label Publishing Policies.
When configuring a publishing policy in Microsoft Purview, administrators encounter two important settings:
- Administrative Units: Full directory or selected Administrative Units.
- Users and groups: All users and groups or Include only specific.
Although these settings appear in the same configuration workflow, they serve different purposes.
Understanding their relationship is essential for building a scalable, secure, and maintainable information protection architecture.
In this article, I’ll explain how these settings work, explore practical enterprise scenarios, and share my recommended approach to designing sensitivity label publishing policies for multinational environments.
1. Understanding Sensitivity Labels and Publishing Policies
Microsoft Purview Sensitivity Labels help organizations classify and protect sensitive information across supported Microsoft 365 applications and services.
Depending on their configuration, sensitivity labels can provide capabilities such as:
- Data classification and identification.
- Encryption and access restrictions.
- Content markings, including headers, footers, and watermarks.
- Protection of documents and emails.
- Integration with Microsoft Purview Data Loss Prevention (DLP).
- Support for information protection governance.
For example, an organization might establish the following classification taxonomy:
| Sensitivity Label | Description | Example |
|---|---|---|
| Public | Information approved for public distribution | Marketing materials |
| Internal | Information intended for internal use | Internal procedures |
| Confidential | Sensitive business information | Customer records, financial reports |
| Highly Confidential | Critical or highly restricted information | Strategic plans, acquisition documents |
However, creating a sensitivity label does not automatically make it available to users.
Labels must be published through Sensitivity Label Publishing Policies.
A publishing policy determines which labels are available to which users and configures supported policy settings, including default labeling, mandatory labeling, and justification for removing or lowering a sensitivity label.
This separation between label configuration and label publication is fundamental to enterprise information protection design.
2. Full Directory vs. Administrative Units
When creating a sensitivity label publishing policy, Microsoft Purview provides an Assign admin units configuration step.
The administrator can use the Full directory scope or select supported Administrative Units.
These options define the administrative scope associated with the policy.
Option 1: Full Directory
Full directory means the policy is not restricted to a specific Administrative Unit.
This provides the flexibility to target users and groups throughout the Microsoft 365 tenant.
For example:
Policy: POL-SL-Global-Baseline
Administrative scope: Full directory
Users and groups: All
Published labels: Public, Internal, Confidential, Highly Confidential
In this scenario, the organization establishes a common classification framework for users across the tenant.
However, selecting Full directory does not necessarily mean the policy applies to everyone.
Consider another example:
Policy: POL-SL-Pilot
Administrative scope: Full directory
Users and groups: Include only specific
Target: GRP-Purview-Pilot
Here, the policy is scoped to the full directory administratively, but only members of the selected pilot group are targeted.
Key takeaway: Full directory defines the available administrative scope. User and group targeting determines who receives the policy.
Option 2: Administrative Units
Administrative Units (AUs) are Microsoft Entra ID objects that support scoped administration.
They allow organizations to delegate administrative responsibilities over defined sets of users and other supported directory objects.
Microsoft Purview integrates with Administrative Units for supported administrative and policy-scoping scenarios.
Consider a multinational enterprise operating in several regions.
The organization might create Administrative Units such as:
- AU-Europe
- AU-Americas
- AU-AsiaPacific
Regional administrators can be assigned appropriate scoped roles, enabling them to manage supported resources within their administrative boundaries.
A sensitivity label publishing policy can also be scoped to a selected Administrative Unit.
For example:
Policy: POL-SL-Europe
Administrative scope: AU-Europe
Users and groups: All
Published labels: Approved labels for the European population
In this example, the policy targets eligible users within the selected Administrative Unit scope.
Administrative Units are particularly useful when organizations need to support regional administrative delegation, organizational separation, or specific governance requirements.
However, they should not be introduced automatically for every country or department.
Architecture recommendation: Use Administrative Units when there is a clear administrative scoping or delegation requirement, rather than using them as a replacement for ordinary Microsoft Entra groups.
3. All Users and Groups vs. Include Only Specific
After defining the administrative scope, the next step is selecting the target audience.
Microsoft Purview provides different targeting options, including All users and groups and Include only specific.
All users and groups
This option targets all eligible users within the applicable administrative scope.
For example:
- Full directory + All users and groups: Tenant-wide publication.
- Selected AU + All users and groups: Publication within the selected AU scope.
This approach is useful when a standard classification policy should apply consistently to the entire target population.
Include only specific
This option restricts the policy to explicitly selected users or supported groups.
For example, a company may want to introduce specialized labels for Finance, Human Resources, Legal, or Research and Development.
Rather than publishing every specialized label globally, administrators can target the relevant business populations.
Example:
Policy: POL-SL-Finance
Administrative scope: Full directory
Users and groups: Include only specific
Target: GRP-Finance
Published labels: Approved Finance-specific labels
This provides targeted publication without requiring an Administrative Unit for the Finance department.
Comparing the four combinations
| Administrative scope | Targeting | Typical use case |
|---|---|---|
| Full directory | All users and groups | Global classification baseline |
| Full directory | Include only specific | Pilot or departmental policy |
| Selected Administrative Unit | All users and groups | Regional or delegated policy |
| Selected Administrative Unit | Include only specific | Targeted policy within an AU |
The distinction is straightforward:
Administrative Units control the administrative and supported policy scope. Users and groups determine the policy’s intended recipients within that scope.
4. Designing a Scalable Enterprise Publishing Architecture
For multinational organizations, I generally recommend a layered architecture based on global standards and targeted exceptions.
The objective is to maintain a consistent classification framework while allowing flexibility for legitimate business requirements.
Layer 1: Global classification baseline
Start with a centrally governed set of sensitivity labels.
For example:
- Public
- Internal
- Confidential
- Highly Confidential
These labels should have clearly defined meanings, usage guidance, and protection requirements.
A global publishing policy can make the approved baseline labels available across the organization.
Example configuration
Policy: POL-SL-Global-Baseline
Administrative scope: Full directory
Targeting: All users and groups
Published labels: Global baseline labels
This simplifies user training, improves consistency, and reduces unnecessary policy fragmentation.
Layer 2: Department-specific protection
Not every department has identical data protection requirements.
For example:
The Legal department may require additional labels for privileged or highly restricted documents.
Human Resources may require specialized protection for employee records.
Finance may need more restrictive controls for sensitive financial information.
Rather than creating entirely separate classification frameworks, these requirements can often be addressed through additional labels or sublabels published to selected groups.
Example configuration
Policy: POL-SL-HR
Administrative scope: Full directory
Targeting: Include only specific
Target group: GRP-HR
Published labels: Approved HR-specific labels
This enables departmental protection while preserving the organization’s global classification model.
Layer 3: Regional administration
In some multinational organizations, regional security teams have distinct administrative responsibilities.
For example, a European information protection team may be responsible for managing supported policies for European users, while another team manages users in the Americas.
Administrative Units can help establish these boundaries.
However, regional Administrative Units do not necessarily require separate regional publishing policies.
If all regions use the same classification labels and policy settings, a single global publishing policy may be sufficient.
Separate regional policies should be created only when there are meaningful differences in requirements.
5. Understanding Publishing Policy Priority
Policy priority becomes particularly important when users are included in multiple sensitivity label publishing policies.
Consider an employee who belongs to both:
- The global publishing policy.
- A Finance-specific publishing policy.
Microsoft Purview supports multiple applicable publishing policies.
The employee can receive sensitivity labels from applicable policies.
However, some policy settings may conflict.
For example:
The global policy may configure one default label, while the Finance policy configures another.
Microsoft Purview uses publishing policy priority to resolve conflicting settings.
Important: In the publishing policy list, a higher order number indicates higher priority.
Consider this example:
| Publishing Policy | Priority order | Target |
|---|---|---|
| POL-SL-Global-Baseline | 0 | All users |
| POL-SL-Finance | 1 | Finance group |
| POL-SL-Legal | 2 | Legal group |
When applicable settings conflict, the higher-priority publishing policy takes precedence.
This should not be confused with sensitivity label priority.
Sensitivity label priority determines the relative sensitivity ordering of labels.
Publishing policy priority determines which applicable policy settings take precedence when conflicts occur.
My recommendation
Before implementing multiple publishing policies:
- Document every policy and its target audience.
- Identify overlapping group memberships.
- Define which policy settings should take precedence.
- Test conflicting settings with representative users.
- Maintain a central publishing policy priority matrix.
This helps avoid unexpected labeling behavior during enterprise rollout.
6. Administrative Units vs. Microsoft Entra Groups
One of the most common architectural mistakes is treating Administrative Units and Microsoft Entra groups as interchangeable.
They are not.
| Capability | Administrative Unit | Microsoft Entra Group |
|---|---|---|
| Organize users | Yes | Yes |
| Delegate scoped administration | Yes | Not by itself |
| Target publishing policies | Supported scenarios | Yes, supported group types |
| Represent departmental membership | Possible | Common use |
| Manage application access | Not its primary purpose | Common use |
| Support regional administration | Yes | Requires separate role/scoping design |
When to use Administrative Units
Consider Administrative Units when:
- Regional teams need delegated administration.
- Different administrative boundaries are required.
- Least-privilege administration is a priority.
- Supported Purview policies must be restricted to defined administrative populations.
When to use Microsoft Entra groups
Consider groups when:
- Publishing labels to specific departments.
- Running controlled pilots.
- Targeting selected business populations.
- Maintaining policy assignments through group membership.
In many enterprise environments, both mechanisms are useful.
They should complement each other rather than compete.
7. Avoid Publishing Policy Sprawl
A multinational company may operate across dozens of countries and business units.
It can be tempting to create a separate publishing policy for every organizational entity.
However, this can lead to unnecessary complexity.
Potential challenges include:
- Overlapping policy assignments.
- Conflicting policy settings.
- Inconsistent user experiences.
- Increased administrative effort.
- Difficult troubleshooting.
- More complex change management.
Microsoft recommends keeping the number of sensitivity label publishing policies as small as practical.
My preferred approach is to begin with a global baseline and add targeted policies only when there is a documented business requirement.
For example, the organization may need additional policies for Legal, HR, or a specialized research division.
But creating a separate policy for every department simply because the department exists is rarely a good architectural objective.
The goal is not to maximize the number of policies. The goal is to minimize complexity while meeting security and governance requirements.
8. Enterprise Deployment and Rollout Strategy
A successful sensitivity labeling program requires more than technical configuration.
It also requires stakeholder alignment, application testing, end-user communication, support readiness, and operational governance.
I recommend a phased rollout.
Phase 1: Assessment and discovery
Start by understanding the existing environment.
Key activities include:
- Review existing sensitivity labels and publishing policies.
- Identify classification and governance requirements.
- Assess licensing and supported applications.
- Review Microsoft Entra groups and Administrative Units.
- Identify overlapping or conflicting policies.
- Understand business and regional protection requirements.
Deliverables: Current-state assessment, gap analysis, requirements matrix, and initial architecture recommendations.
Phase 2: Classification and architecture design
Define the target information protection model.
Key activities include:
- Design the classification taxonomy.
- Define label descriptions and protection settings.
- Determine whether encryption is required.
- Design the publishing policy structure.
- Define group targeting and AU requirements.
- Document policy priority and exception handling.
Deliverables: Target architecture, label design matrix, publishing policy matrix, and governance model.
Phase 3: Pilot implementation
Deploy the proposed configuration to a representative pilot population.
For example:
Administrative scope: Full directory
Users and groups: Include only specific
Target: GRP-Purview-Pilot
Validate:
- Label availability.
- Manual labeling.
- Default labeling.
- Mandatory labeling.
- Downgrade justification.
- Supported Office applications.
- Encryption and external sharing, where applicable.
- Policy overlap and priority behavior.
Deliverables: Pilot configuration, test results, issue register, and deployment readiness assessment.
Phase 4: Controlled enterprise rollout
Expand deployment through approved business units and regions.
Key activities include:
- Implement the global publishing baseline.
- Deploy justified targeted policies.
- Communicate classification guidance.
- Train users and support teams.
- Monitor adoption and labeling activities.
- Address technical and operational issues.
Deliverables: Deployment plan, rollout evidence, communication materials, and adoption reporting.
Phase 5: Operational governance
Once labels are deployed, establish continuous governance.
Key activities include:
- Monitor label adoption and usage.
- Review policy changes and exceptions.
- Assess downgrade and label removal activities.
- Maintain group assignments.
- Review administrative access.
- Refine labels based on business requirements.
Deliverables: Operational procedures, reporting dashboards, governance documentation, and continuous improvement roadmap.
9. Publishing Labels vs. Automatically Applying Labels
Another important distinction is the difference between publishing labels and automatically applying them.
A sensitivity label publishing policy makes labels available to the targeted population.
It does not automatically classify every existing document or email.
Microsoft Purview supports different approaches to automatic labeling.
Client-side automatic labeling
Client-side automatic labeling operates in supported Office applications.
For example, an employee creates a document containing sensitive financial information.
Based on configured conditions, Microsoft Purview may recommend or automatically apply a sensitivity label in the supported application.
This helps protect information during content creation and editing.
Service-side automatic labeling
Service-side automatic labeling uses dedicated auto-labeling policies for supported Microsoft 365 locations.
For example, an organization may configure an auto-labeling policy to identify sensitive information stored in SharePoint or OneDrive.
The policy can be tested in simulation mode before being enabled for automatic application.
What about DLP?
Microsoft Purview Data Loss Prevention is another complementary capability.
Sensitivity labels classify content and can apply protection settings.
DLP policies detect and control sensitive data activities across supported workloads.
For example, an organization may create a DLP policy that restricts external sharing of documents labeled Highly Confidential.
An effective information protection architecture should coordinate sensitivity labels, automatic labeling, encryption, and DLP rather than treating them as isolated features.
10. Enterprise Architecture Best Practices
Based on Microsoft Purview architecture principles, I recommend the following practices.
1. Standardize classification globally. Establish a consistent classification taxonomy wherever possible.
2. Keep publishing policies simple. Create additional policies only when business requirements justify them.
3. Use groups for audience targeting. Avoid maintaining large collections of individually assigned users.
4. Use Administrative Units selectively. Introduce them when scoped administration or supported policy boundaries are required.
5. Document policy priority. Identify overlapping assignments and validate conflicting policy settings.
6. Separate classification from protection. Not every label requires encryption, and not every DLP policy requires a sensitivity label.
7. Pilot before broad deployment. Test technical behavior and user experience before expanding.
8. Establish governance ownership. Define responsibilities for label changes, policy approvals, exceptions, and reporting.
9. Validate licensing and application support. Advanced capabilities such as automatic labeling may require additional licensing and have workload-specific limitations.
10. Monitor and continuously improve. Use reporting, feedback, and operational findings to refine the information protection program.
Conclusion
Designing Microsoft Purview Sensitivity Label Publishing Policies for multinational enterprises requires a balance between global consistency and organizational flexibility.
The key architectural distinction is understanding the purpose of each configuration option.
Full directory provides an unrestricted directory scope for the policy.
Administrative Units support scoped administration and supported policy targeting.
All users and groups targets the eligible population within the applicable scope.
Include only specific restricts publication to selected users or groups.
For most multinational organizations, I recommend starting with a centrally governed classification taxonomy and a global publishing baseline.
Additional policies should be introduced only where specialized business requirements, different policy settings, or administrative boundaries justify them.
Administrative Units should support a deliberate delegation model, while Microsoft Entra groups remain a practical mechanism for targeting specific business populations.
Ultimately, a successful Microsoft Purview deployment is not measured by how many sensitivity labels or publishing policies have been created.
It is measured by how effectively the organization can classify, protect, govern, and manage sensitive information across its environment.
The best enterprise architecture is one that provides consistent protection without unnecessary operational complexity.
