CMMC Level 2 Retention Policies In Microsoft Purview Setup Guide

If you handle CUI, retention can’t be a vague “we keep stuff for a while” promise. In a CMMC Level 2 assessment, I want to show what’s kept, for how long, who can change it, and how I stop accidental deletion. That’s where Microsoft Purview retention policies and labels earn their keep.

This guide is written for small teams running Microsoft 365, often alongside Cloud Infrastructure projects, an Office 365 Migration, and day-to-day Cybersecurity Services. I’ll keep it practical, with the exact Purview features and clicks I use in 2026. It won’t guarantee compliance by itself, but it will help you produce clean, assessor-ready evidence.

Start with a CMMC Level 2-friendly retention schedule (template included)

Photo by Markus Winkler

Retention is like setting a timer on a document safe. Too short, and you lose evidence. Too long, and you keep risk around for no reason. For CMMC Level 2 (NIST SP 800-171), I focus on three outcomes:

• CUI stays protected and recoverable for the required period.
• Audit and incident records exist long enough to investigate and prove actions.
• Records can’t be quietly altered or deleted by the wrong people.

Here’s a sample retention schedule template I use as a starting point. You must validate timeframes with your contract language, legal counsel, and customer flow-downs.

Category	Example retention period (validate)	Purview approach	Notes
CUI documents (projects, engineering, tickets)	6 years	Retention label + (optional) record declaration	Use labels so CUI follows the file, even when moved.
Contracts and SOWs	7 years	Label, publish to SharePoint and OneDrive	Consider longer if disputes are common.
HR and personnel records	7 years after separation	Label (separate HR sites)	Keep access tight, use separate containers.
Security incident records (IR reports, RCA)	5 years	Label, plus eDiscovery holds when needed	Holds should be event-driven, not “always on.”
Security logs and audit exports	1 year (often 90 to 365 days)	Purview Audit plus external SIEM retention	Many teams store logs outside M365 for analysis and immutability.

My rule: I never pick retention periods “because that’s what another company did.” I pick them because contracts, risk, and investigations demand them.

If you’re a Business Technology Partner for clients, this is where Technology Consulting matters. A good schedule supports Business Continuity & Security, and it fits into an IT Strategy for SMBs without creating busywork. Even shops juggling Restaurant POS Support and Kitchen Technology Solutions benefit, because good evidence and change control reduce panic during an incident.

Build your Purview control map (CMMC expectations to Purview features)

Before I click anything, I write a simple map from common CMMC Level 2 expectations to Purview controls. It keeps the build honest and makes assessor conversations easier.

CMMC Level 2 / NIST 800-171 expectation (typical)	Purview feature(s) to use	What I show an assessor
Records handling and retention rules exist	Retention policies, retention labels	Policy and label settings, scope, locations, effective dates
Prevent unauthorized deletion of required records	Records Management (record or regulatory record), retain-only configs	Label properties (record settings), restricted admin roles
Retain investigation evidence when needed	eDiscovery (Standard) holds, Litigation Hold	Case hold details, hold scope, timestamps
Audit events are captured and reviewed	Purview Audit	Audit search results, alerting process docs, reviewer roles
Disposition is controlled and documented	Disposition review (Records Management)	Disposition review list, reviewer assignment, decisions
Changes to compliance settings are controlled	Purview role assignments + audit trails	Role group membership, audit events for policy changes

For background on how Microsoft frames lifecycle and records features, I keep Purview data lifecycle and records management overview bookmarked.

Step-by-step: Configure Microsoft Purview retention policies and labels (2026 clicks)

I do this work in the Microsoft Purview portal at compliance.microsoft.com. If you’re new to the admin experience, this SMB Purview setup guide is a solid orientation.

1) Confirm roles, then lock down who can change retention

1. In Purview, go to Settings > Roles & scopes.
2. Open Role groups.
3. Assign the smallest set of admins to:
   • Records Management
   • Compliance Administrator (or a tighter equivalent in your org)
   • eDiscovery Manager (only if they run holds)

I treat this like Device Hardening for compliance tooling. Fewer hands on the knobs means fewer “oops” moments.

2) Create retention labels for CUI and other record categories

1. Go to Data lifecycle management > Microsoft 365 > Retention labels.
2. Select Create a label.
3. Name it clearly (example: CUI - Retain 6 Years - Record).
4. Set Retain items for a specific period (example: 6 years).
5. Choose what happens after the period:
   • For many CUI sets, I prefer Do nothing (retain-only) until disposition is reviewed.
   • For lower-risk content, choose Delete items automatically (if approved).
