Get Copilot ready(-ish) – with retention policies

You’ve labelled your data, patted yourself on the back, and declared yourself “Copilot-ready.”
Cute.

Except you’re not.

Because if you haven’t touched retention, your beautifully labelled data might still be quietly rotting away, or worse, sitting around forever like digital leftovers in the fridge. And let’s be honest: nobody likes opening that container.

This post walks through what retention policies and retention labels actually do, how they interact with your sensitivity labels, and how to keep your data lifecycle from turning into a compliance horror story.

• Get Copilot ready(-ish) – with Microsoft Purview – Agder in the cloud
• Get Copilot ready(-ish) – with labels – Agder in the cloud

First: understand what retention actually means

Retention is not about “keeping stuff forever.”
It’s about deciding how long something should live — and making sure that when it’s time to go, it actually goes.

There are two main players here:

Both can retain, delete, or trigger reviews.
And both can happily (or unhappily) coexist with your sensitivity labels — depending on how you’ve configured things.

The love–hate relationship: Sensitivity vs. Retention

Here’s the bit Microsoft doesn’t always say loudly enough:

Sensitivity labels protect how something is used.
Retention labels decide how long something stays alive.

They’re separate systems — but when you enable Unified Labeling, they can start to dance together (or step on each other’s toes).

Think of it like this:

In other words: sensitivity = protection; retention = lifecycle.
You need both if you want Copilot to operate safely and within legal boundaries.

Step 1. Map your data lifecycle

Before you start creating policies, do some digital housekeeping (yes, again).
Ask:

• How long should contracts, emails, reports, and chat messages actually live?
• Are you compliant if you store identity numbers in your email or OneDrive?
• What’s legally required to keep, and what’s just corporate hoarding?
• Who needs to approve deletions or retention extensions?

Then, document it, seriously. A one-page “Data Lifecycle Map” beats a 50-page policy no one reads.

Step 2. Build your retention labels

You’ll find them in Microsoft Purview → Data Lifecycle Management → Retention labels.
From here:

1. Create a new label. Give it a clear, boring name (e.g. Finance – 7 years).
2. Choose the label setting:
   • Retain only
   • Delete only
   • Retain and then delete
   • or Mark as a Record (locks down edits)
3. Define the period: number of days/months/years.
4. Decide what starts the timer: created date, last modified, event trigger.
5. Save.

You can then publish the label via a retention label policy, just like you did with sensitivity labels.
Select where it applies (SharePoint, Exchange, OneDrive, Teams), who it applies to, and whether it’s visible to users.

Step 3. Configure retention policies

Now for the broad strokes. Retention policies let you say:

“Everything in Teams chat older than 90 days – gone.”
“All mailboxes – keep for 3 years.”

To set one up:

1. Go to Data Lifecycle Management → Retention policies.
2. Create new.
3. Select locations (Exchange, SharePoint, OneDrive, Teams, Engage if you’re brave).
4. Choose your settings: retain, delete, or both.
5. Name it sensibly (no “Policy-test-final-v3”).

Be careful: Retention policies override local deletions. If someone deletes a file but the policy says “retain for 5 years,” it’s still hanging out in the Preservation Hold library.

Step 4. Make Sensitivity & Retention play nicely

You can absolutely combine both.
For example:

• A Highly Confidential document (sensitivity label) is also a 7-year retention record (retention label).
• When a sensitivity label encrypts a file, the retention system can still “see” metadata, enough to manage retention without decrypting everything.

Pro tip: Retention always wins when it comes to deletion logic.
If you mark something as a Record, even Global Admins can’t casually delete it (and thank goodness).

Step 5. Test before you unleash it on production

Seriously.
Create a pilot site and:

• Apply both sensitivity and retention labels.
• Modify and delete content.
• Check audit logs (Purview → Audit → Activity → Label actions).
• See who can override what.
• Validate Copilot access, because if your retention policy hides everything, your AI will act like it’s blindfolded.

Step 6. Reporting, auditing & proving you did it

Auditors love proof. Microsoft’s done us a favour by adding more audit events for retention actions — creation, change, deletion, expiry, record lock.

Use:

• Audit logs for event-level detail
• Content Explorer to see label distribution
• Activity Explorer to spot who’s labelling what (and who’s not)
• Microsoft 365 Usage reports if leadership wants pretty charts

And please, document your rationale — “we think it’s fine” won’t fly with compliance teams.

Common pitfalls (learned the hard way)

• Setting retention to delete before auto-labelling has finished, oops.
• Forgetting that Teams chat and channel messages have separate retention policies.
• Letting business users publish their own labels “for convenience.” (No. Just no.)
• Believing that retention automatically means backup, it doesn’t.

Final words

Sensitivity labels protect your information.
Retention labels manage its lifespan.
Together, they form the data-governance equivalent of “you can look, but you can’t keep it forever.”

Get these two in sync, and your Copilot won’t just be safe, it’ll be useful.
Ignore them, and you’ll end up with an immortal junk pile that Copilot gleefully resurfaces every time someone asks, “Show me our strategy doc from 2017.”

BONUS: Adding magic aka Auto-Labeling Policy

We need to choose the type of content we want to apply this label to, you can use sensitive info, that will give you the sensitive info types that exists or you can create your own.

You can add it to spesific words, phrases or properties that you set, or we can match trainable classifiers. There is also an option to use it for cloud attachments and sharing links.

For this task, I’m aiming to clear out all emails that are over a month old AND contain identity numbers, so I’m picking the option with sensitive info.

• Next step is to choose GDPR Enhanced

• And then delete all the instances you don’t need.

I deleted all of these and added the choice Norway Identity number

• Ensure you review the remaining sections of the policy to confirm the scope and the locations where it will be active. Since this pertains to email, I’ve selected Exchange Mailboxes as the applicable service.

Always test a policy before you publish it!

When you wrap things up with those final steps, you’ll find all your policies under Label policies.

It’s a great start to chuck out things you really shouldn’t be keeping, both for legal and storage space reasons. But don’t forget, it’s just as important to keep the stuff you definitely shouldn’t toss out!

Extra bonus: event-based retention

For the more advanced crowd: you can trigger retention based on events, like an employee leaving, a contract closing, or a project being archived.
Define events → assign labels → tie them to triggers (via Power Automate or API).
That’s where real compliance magic happens.