Sensitivity Labels

Sensitivity labels are the foundation of Microsoft Purview's protection strategy. Everything else — DLP policies, Insider Risk Management, Copilot governance — depends on content being labeled. Labels must be designed before any other policy is deployed.

Label Taxonomy

GCC High (CMMC)

CUI-Aligned Label Hierarchy

CMMC AC.L2-3.1.3 requires organizations to control the flow of CUI based on the CUI Registry categories. The label hierarchy maps to the NARA CUI Framework:

Priority	Label	CUI Mapping	Scope	Encryption
0	Public	Not CUI	Files, Email	No
1	General	Not CUI — internal operational data	Files, Email, Site, Group	No
2	CUI — Basic	CUI Basic (single-category, standard safeguarding)	Files, Email, Site, Group	Recommended
3	CUI — Specified	CUI Specified (enhanced safeguarding required by law)	Files, Email, Site, Group	Required

CUI — Basic covers the majority of defense contractor CUI: technical data, export control, procurement-sensitive, and privacy data subject to standard NIST 800-171 safeguarding requirements.

CUI — Specified covers categories where the authorizing law requires enhanced controls beyond NIST 800-171: ITAR technical data, Tax Return information, legal privilege, and Personally Identifiable Information subject to the Privacy Act.

The CUI Registry at archives.gov/cui is authoritative. Map your specific data types to registry categories before finalizing label names.

Content Marking — CUI Banner

NARA 32 CFR Part 2002 requires a CUI designation indicator and CUI category markings on documents. Configure footer content marking:

CUI

For Specified categories, configure the footer as a dynamic marking using the label name:

CUI//SP-EXPT   (ITAR / Export Control)
CUI//SP-PRVCY  (Privacy Act)

Encryption on CUI — Basic

CMMC SC.L2-3.13.10 requires protecting CUI at rest and in transit. For files stored outside GCC High (contractor systems, partner sharing), encryption via Rights Management is the control:

• Assign Permissions Now: Grant Read and Change rights to the tenant's authenticated users group. This ensures files remain readable inside the tenant but cannot be opened by external parties without a decryption ceremony.
• Do not expire: CUI documents may be retained for years; expiring keys creates recovery support burden.
• Allow offline access for 7 days: Balances security with usability for field personnel.

Encryption on CUI — Specified

For CUI Specified, restrict decryption rights further:

• Assign permissions to a specific Entra security group (e.g., sg-cui-specified-access) rather than all authenticated users.
• Disable offline access (Never offline access period).
• Enable content expiry only if the data has a defined retention period (e.g., FOIA-exempt period).

Commercial

Regulatory-Aligned Label Hierarchy

For commercial organizations, labels map to data sensitivity tiers rather than government classification categories:

Priority	Label	Scope	Encryption	Auto-labeling
0	Public	Files, Email	No	No
1	Internal	Files, Email, Site, Group	No	Yes
2	Confidential	Files, Email, Site, Group	No	Yes
3	Restricted	Files, Email, Site, Group	Yes	No

Public — Data open to public inspection by law or released through public channels. No controls required.

Internal — Operational content that originates within the organization and may be shared externally when appropriate. Label is informational only; no encryption or sharing restrictions. Applied automatically as a baseline for unlabeled content.

Confidential — Content subject to regulatory requirements: GLBA, FERPA, HIPAA, PCI-DSS. Applied automatically when financial or PII SITs are detected at high confidence. No encryption by default (avoids user friction during the Foundational deployment phase), but external sharing is alerted via DLP.

Restricted — Content requiring the most stringent access controls: board materials, M&A data, HR disciplinary records, credentials. Encryption enabled with Assign Permissions Now. Not applied automatically — requires intentional user action with a mandatory justification prompt.

User-Facing Descriptions

Write label descriptions for end users, not administrators. The description appears in Office client tooltips:

Label	User Description
Public	Data that is publicly available or has been approved for public release.
Internal	For internal use. May be shared externally when appropriate. No special handling required.
Confidential	Contains sensitive personal or financial information subject to regulatory requirements. Share only with authorized parties.
Restricted	Highly sensitive. External sharing not permitted. Access from authorized devices only.

Label Scopes: Encryption vs. Container

When creating a sensitivity label in Purview, you choose one or more scopes — each scope applies the label to a different class of object. A single label can carry multiple scopes simultaneously, which is why one label can both encrypt a file AND control the SharePoint site it lives in.

