· Microsoft 365  · 7 min read

Microsoft Purview for CUI Data Classification and DLP

How to design Microsoft Purview sensitivity labels and DLP policies for CUI handling.

How to design Microsoft Purview sensitivity labels and DLP policies for CUI handling.

Microsoft Purview represents the Microsoft 365 information protection stack, encompassing sensitivity labels, label-based encryption, Data Loss Prevention (DLP), data lifecycle management, and integrated audit capabilities. For organizations managing Controlled Unclassified Information (CUI) within M365, Purview serves as the technical implementation layer for NIST SP 800-171 data-centric controls, the layer assessors examine when verifying that “we label CUI and prevent it from leaving the boundary” reflects actual implementation rather than policy rhetoric.

This post examines the Purview design pattern for CUI: label taxonomy structure, protection settings that enforce CUI handling, DLP rule architecture, and the adoption practices determining whether labeling remains effective in production environments.

The controls Purview supports

From NIST SP 800-171 r2, Purview directly supports:

  • 3.1.3 — Control the flow of CUI in accordance with approved authorizations. DLP rules block unauthorized flows.
  • 3.1.20 — Verify and control/limit connections to and use of external systems. DLP policies block external sharing of labeled CUI.
  • 3.1.22 — Control CUI posted or processed on publicly accessible systems. DLP policies block labeled CUI to public-facing locations.
  • 3.8.3 — Sanitize or destroy system media containing CUI before disposal or release. Label-driven retention and disposal policies underpin this.
  • 3.13.4 — Prevent unauthorized and unintended information transfer via shared system resources. Label-based encryption and DLP on outbound channels.
  • 3.13.8 — Implement cryptographic mechanisms to prevent unauthorized disclosure of CUI during transmission. Label-applied encryption to email and documents.
  • 3.13.16 — Protect the confidentiality of CUI at rest. Label-applied encryption to documents at rest.

A workable label taxonomy

Simplicity remains critical. Twenty labels will not achieve consistent application by end users. A taxonomy with four to six top-level labels and minimal sub-labels for legal categories functions effectively in practice.

A typical CUI-aware taxonomy structure:

  • Public — content explicitly intended for external publication. No protection.
  • Internal — general business content. Default label for unmarked content. No encryption; mild DLP guardrails.
  • Confidential — sensitive business content. Encryption applied, restricted to authenticated organizational users.
  • CUI — Controlled Unclassified Information. Encryption, restricted to a defined CUI user group, copy/paste restrictions in supported clients, marking applied.
    • Sub-label: CUI / CDI — Covered Defense Information under DFARS 7012.
    • Sub-label: CUI / Export Controlled (ITAR) — additional restriction to U.S.-person users.
    • Sub-label: CUI / Specified — for CUI categories with specific dissemination controls.
  • Highly Confidential — sensitive trade secrets or pre-release contract data. Encryption, named-user restriction, additional protection settings as needed.

Each label carries a clear, documented application criterion. Users need not interpret. Training states: “If the content meets criterion X, the label is Y.”

Label protection settings for CUI

The CUI parent label’s protection configuration includes:

  • Encryption: Apply. Assign permissions: members of the “CUI Authorized Users” security group receive Co-Author access. External users receive no permission.
  • User access expiration: Never (label-applied access; revoke via group membership change).
  • Offline access: 7 days. Balances usability with revocation timeliness.
  • Content marking: Apply header / footer / watermark with the text “CUI” (or the appropriate CUI banner for the category).
  • Auto-labeling: Where feasible, auto-label by SharePoint site (CUI-designated sites apply the label automatically) and by sensitive information type (regex-detected pattern matches such as ITAR control numbers).

The label’s encryption is enforced by Microsoft Information Protection (the engine behind Purview labeling). Files protected by the label require user authentication to the tenant and group membership verification for opening. Outside the tenant boundary the encryption persists; an unauthorized recipient cannot decrypt.

DLP rule structure

DLP rules complement labeling by blocking egress paths that labeling alone does not cover. The baseline rule set for a CUI-handling tenant includes:

DLP-001 — Block external sharing of labeled CUI

Locations: Exchange Online, SharePoint, OneDrive, Teams chat and channels. Condition: content has sensitivity label “CUI” (or any sub-label). Action: Block (with notification to user explaining why). Allow override only with business justification logged.

