A New Age of Data Governance
Data governance has always been an important part of responsible data stewardship, and in the era of AI, there is a new sense of urgency for organizations to get their digital house in order. Here are a few Practical 365 posts that address some ways organizations can do this:
- Microsoft 365 Archive Could Help Companies with Digital Debris (practical365.com)
- Create a SharePoint Online Files Report with the Graph PowerShell SDK (practical365.com)
Establishing and executing a holistic data governance program across Microsoft 365 requires an integrated suite of tools (either third-party products or Microsoft Purview) each addressing a part of data governance. One of the first areas of focus I see organizations working on is the classification and protection of their sensitive information using Purview tools such as information protection and data loss prevention. Although those are great starting points, another important aspect of a data governance program is data retention and deletion.
IT professionals helping implement Purview retention and deletion controls (Data Lifecycle Management and Records Management) across their tenants should understand how they work before configuring them in a production tenant. For IT professionals who are more familiar with data protection, this can be unfamiliar territory.
Why is Data Retention and Deletion Important?
Data retention and deletion are important for 2 main reasons:
Meeting Compliance Obligations: There is often business, regulatory, and/or legal requirements stating an organization must retain certain types of records (files, emails) for a defined period. For example, a US state retention schedule may require all government agencies to retain financial records for 7 years. For organizations storing these records in SharePoint and Exchange, this requirement can be satisfied by defining a retention label in Purview Data Lifecycle Management (E3) or Purview Records Management (E5) to retain for 7 years, publishing it to Exchange and SharePoint, and applying it to the individual financial records found there.
This is an example where knowledge of the differences between Purview retention labels and retention policies is necessary to identify which one is needed to meet the requirement. In this example, a retention label is required rather than a retention policy because the individual financial records must be labeled within the Exchange mailbox or SharePoint site rather than the entire mailbox or site. A retention policy applies to all content in the mailbox or site.
Preventing Over-retention: Deleting content that does not need to be retained for business, legal, or regulatory reasons stated above can help to reduce your overall data footprint. This results in decreased exposure during data breaches and reduced storage costs. Records managers often refer to this type of content as Redundant, Obsolete, and Trivial (ROT). In general, it isn’t providing any value to an organization by keeping it and can clutter search results. Of these, obsolete content is the one that will have the biggest impact on data quality across your tenant, something particularly important for Copilot for Microsoft 365. Preventing over-retention can be met with retention policies with a delete action defined in Purview Data Lifecycle Management.
There are certainly other ways to stop Copilot from accessing content (New Sensitivity Label Setting to Block Access to Content Services for Office, Restricted SharePoint Search); however, this should not preclude you from also applying retention policies to proactively clean up ROT content across Microsoft 365 locations.
Understanding Retention Labels
As an IT Professional, if you’re already familiar with Purview information protection (sensitivity labels) and need to learn Purview data lifecycle and records management (retention labels), knowing the tactical differences between the two label types is a great place to start.
Here’s a sample of six key differences:
| I Want to Default the Label | |
| Sensitivity Label | Retention Label |
| You can assign a default sensitivity label for: – Users and groups (E3) -Containers (Teams, M365 Groups, SP sites) (E3) -SharePoint document library (E5) In addition, a different default can be set for files, emails, meetings, sites and groups, and Fabric and Power BI content. | You can assign a default retention label for a SharePoint document library, folder, or document set (E5). You cannot set a default retention label for a user or group. The closest way to do this is to create an auto-apply retention label policy targeting a user location for all content they create. (E5) |
| I Want to Make the Label Mandatory | |
| Sensitivity Label | Retention Label |
| You can make a sensitivity label mandatory in a sensitivity label publish policy. In addition, you can have different mandatory labels for files, emails, meetings, sites and groups, and Fabric and Power BI. (E3) | You cannot make a retention label mandatory. The closest way to make a retention label mandatory is to apply a record retention label since it can only be removed by a site collection admin/site owner. (E5) |
| I Want to Recommend the Label | |
| Sensitivity Label | Retention Label |
| You can recommend a sensitivity label to the end-user while they are working with the content (client-side) by configurating conditions for recommending a label within the sensitivity label definition. An end-user can either accept or reject the recommendation. (E5) | You cannot recommend a retention label to end-users. |
| I Want to Automatically Apply the Label | |
| Sensitivity Label | Retention Label |
| You can auto-apply a sensitivity label with an auto-labeling policy (service-side) and with an auto-apply configuration within the sensitivity label (client-side). (E5) A retention label can be a condition to apply a sensitivity label in SharePoint using this KQL in an auto-labeling policy: Compliancetag:<display name of retention label> | You can auto-apply a retention label with an auto-apply retention label policy (service-side). There is no mechanism on the client-side to auto-apply a retention label. (E5) A sensitivity label can be a condition to apply a retention label using this KQL in an auto-apply retention label policy: InformationProtectionLabelId:<guid of sensitivity label> |
| I Want to Require a Justification for Changing the Label | |
| Sensitivity Label | Retention Label |
| Only when downgrading. There is a defined priority number for each sensitivity label that can be used to require a justification when downgrading to a lower group parent level. | You can’t. There is no defined priority number for each retention label and no option for justification exists when changing the label. |
| I Want to Make the Label Multilingual | |
| Sensitivity Label | Retention Label |
| Multiple languages are supported for sensitivity labels via PowerShell. You can also use the Microsoft Translator service to set both the label display name and tooltip in different languages. | There is no multilingual option for retention labels. |
Knowing the differences above can significantly affect your approach when implementing retention labels across your tenant.
Want to Learn More?
Interested to learn more about data retention in Microsoft 365 from an IT-Pro perspective? Come to my session, Why You Need to Care About Retention in Your Microsoft 365 Tenant, at The Experts Conference this October where I’ll demonstrate how retention works across Exchange, SharePoint, and Teams, missteps to avoid, and key things to know before starting.