Scope	What it protects	What it configures
Files & emails (encryption scope)	Individual documents, emails, and PDFs	RMS encryption with usage rights; offline access window; co-author/reader permissions; authentication context requirements
Groups & sites (container scope)	SharePoint sites, Teams, Microsoft 365 Groups	External sharing settings; unmanaged device access restrictions; privacy (public/private); default share link permissions
Schematized data assets (E5)	Azure SQL, Synapse, Data Lake	Label propagation in Purview Data Map for structured data
Meetings (E5)	Calendar events and meeting invites	RMS encryption on meeting content, watermarking

The Critical Distinction

• Encryption scope protects the content. The file travels encrypted. If it's exfiltrated, emailed externally, or copied to removable media, it remains unreadable to anyone outside the authorized group.
• Container scope protects the location. The SharePoint site enforces sharing and access policies on every file inside it — including files that don't individually carry the label yet.

These complement each other rather than duplicate. A file with encryption scope is safe regardless of where it travels. A site with container scope blocks unmanaged device access to every file in the site, not just labeled ones.

Recommended Configuration for CUI Labels

Encryption scope (Files & emails):

Setting	Recommended Value	Why
Encrypt files and emails	On	RMS encryption is the non-negotiable file-level control
Assign permissions now	Yes	Policy-enforced, not user-chosen
Users or groups	Specific CUI handler group (e.g., AVD-Enclave-FCI-Users)	Scopes decryption rights to authorized users only
Permissions	Co-Author (read, modify, print — no full control)	Co-Author prevents users from modifying label permissions themselves
User access expires	Never (or per retention policy)	Prevents lockout on older documents
Allow offline access	3–7 days	Short window limits risk of offline decryption of exfiltrated files

Container scope (Groups & sites):

Setting	Recommended Value	Why
External sharing	Only people in your organization	Prevents accidental external sharing at the site level
Access from unmanaged devices	Block access (or Web-only)	Forces managed devices for CUI site access, independent of any CA policy
Default share link	Specific people	Prevents "Anyone with the link" from being the default
Privacy	Private	CUI sites should not be discoverable via search

Enabling container support requires a one-time tenant configuration

Before container labels take effect, you must enable sensitivity labels for Microsoft 365 Groups and SharePoint sites at the tenant level. See the Container Labels section for the PowerShell commands. This is a one-time step per tenant — not per label.

Label Sync Timing

Sensitivity labels created and published in Purview need to sync into Microsoft Entra ID before they become available for application to container objects — Microsoft 365 Groups, SharePoint sites, and Microsoft Teams sites. For tenants stood up after September 2019, this sync happens automatically with no admin action required. For tenants that pre-date September 2019, the Execute-AzureADLabelSync cmdlet in Security & Compliance PowerShell forces the sync.

