People-First Purview (Technical): Data Lifecycle Management

The strategy post covered why data lifecycle management gets deferred and what it means for your risk posture. This post is about how to build it.

If you are standing up a retention program for the first time, this is where to start.

Retention Policies and Retention Labels Are Not the Same Thing

This is the first thing to get clear before touching any configuration.

Retention policies apply broadly. You assign them to workloads (Exchange, SharePoint, Teams, OneDrive) and they define a default retention period for everything in scope. They are your baseline.

Retention labels apply specifically. They can be applied manually by users, recommended by Purview, or applied automatically based on content. They can also trigger different retention periods, start the retention clock from an event rather than a creation date, and mark content as a record that requires disposition review before deletion.

The relationship between them matters. If a retention label and a retention policy conflict, Purview follows the principle of most restrictive retention, meaning the content is kept for whichever period is longer. That covers the retention side.

Deletion is more complicated. When multiple settings have conflicting delete actions, a label's delete action takes precedence over any retention policy's delete action. Scoped policies take precedence over org-wide policies.

Only if neither of those rules resolves the conflict does the shortest deletion period apply. Understanding that behavior before you configure anything saves a lot of troubleshooting later.

Start with policies. Layer labels in once the baseline is solid.

Build Your Baseline With Retention Policies First

The first configuration decision is scope.

Retention policies in Purview are assigned to locations. Exchange mailboxes, SharePoint sites, OneDrive accounts, Teams messages, and Teams channel messages are all configured separately. That matters because your retention requirements are probably not the same across all of them.

Before you configure a single policy, get three things clear.

First, what is your organization legally required to retain and for how long? That answer drives your minimum retention period. Seven years is common for financial records in the US. Your legal or compliance team should have a records retention schedule. If they do not, getting one in place before building policies is worth the delay.

Second, do you need to retain, delete, or both? A retention policy can retain content for a period and then do nothing, delete content after a period with no retention requirement, or retain and then delete. Most organizations start with retain-only until they are confident in what they have.

Third, are there workloads you want to exclude? Broad policies applied to all of Exchange or all of SharePoint catch everything, including content people are actively working with. Scoping to specific groups or sites first gives you more control during rollout.

Notes from the field

A retention policy applied to all of Exchange on day one is a significant commitment. Start with a scoped pilot (a department, a site, a group) before going broad.

Adaptive Scopes vs Static Scopes

When you configure a retention policy, you choose between static and adaptive scopes.

Static scopes are explicit inclusions or exclusions. You specify the mailboxes, sites, or groups the policy applies to. Simple to understand, but they require manual updates when your organization changes.

Adaptive scopes use Entra ID attributes to define membership dynamically. A policy scoped to "all users in the Finance department" automatically includes new Finance hires and excludes people who transfer out. That is the right approach for most production environments, but it requires clean, reliable attribute data in Entra ID.

If your Entra ID data is inconsistent or incomplete, static scopes are safer to start with. Adaptive scopes amplify whatever is in your directory. Good data makes them powerful. Bad data makes them unpredictable.

When to Introduce Retention Labels

Once baseline retention policies are in place, retention labels let you handle exceptions and higher-stakes content.

The two most common use cases in a first program:

Records and disposition review. Content that needs to be treated as an official record, such as contracts, regulatory filings, board minutes, can be marked using a retention label. This also unlocks disposition review, which triggers a formal review workflow before content is deleted at the end of its retention period rather than automatic deletion. Records management configuration in Purview, including event-based retention and disposition review, is covered in a separate post.

Exceptions to the baseline. If your default Exchange policy retains for seven years but executive communications need to be retained for ten, a retention label scoped to the right group handles the exception without rewriting the base policy.

One constraint that affects auto-apply in particular: an item can only have one retention label at a time, and auto-apply policies generally will not override a label that is already applied. If you are planning to auto-apply labels based on sensitive information types, audit your existing label coverage first. Content that already has a label will not get the auto-applied one, regardless of whether it matches the conditions.

