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 Level 2 and NIST SP 800-171 Rev. 3 3.1.3 require 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

NIST SP 800-171 Rev. 3 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 are created and published in Purview, but the Azure Rights Management (RMS) service maintains its own copy of the label configuration for encryption operations. These two copies sync automatically on a schedule — typically every few hours — which means a label you just created or modified may not be immediately available for RMS encryption, decryption, or Microsoft 365 Groups container labeling.

This delay is a common source of confusion. Clients create a label, publish it, immediately try to apply it to a test document, and see it fail to encrypt or decrypt — concluding that something is misconfigured. In most cases, the label simply hasn't propagated yet.

To force an immediate sync:

Import-Module ExchangeOnlineManagement
Connect-IPPSSession
Execute-AzureAdLabelSync

This is a one-time sync, not a continuous one

Execute-AzureAdLabelSync triggers a single sync pass — it pulls the current label configuration from Purview to the RMS service. It does not establish an ongoing sync. Labels will continue to sync automatically on the default schedule, but any new label changes require either waiting for the next automatic sync or re-running this command.

Run this command after:

• Creating a new sensitivity label
• Modifying encryption settings on an existing label
• Modifying the published label policy
• Applying a container label to M365 Groups and SharePoint sites (see Container Labels)
• Any time you need to skip the automatic sync delay during testing or initial deployment

Making label deployment deterministic

Running Execute-AzureAdLabelSync after every label configuration change eliminates the "is it broken or is it still syncing?" ambiguity during deployment and testing. Build it into your label creation procedure so you and the client know the sync has completed before moving to the next step.

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. Run Execute-AzureAdLabelSync to force immediate sync to RMS
5. 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.

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
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 NIST SP 800-171 Rev. 3 3.3.2 audit record review requirements).