People-First Purview (Strategy): Data Lifecycle Management

Most Purview programs focus on labeling sensitive data, preventing it from leaving the organization, and monitoring risky behavior.

Those are the right places to start.

But there's a part of the data protection conversation that most organizations defer until something forces it...a compliance audit, a legal hold, or a storage bill that finally gets someone's attention.

That part is data lifecycle management.

What Data Lifecycle Management Is

Data lifecycle management (DLM) is the practice of controlling how long data is retained and what happens to it when that period ends.

In Microsoft Purview, that means retention policies and retention labels.

Retention policies define how long content is kept across workloads (Exchange, SharePoint, Teams, OneDrive) and whether it's deleted automatically at the end of that period.

Retention labels give you more granular control. They can be applied to specific content, trigger different retention periods based on classification, and in some cases start the retention clock based on an event rather than a fixed date.

Both answer the same two questions every organization eventually has to answer: how long do we keep this, and what happens to it after that?

Why It Gets Deferred

DLM is uncomfortable to talk about.

Deletion is a harder conversation than protection. Most organizations are comfortable saying "we should protect sensitive data." Far fewer are comfortable saying "we should delete sensitive data when we no longer need it."

It also requires alignment across legal, compliance, HR, and IT at the same time.

That's harder than deploying a DLP policy.

And it requires the organization to define what data it has, how long it's needed, and under what circumstances. That's foundational work a lot of programs haven't done yet, so DLM gets pushed to later.

Later becomes never.

Notes from the field:

The longer an organization waits to address retention, the more data it has to sort through when it finally does. Deferring DLM doesn't reduce the problem. It compounds it.

Where It Fits in a Purview Program

If you've read the People-First Purview series, you already know how the foundational pieces connect. Sensitivity labels identify how sensitive data is. DLP policies control how it moves. Insider Risk Management monitors behavior around it.

Data lifecycle management controls how long that data exists.

Without retention, sensitive data doesn't disappear when it's no longer needed. It accumulates, old contracts, outdated HR records, stale financial data from acquisitions nobody works on anymore. Every piece of data you're still holding is data you're still responsible for protecting.

A well-designed DLM program reduces that surface. Data that's been purged on schedule can't be subpoenaed beyond its required window and doesn't show up in a discovery process it has no business being in.

That's a risk argument, not just a compliance one.

Security Blanket Nature Break

Step away from the dashboards for a moment.

This is a Cinnabar Chanterelle (Cantharellus cinnabarinus), pushing up through dead leaf litter on the forest floor. It grew straight up through a fragment of acorn shell on the way.

The decomposed material around it isn't incidental. It's what makes the whole thing possible. Nothing about that process is accidental or wasted, it's the system working the way it's supposed to.

Data lifecycle management works the same way. The data you clear out on schedule isn't lost. It's the organization reducing what it's responsible for protecting.

The Connection to Sensitivity Labels

In Purview, retention labels and sensitivity labels are separate objects. They serve different purposes and operate independently. But they work better together.

A sensitivity label tells you the data is Highly Confidential. A retention label tells you it needs to be kept for seven years and then reviewed before deletion. Applied to the same document, those two labels give you a complete picture of how that content should be handled from creation through disposition.

The more mature approach is designing your retention strategy to align with your classification model. Different sensitivity levels often have different retention requirements... not always, but frequently enough that it's worth thinking through before you configure anything.

What a Blanket Retention Policy Actually Does

The most common mistake I see is treating retention as a compliance checkbox.

Organizations deploy a default retention policy across all of Exchange or SharePoint, set it to seven years because that's what legal said, and call it done.

That's a blanket hold with a deadline, not a lifecycle program.

It doesn't account for the fact that HR records, financial data, legal contracts, and everyday operational email don't have the same retention requirements. A single policy applied uniformly doesn't reflect that.

It also creates deletion risk. If everything is retained for seven years and then automatically deleted, someone will eventually delete something they shouldn't have.

Without a review stage built into the disposition process, that's a liability. Automated deletion at scale will eventually hit something it shouldn't, such as a record under legal hold, a contract still in force, a file someone in the business is still relying on. The review stage is what keeps the policy from creating the problem it was supposed to prevent.

And when users don't understand why content is being retained or deleted, they work around it. They move files, copy content, or store things somewhere the policy doesn't reach.

Where to Start

Start with what your organization is already required to retain by law or regulation.

Map that to where that data lives in your Microsoft 365 environment and build retention policies around those requirements first.

From there, layer in broader decisions once the compliance-driven requirements are covered, operational data, internal communications, project files.

Retention labels come into the picture when you need more control than a blanket policy provides. Content that needs a different retention period based on its classification. Records that need a formal review before disposition. Scenarios where the retention clock starts from an event rather than a creation date.

Notes from the field:

Start with what you're legally required to retain. Get that right first. Everything else can be layered in once the foundation is stable.

The People-First Angle

Retention and deletion policies have a direct impact on how people work.

If a retention policy deletes content users are still referencing, they'll find ways around it. If a legal hold freezes an entire mailbox instead of targeting specific items, it creates friction for everyone involved, not just the person under hold.

The goal is the same as it is for labeling and DLP: design controls that reflect how the organization operates, not controls that assume perfect behavior and create problems when reality doesn't cooperate.

That means involving legal and compliance early, communicating to users what's being retained and why, and building disposition workflows that include a human review stage for anything with meaningful risk.

The organizations that get DLM right aren't the ones with the most sophisticated retention policies. They're the ones that treat data lifecycle as a program decision, not a configuration task.