Data Protection Requirements

Microsoft Purview Information Protection addresses four fundamental problems in regulated data environments:

1. Discovery: Where is sensitive data? Content Explorer maps labeled content across SharePoint, OneDrive, Exchange, and Teams. The Purview Information Protection Scanner extends coverage to on-premises file shares.
2. Classification: What is it? Sensitivity labels create a consistent taxonomy that travels with files regardless of location or sharing state.
3. Flow Control: Where can it go? Data Loss Prevention (DLP) policies enforce boundary constraints, blocking external shares, email forwards, or clipboard paste based on label or content match.
4. Encryption: Even if data leaves the boundary, sensitivity label encryption makes it unreadable without the right Entra ID identity and an active license in the issuing tenant.

GCC High

CMMC Scope

For CMMC Level 2, Purview addresses the following controls within the information protection domain:

CMMC Practice	Purview Mechanism
AC.L2-3.1.3 (CUI Flow Control)	DLP policies prevent CUI from being sent to external recipients, uploaded to non-approved services, or shared with users outside the tenant boundary.
SC.L2-3.13.11 (FIPS Encryption)	Sensitivity label encryption uses AES-256 and RSA-2048 through Microsoft's FIPS 140-2 validated cryptographic modules. Encryption is document-level and persists independent of storage location.
SC.L2-3.13.16 (CUI at Rest)	Labels applying encryption protect CUI at rest in SharePoint, OneDrive, Exchange mailboxes, and Teams, including items in shared drives and archived conversations.
MP.L2-3.8.1 (Media Protection)	Sensitivity labels persist when CUI is exported to USB or local disk. Intune Device Control (configured in Chapter 10) restricts unencrypted export to removable media.
MP.L2-3.8.7 (Removable Media)	Defender for Endpoint Device Control provides the enforcement layer; Purview Endpoint DLP provides the data-awareness layer, triggering policy based on label or content match during copy-to-USB events.

CUI Label Taxonomy

The DoD CUI Registry defines over 20 categories. For most DIB organizations, a practical starting taxonomy covers the categories that appear most frequently in engineering and program management workflows. Users see three top-level choices, Public, Internal, and CUI; CUI is a parent label that opens to three sublabels, and the parent itself is never applied to anything:

Label	Parent	Description	Encryption (Assign permissions now)
Public	none	Approved for public release.	None
Internal	none	Internal business information not cleared for external release. No special handling required.	None
CUI	none	Parent label: a grouping that cannot be applied. Users choose the sublabel that matches the document's marking or the contract's CUI guidance.	n/a: every setting lives on the sublabels
CUI (Basic)	CUI	CUI whose authority does not specify handling. NIST SP 800-171 baseline applies.	Required: All Employees, Co-Author; approved partner domains, Viewer; 30 days offline
CUI//SP-CTI	CUI	Controlled Technical Information under DFARS 252.204-7012: engineering drawings, specifications, test data. Carries a DoD distribution statement.	Required: All Employees, Co-Author; approved partner domains, Viewer; 30 days offline
CUI//SP-EXPT	CUI	Export controlled under ITAR or EAR. US persons only.	Required: sg-us-persons (a mail-enabled security group, or Microsoft 365 group, of verified US persons), Co-Author, 7 days offline

Basic and Specified are the two handling classes, and the class comes from the law behind the information. Basic means the law says protect it, so the NIST SP 800-171 baseline applies; Specified means the law says how, and the sublabels exist because those rules change both the banner and the permissions. Organizations that hold Privacy Act data add a fourth sublabel, CUI//SP-PRVCY, the same way when that data is in scope; this book does not build it out. The per-sublabel markings and encryption settings, and how parent labels and sublabels behave in Purview, are in Sensitivity Labels.

Start with CUI, not the full registry

Attempting to implement all 20+ CUI sub-categories at initial deployment creates user confusion and drives low adoption. Start with the three encrypted sublabels (CUI (Basic), CUI//SP-CTI, CUI//SP-EXPT). Users can request additional sub-categories as the program matures. A CMMC assessor needs to see that CUI is labeled and encrypted, not that every category is pre-built on day one.

GCC High Purview is Sovereign: Verify Your Portal URL

Purview in GCC High uses sovereign endpoints. Confirm that your compliance portal URL is compliance.microsoft.us. If it resolves to compliance.microsoft.com, sensitivity label encryption keys may be managed in the commercial cloud, which is out of scope for CUI. Verify your Azure Information Protection service endpoint in the Purview admin center before deploying labels.

Commercial

NIST SP 800-171 Rev. 3 Scope

For organizations voluntarily aligning to NIST SP 800-171 Rev. 3, Purview addresses the following security requirements within the information protection domain:

NIST SP 800-171 Rev. 3 Requirement	Purview Mechanism
3.1.3 (Information Flow Control)	DLP policies prevent sensitive data from being sent to external recipients, uploaded to non-approved cloud services, or shared outside the organization.
3.13.11 (FIPS Cryptography)	Sensitivity label encryption uses AES-256 and RSA-2048 through Microsoft's FIPS 140-2 validated cryptographic modules. Encryption persists at the document level regardless of storage location.
3.13.8 (Transmission and Storage Confidentiality)	Labels applying encryption protect sensitive data at rest in SharePoint, OneDrive, Exchange mailboxes, and Teams, including archived and shared content.
3.8.1 (Media Protection)	Sensitivity labels persist when data is exported to USB or local disk. Intune Device Control restricts unencrypted export to removable media.
3.8.7 (Removable Storage Devices)	Defender for Endpoint Device Control blocks unauthorized write access to removable media; Purview Endpoint DLP provides content-awareness triggering based on label or sensitive information type match.

Sensitive Data Label Taxonomy

Commercial organizations have more flexibility in label taxonomy than CMMC-scoped environments. The goal is a taxonomy that maps to how your organization actually describes its sensitive data, not to a regulatory registry. A practical starting taxonomy for most commercial M365 deployments:

Label	Scope	Encryption
Public	Approved for external release.	None
Internal	Business content that originates within the organization. Default label for unlabeled content.	None
Confidential	Content subject to regulatory requirements (GLBA, FERPA, HIPAA, PCI-DSS) or business-sensitive material such as financials, HR records, and strategy documents.	Optional (recommended for external shares)
Restricted	Data requiring the most stringent access controls: M&A activity, executive communications, board materials, credentials, regulated PII/PHI.	Required: AES-256 via sensitivity label

Fewer labels drive higher adoption

Purview deployments consistently show that taxonomies with more than 5 labels result in poor adoption and significant mis-labeling. Start with Public, Internal, Confidential, and Restricted. Add sub-labels (e.g., Confidential // Legal, Confidential // Finance) only after baseline adoption is established across the organization.