6. If your policy requires stronger control, configure the label as a record (or regulatory record where appropriate for immutability and stricter controls).

3) Publish labels to SharePoint, OneDrive, and Exchange

1. Go to Data lifecycle management > Label policies.
2. Select Publish labels.
3. Choose locations:
   • SharePoint sites
   • OneDrive accounts
   • Exchange email
   • Microsoft 365 Groups (if you store content there)
4. Use Include and Exclude carefully. I often exclude personal OneDrive accounts if they aren’t in CUI scope.

4) Create Microsoft Purview retention policies for broad, location-based coverage

Labels are great when content needs to “travel.” Policies are great when a location needs a baseline rule.

1. Go to Data lifecycle management > Microsoft 365 > Retention policies > Create.
2. Choose the locations you need, including:
   • Teams chats
   • Teams channel messages
   • Exchange, SharePoint, OneDrive (as applicable)
3. Set the retention duration (example: keep Teams chat 1 year).
4. Decide whether to retain-only or retain-then-delete.

Microsoft’s step guidance is worth cross-checking here: create retention policies in Purview.

When I use PowerShell

I use PowerShell for two reasons: evidence exports and a few settings that are easier to manage at scale.

• Export policy configuration: Connect-IPPSSession, then run Get-RetentionCompliancePolicy and Get-RetentionComplianceRule to capture the effective configuration for your evidence package.
• Mailbox Litigation Hold (exceptions section below): Connect-ExchangeOnline, then Set-Mailbox -LitigationHoldEnabled $true for targeted users (with the right approvals).

Teams retention (chat vs channel), holds, and immutable retain-only rules

Teams trips people up because messages don’t live where you think they do. In practice, I treat it like two streams:

• Teams chats: user-to-user and meeting chats
• Teams channel messages: posts in channels

In Purview, I apply retention through Retention policies with the Teams chats and Teams channel messages locations. That covers the message objects.

Files shared in Teams are different. Channel files land in SharePoint. Chat files usually land in OneDrive. That’s why label publishing to SharePoint and OneDrive matters.

How holds interact with retention (don’t let this surprise you)

Retention is your “normal timer.” A hold is your “freeze button.” If content is under an eDiscovery hold or Litigation Hold, Purview prevents deletion even if a retention policy would delete it.

That means two things:

• Holds can silently extend storage and risk, so I track start and end dates.
• You must document who can place holds and why.

Immutable and retain-only configurations (when the contract demands it)

When I need stronger immutability, I do three things:

1. Use retention where the action is retain-only (don’t auto-delete) for high-risk categories like CUI.
2. Declare content as a record (or regulatory record when required and approved), which limits edits and deletion paths.
3. Reduce admin access, then audit changes to retention settings.

This supports Secure Cloud Architecture and Cloud Management goals, because it reduces chances of evidence loss during incidents.

Produce assessor-ready evidence from Purview (what I capture every time)

For CMMC Level 2, I build an evidence folder that a reviewer can follow without my narration. I capture:

• Screenshots:
  • Retention label settings page (duration, action, record settings)
  • Label policy publish locations (SharePoint, OneDrive, Exchange)
  • Retention policy scope (Teams chats vs channel messages, other locations)
  • Role group membership (Records Management, eDiscovery Manager)
• Exports:
  • PowerShell output from Get-RetentionCompliancePolicy and Get-RetentionComplianceRule
• Audit proof:
  • Purview Audit searches that show policy changes, who changed them, and when
• Change history notes:
  • Ticket or change record that ties the retention change to approval

This is part of Infrastructure Optimization and Digital Transformation work I do for Managed IT for Small Business clients, because controls without proof don’t survive an assessment.

Conclusion and final verification checklist

CMMC Level 2 retention work succeeds when I connect policy, tooling, and evidence. Purview gives me the mechanisms, but my process makes it defensible. If you want help tuning this to your tenant, I treat it as part of Tailored Technology Services, aligned with Endpoint Security and Business Continuity & Security.

Here’s my final checklist before I call it “assessment-ready”:

• Retention schedule approved (contract and legal validated)
• Labels created for CUI and key record categories
• Label policies published to SharePoint and OneDrive (and Exchange if needed)
• Retention policies configured for Teams chats and Teams channel messages
• Record or regulatory record settings applied where immutability is required
• Holds process documented (who, when, why, and off-ramp)
• Roles restricted (Records Management, eDiscovery Manager assigned minimally)
• Evidence captured (screenshots, PowerShell exports, audit events, change tickets)