DLP-002 — Block labeled CUI to unmanaged endpoints

Endpoint DLP scope. Condition: content has sensitivity label “CUI” being copied to removable storage, uploaded to non-corporate cloud, or printed. Action: Block. The endpoint DLP requires Microsoft Defender for Endpoint (or the Purview endpoint agent) deployed; this overlaps with the Intune compliance baseline.

DLP-003 — Detect unlabeled CUI by pattern

Sensitive Information Types matching known CUI patterns: contract numbers, DD Form 254 markers, ITAR-controlled item identifiers, export control numbers. Action: Audit and alert (do not block, as false positives are high; the alert routes to the data protection team for review and potential auto-labeling).

DLP-004 — Restrict CUI-labeled email to allowed recipients

Condition: email with labeled CUI attachment or content sent to a recipient outside the tenant or outside a defined allow-list of partner domains. Action: Block (with override-with-justification for limited known partners).

Auto-labeling: where it earns its keep

Voluntary user-driven labeling alone does not survive at scale. Some users forget, some mislabel, some lower-label to ease sharing. Auto-labeling reduces the burden:

  • SharePoint site default label. A CUI-designated site applies the CUI label to every file added. Most common and most reliable mechanism.
  • Service-side auto-labeling policies. Scan content in SharePoint, OneDrive, and Exchange against sensitive information type patterns; apply the CUI label automatically when matched.
  • Client-side auto-labeling. The Microsoft 365 apps (Word, Excel, PowerPoint, Outlook) can recommend labels based on content. Useful for nudging but not enforceable on its own.

Auto-labeling employs a quarantine pattern worth using: when a sensitive information type match is high confidence but ambiguous, apply a draft label and notify the user to confirm or recategorize. Tune the patterns over time based on the false-positive rate.

Where Purview interacts with the rest of the stack

Purview’s labeling and DLP are powerful because they sit alongside the tenant’s identity and access controls. A labeled CUI document is encrypted at rest, restricted to a permission group, blocked from external sharing by DLP, and accessible only from a compliant device because the Conditional Access policy upstream demands it. The layers reinforce each other.

The tenant decision (commercial vs. GCC High) also affects Purview capability availability. Some Purview features (specific Sensitive Information Types, certain auto-labeling capabilities) historically lag in GCC High by months relative to commercial. Plan against the documented feature set in the tenant the organization actually runs.

And the broader CUI scoping work (which sites get the CUI label by default, which user populations are in the CUI Authorized Users group) is itself the implementation of the boundary decisions in organizational CUI boundary identification.

Adoption discipline

The technical configuration is the easier half. Adoption (getting users to label correctly, getting drift detected and corrected, getting DLP overrides examined) is the harder half. Practical disciplines include:

  • Mandatory labeling on save. The tenant setting that requires users to apply a label before saving an Office document. Forces a decision at the point of creation.
  • Justification on lower-label. When a user changes a label downward (e.g., CUI to Internal), require a free-text justification. Review periodically.
  • Activity Explorer review. The Activity Explorer in Purview shows label application, downgrade, and DLP rule match events. Review weekly for the first quarter post-rollout, then monthly.
  • Targeted training. Where a user repeatedly mislabels or overrides DLP, the response is conversation and training, not policy weakening.

Evidence retention

For assessor review:

  • Sensitivity label configuration export: name, scope, protection settings, content marking.
  • DLP policy export: locations, conditions, actions, override behavior.
  • Auto-labeling policy export: sensitive information types in use, scope.
  • Activity Explorer sample reports showing labeling events, downgrade events, DLP rule matches.
  • CUI Authorized Users group membership and the criteria for inclusion.

What to do next

  • Inventory current labels (if any) and audit usage. Where the taxonomy is large or inconsistently applied, consolidate before adding CUI.
  • Design the CUI label and sub-labels with explicit application criteria. Pilot with a single team for two weeks before broad rollout.
  • Implement the DLP rules in audit-only mode first. Tune the false-positive rate down before switching to block.
  • Wire the labels into SharePoint site defaults for any CUI-handling site. This is the single highest-leverage auto-labeling action.
  • Establish the Activity Explorer review cadence and the response process for repeated overrides.
Back to Blog

Related Posts

View All Posts »