The cmdlet's scope is narrower than people often assume. It moves labels from Purview into Entra ID for container-label application — and that's all. It does not influence the Purview-to-Azure Rights Management sync (which handles encryption configuration) and does not influence label visibility in Office client apps (which is driven by the published label policy's automatic propagation):

Sync path	Forced by Execute-AzureADLabelSync?	How it actually works
Purview → Entra ID (container-label availability)	✅ Yes — this is the cmdlet's purpose	Automatic for tenants post-September 2019; cmdlet forces it for older tenants or as a troubleshooting step
Purview → Azure Rights Management service (encryption configuration)	❌ No	Automatic on Microsoft's schedule; no admin-runnable cmdlet exists to force it
Purview → Office client policy cache (label visibility to end users in Word/Excel/Outlook)	❌ No	Automatic ≈1 hour after publishing the policy; force per-client refresh by signing out / back in or restarting the Office app

To run the cmdlet (GCC High):

Import-Module ExchangeOnlineManagement
Connect-IPPSSession `
    -UserPrincipalName admin@yourtenant.onmicrosoft.us `
    -ConnectionUri https://ps.compliance.protection.office365.us/powershell-liveid/ `
    -AzureADAuthorizationEndpointUri https://login.microsoftonline.us/organizations
Execute-AzureADLabelSync
Disconnect-ExchangeOnline -Confirm:$false

Both sovereign URIs are mandatory for GCC High — the commercial defaults fail with "unable to find tenant." See Connect to Security & Compliance PowerShell — Microsoft 365 GCC High for the canonical reference. The account needs Compliance Administrator or Compliance Data Administrator.

When to actually run it

• One-time container-labeling enablement — immediately after the EnableMIPLabels = True Graph call for the Group.Unified setting that turns on container labels for the tenant. This is the canonical use case and is captured in the Container Labels section below.
• Troubleshooting — if a newly-created label doesn't appear in the SharePoint site-label picker after several hours, run this as a remedial step. For tenants post-September 2019, this is rarely needed.
• Not "after every label change." Microsoft does not document this cmdlet as a recurring sync tool. The label-policy-to-Office-clients propagation is a separate automatic path (≈1 hour after publishing) that this cmdlet does not affect, and the Purview-to-RMS encryption-configuration sync is also separate and automatic.

Policy-First Design

Before creating labels in the Purview portal, document the label policy decisions:

Question	Decision Needed
How many labels?	More labels = more user confusion. Limit to 3–5 published labels.
Default label for new files?	Typically Internal or General — not Public.
Default label for email?	Typically the same or one level lower than files.
Mandatory labeling?	Yes — required for regulated environments.
Justification on downgrade?	Yes — critical for audit trail. Pair with downgrade reporting script.
User ability to remove labels?	Allow with justification; track in Activity Explorer.

Incremental Rollout to a Test Group

Deploying sensitivity labels — especially with mandatory labeling and encryption — changes how users save files, send email, and access documents. A direct-to-production rollout risks user frustration, helpdesk flood, and workflow breakage. Use a three-phase rollout to surface issues before they affect the full user population.

Key concept: The label itself is tenant-wide once created, but visibility and enforcement are controlled by the label policy. You can create a label, publish it only to a test group, and the rest of the tenant sees nothing. This makes staged rollouts straightforward.

Phase 1 — Create but don't publish (1 week)

1. Create the label in Purview with the target configuration (encryption scope, container scope, permissions, offline access window)
2. Do not publish it — without a label policy, the label is invisible to end users
3. Validate the label configuration using a test account with Compliance Administrator or Information Protection Administrator role — these roles see all labels regardless of policy
4. Apply the label to a test file, encrypt/decrypt, verify permissions behave as expected

This phase catches configuration errors (wrong permission group, overly restrictive settings, missed offline access) before any end user is affected.

Phase 2 — Publish to a test group (1–2 weeks)

1. Create a label policy named Label Policy - Test (or similar) and publish it to a security group — e.g., EID_Sensitivity_Label_Test_Users — containing 5–10 representative users
2. Enable mandatory labeling and justification on downgrade in the test policy — the test should reflect real production behavior, not a softer test configuration
3. Set the default label to match the production plan
4. Let test users work normally for 1–2 weeks — creating documents, sharing, collaborating, attempting external sends

What to monitor in Activity Explorer:

• Label application events — are users applying the intended labels?
• Label downgrade events — are users justifying downgrades appropriately?
• DLP rule matches — are protected documents triggering expected DLP policies?
• User notifications and policy tips — are users seeing and responding to them?

Criteria to advance to Phase 3:

• No unresolved label-related helpdesk tickets in the past 7 days
• Mandatory labeling is applying without breaking user workflows
• Encryption is working across Office apps, Outlook, SharePoint, and mobile clients
• External sharing behavior matches expectations

Phase 3 — Expand to the broader population

Once the test group operates cleanly:

Approach	How	When to use
Expand the existing test policy	Edit Label Policy - Test and add the broader group (or All Users) to the publish scope	Fastest — no new policy to maintain. Use if the test policy settings match production requirements exactly.
Create a production policy	Create Label Policy - Production with the target scope, then retire the test policy	Preferred for larger deployments — keeps the test policy available for future label changes, allows different default labels or mandatory settings between test and production populations

Label policies are how you scope exposure, not labels themselves

A label is created once and exists tenant-wide. Multiple label policies can publish the same label to different groups with different defaults, mandatory settings, and justification requirements. This lets you roll out the same label progressively across departments or regions without creating duplicate labels.

Don't skip mandatory labeling in the test phase

If the test group runs without mandatory labeling but production will have it on, you're testing a different configuration than you'll deploy. Users will hit the mandatory labeling prompt for the first time when the policy expands — creating a wave of confusion at exactly the wrong moment. Test with the real settings.

Auto-Labeling

Auto-labeling applies labels based on SIT detection without user involvement. Two modes operate independently:

Client-side auto-labeling — runs in Office apps while the user is editing. Shows a notification bar recommending or applying the label. Requires the Office client to be policy-aware (M365 Apps for Enterprise, not Office LTSC).

Service-side auto-labeling — runs in the Purview backend on existing content in Exchange, SharePoint, and OneDrive. Applies labels to already-stored files without user involvement. Operates as a simulation first; review results before enabling enforcement.

Auto-Labeling Policy Design

Label	Trigger SITs	Confidence	Mode
Internal / General	No SITs — applied to all unlabeled Office files	N/A	Default label policy
Confidential / CUI — Basic	Financial SIT group or PII SIT group	High	Auto-apply
CUI — Specified (GCC High)	CUI Bundle (Distribution Statements, ITAR/EAR, DoD Contract)	High	Auto-apply
Restricted	No SIT trigger — user-applied only	N/A	Recommend only

Service-Side Simulation

Always run service-side auto-labeling in Simulation mode for at least 7 days before enabling enforcement. Review the simulation report in the Purview portal to identify false positives before labels are written to production files.

PDF Labeling

PDF labeling is two distinct features, and both have to be enabled separately. Tenants that turn on one and assume the other follows are usually surprised when search and DLP appear to ignore PDF content.

Track	What it covers	Default in GCC High
Office desktop export	When users do File > Save As > PDF, File > Export > PDF, or Share > Send a Copy > PDF in Word, Excel, or PowerPoint, the resulting PDF inherits the source file's label and any encryption. Logged with SensitivityLabeledFileRenamed in the unified audit log.	On (assuming sensitivity labeling is enabled and labels are published)
SharePoint and OneDrive processing	Whether SP/OD can read inside encrypted PDFs to support search, eDiscovery, DLP, auto-labeling policies, and default-label-on-library for PDFs	Off — opt-in via PowerShell

Without the second track, SP/OD silently fails to process encrypted PDFs. Office files keep working, PDFs become opaque to compliance — search results, DLP matches, and eDiscovery content all exclude PDFs without surfacing an error. The two settings stack: EnableSensitivityLabelforPDF requires EnableAIPIntegration = $true first.

Verifying current state

# GCC High — note the .us admin URL, not .com
Connect-SPOService -Url https://<tenant>-admin.sharepoint.us

Get-SPOTenant | Select-Object EnableAIPIntegration, EnableSensitivityLabelforPDF

The most common state for a tenant that has been doing labeling for Office files is EnableAIPIntegration = True and EnableSensitivityLabelforPDF = False — labeling appears to work, but PDF processing is silently dark.

Enabling

# Parent setting — required before the PDF child can be set
Set-SPOTenant -EnableAIPIntegration $true

# PDF support
Set-SPOTenant -EnableSensitivityLabelforPDF $true

The PDF flag requires SharePoint Online Management Shell 16.0.24211.12000 or later — Update-Module Microsoft.Online.SharePoint.PowerShell if older. Older versions fail with a generic parameter not found error rather than a helpful message. Propagation takes about 15 minutes after the cmdlet returns; do not test immediately. Primary sources: Set-SPOTenant cmdlet reference and Enable sensitivity labels for files in SharePoint and OneDrive § Adding support for PDF.

Gotchas

Gotcha	What happens
Signed PDFs aren't supported	Cryptographically signed PDFs can't be labeled — Microsoft explicitly excludes them. The label apply silently no-ops.
Print-to-PDF strips the label	Office warns the user and requires confirmation. With mandatory labeling on (see Mandatory Labeling), Print-to-PDF is unavailable entirely.
PDF/A + encryption is unsupported	The long-term archival format conflicts with label encryption. Office blocks the export when both are requested.
Auto-labeling load increases	Enabling PDF support pushes existing auto-labeling policies to also evaluate PDFs. The 100,000-files-per-day cap is shared across file types — large tenants can hit it on the first sweep.
Encrypted PDFs need label-aware readers	Microsoft Edge (Windows/Mac) reads them natively. Adobe Acrobat requires the Microsoft Information Protection plug-in. Other readers fail with a generic error.

Recommended posture for CUI

Both flags $true. The risk of leaving EnableSensitivityLabelforPDF off is meaningful in a CUI tenant: a user exports a labeled Word document to PDF, the PDF inherits the label and encryption (Track 1), but SharePoint cannot see inside it for DLP scanning or eDiscovery (Track 2 disabled). The compliance posture looks fine — the file is encrypted — but DLP rule matches, search results, and audit-search content all silently exclude the PDF. Match the PDF posture to the Office-files posture: if .docx is in scope for DLP, .pdf should be too.

Schedule the enablement during a low-activity window for tenants with large PDF inventories

Auto-labeling will process the entire existing PDF corpus on first enable. A tenant with hundreds of thousands of legacy PDFs can stall Office-file labeling for days while the PDF backlog clears against the 100,000-files-per-day cap. Enable late on a Friday or before a holiday weekend so the bulk processing completes before active editing resumes.

Container Labels

Container labels apply to Microsoft Teams, SharePoint sites, and Microsoft 365 Groups. They do not encrypt files — they control site-level settings.

Prerequisites — Container labels require a one-time setup:

# Enable MIP labels for M365 Groups in Entra
Install-Module Microsoft.Graph.Beta -Scope CurrentUser
Connect-MgGraph -Scopes "Directory.ReadWrite.All"

$template = Get-MgBetaDirectorySettingTemplate | Where-Object { $_.DisplayName -eq "Group.Unified" }
$settingParams = @{
    TemplateId = $template.Id
    Values = @(@{ Name = "EnableMIPLabels"; Value = "True" })
}
New-MgBetaDirectorySetting -BodyParameter $settingParams

# Sync labels from Purview to Entra ID — one-time after enabling container labels
# For GCC High, add -ConnectionUri and -AzureADAuthorizationEndpointUri to Connect-IPPSSession
# (see Label Sync Timing section above for the full sovereign-endpoint invocation)
Import-Module ExchangeOnlineManagement
Connect-IPPSSession
Execute-AzureADLabelSync

Container Label Settings

Label	External Sharing	Default Share Link	Unmanaged Device Access
Public	Allowed (Anyone)	Anyone with the link	Full access
Internal / General	Authenticated guests only	Specific people	Full access
Confidential / CUI — Basic	Existing guests only	Specific people	Web-only (read)
Restricted / CUI — Specified	No external sharing	Specific people	Blocked

Mandatory Labeling and Justification

Enable mandatory labeling in the label policy to require users to select a label before saving or sending. In the label policy settings:

• Require users to apply a label: On
• Require users to provide justification to remove a label or lower its classification: On
• Provide users with a link to a custom help page: Link to your organization's data classification policy

Justification text is captured in the Unified Audit Log under the SensitivityLabelUpdated operation and is surfaced in Activity Explorer.

Label Downgrade Reporting

The following PowerShell script queries the Unified Audit Log for label downgrade and removal events in the past 7 days and emails a formatted HTML report.

# Connect to Security & Compliance
Connect-IPPSSession

# Build label ID-to-name lookup
$LabelLookup = @{}
Get-Label | Select-Object ImmutableId, DisplayName | ForEach-Object {
    if ($_.ImmutableId) {
        $LabelLookup[$_.ImmutableId.ToString()] = $_.DisplayName
    }
}

# Query audit log — downgrades and removals only
$EndDate = Get-Date
$StartDate = $EndDate.AddDays(-7)
$Events = Search-UnifiedAuditLog `
    -StartDate $StartDate -EndDate $EndDate `
    -Operations "SensitivityLabelUpdated","FileSensitivityLabelChanged","SensitivityLabelRemoved","FileSensitivityLabelRemoved" `
    -ResultSize 5000

$Report = @()
foreach ($EventObj in $Events) {
    $Data = $EventObj.AuditData | ConvertFrom-Json
    # LabelEventType: 1=Upgrade, 2=Downgrade, 3=Remove
    if ($Data.SensitivityLabelEventData.LabelEventType -in 2, 3) {
        $ActionType = if ($Data.SensitivityLabelEventData.LabelEventType -eq 3) { "Removed" } else { "Downgraded" }
        $OldLabel = if ($LabelLookup.ContainsKey("$($Data.SourceLabel)")) { $LabelLookup["$($Data.SourceLabel)"] } else { $Data.SourceLabel }
        $NewLabel = if ($Data.SensitivityLabelEventData.LabelEventType -eq 3) { "(Removed)" }
                    elseif ($LabelLookup.ContainsKey("$($Data.DestinationLabel)")) { $LabelLookup["$($Data.DestinationLabel)"] }
                    else { $Data.DestinationLabel }
        $Report += [PSCustomObject]@{
            Time          = $EventObj.CreationDate
            User          = $EventObj.UserIds
            Action        = $ActionType
            File          = $Data.ObjectId
            OldLabel      = $OldLabel
            NewLabel      = $NewLabel
            Justification = $Data.SensitivityLabelJustificationText
        }
    }
}

if ($Report.Count -gt 0) {
    $Report | Export-Csv -Path ".\LabelDowngrades_$(Get-Date -Format 'yyyy-MM-dd').csv" -NoTypeInformation -Encoding UTF8
    Write-Host "$($Report.Count) downgrade/removal events exported." -ForegroundColor Yellow
} else {
    Write-Host "No downgrade events found in the past 7 days." -ForegroundColor Green
}

Schedule this script to run weekly via a Logic App or Azure Automation runbook and send results to your security team. Retain the CSV output as audit evidence for compliance assessments (satisfies CMMC AU.L2-3.3.2 audit record review requirements).