What I do not use retention labels for in a first program is trying to replace retention policies entirely. Labels require either user action or automation to apply. Policies apply automatically. Use each for what it does well.

How Retention Labels and Sensitivity Labels Work Together

Retention labels and sensitivity labels are separate objects and operate independently. But they can be applied to the same content, and in a mature program they often are.

A sensitivity label tells Purview how sensitive the content is. A retention label tells Purview how long to keep it. Neither label knows about the other. There is no native dependency between them.

That means you have to design the relationship yourself.

The question worth asking during design is whether your sensitivity classifications have implied retention requirements. Highly Confidential content often does. If your classification model already defines what falls into each sensitivity tier, mapping retention requirements to those tiers is a reasonable starting point.

Auto-apply retention labels based on sensitive information types is one way to create that connection technically. If Purview detects content that matches a sensitive information type (SSNs, financial account numbers, health records), it can automatically apply a retention label. That keeps the user experience clean and reduces reliance on manual labeling for compliance-driven retention.

There is one other connection worth knowing about. A retention label can be used as a condition in a DLP policy. If you want to prevent documents with a given retention label from being shared outside the organization, you can configure that directly in DLP without building a separate detection rule. If your sensitivity classifications already map to retention requirements, that pairing can do a lot of work with minimal configuration overhead.

A Note on Teams

Teams retention behaves differently than Exchange and SharePoint, and it catches people off guard.

Teams channel messages and Teams chats are separate locations in Purview and require separate retention policies. A policy applied to Exchange does not cover Teams chats.

Private channel messages have historically required separate handling, but if your tenant completed Microsoft's 2025 private channel message migration, private channel messages are now covered under the standard Teams channel messages location. Check your tenant migration status before building separate policies for private channels.

Teams also uses a different underlying storage model. When a Teams message is subject to retention, a copy is stored in hidden mailbox folders in Exchange. Deleting a message in Teams does not necessarily delete it from the retention copy.

If Teams is a significant communication channel in your organization, get clarity on the retention requirements for Teams content before configuration and test the behavior in a pilot before rolling out broadly.

A Note on Licensing

Retention policies and manually published retention labels are available at Microsoft 365 E3. If a baseline program is all you need, E3 covers it.

Most of the features that make retention programs more powerful (auto-apply policies, adaptive scopes, and anything in the Records Management solution) require E5 or the Microsoft Purview Information Protection and Governance add-on. Licensing details change, and the line between E3 and E5 features shifts. Verify against Microsoft's current licensing guidance before you start building.

Where to Start if You Have Nothing

If you are starting from zero, here is the sequence that works.

First, get a copy of your organization's records retention schedule. If one does not exist, work with legal or compliance to define minimum retention periods for your most common content types before building anything in Purview.

Second, configure a scoped retention policy for your highest-priority workload. Exchange is usually the right starting point. Scope it to a pilot group, validate the behavior, then expand.

Third, identify content that needs to be treated as a record and configure retention labels for those content types. Start with the obvious ones: contracts, regulatory submissions, board minutes.

Fourth, set up disposition review for anything you are marking as a record. Get the content owners identified and confirm the review process before the queue goes live.

Retention labels, event-based retention, and auto-apply policies can all come later once the baseline is working and validated.

What Not to Do

Do not deploy a broad retention policy across all workloads on day one without scoping and testing first. The blast radius of a misconfigured retention policy is significant.

Do not mark everything as a record. Records cannot be modified while the label is applied. If users need to edit content as part of normal work, locking it as a record breaks their workflow.

Do not configure automatic deletion without a disposition review stage for anything with legal or compliance significance. Automatic deletion without review is a liability, not a control.

Do not skip the conversation with legal. Retention is one of the areas where IT and legal have to be aligned. A technically correct configuration that does not match your legal obligations is not a retention program. It is a liability with good documentation.