Practical Pointers for Retention Labels and Policies in Microsoft 365

Once customers have established their compliance strategy and developed a roadmap for enabling data governance controls with Microsoft Purview, there are some helpful things to know before starting to configure them. The four practical pointers shared in this post are based on some of my real-world experiences working with customers to implement retention labels and policies through the data lifecycle management and records management features in their tenants. I’ve learned these things the hard way, so now you won’t have to!

Pointer #1: Some things can’t be changed after the fact. Choose wisely.

This is one of those areas that can catch you off-guard if you’re not paying attention. Planning is key when it comes to compliance in general, but it’s of prime importance once you begin the technical configurations. Below are the Purview features where a name or setting cannot be changed once it’s created:

Backing out of some of these decisions can require a significant amount of work. For example, if there is existing content with a retention label applied and you want to change the label name, you will need to create a new label and re-label the content with custom code.

Pointer #2: Establish a naming convention early on.

Although related to Pointer #1, this tip emphasizes the importance of a naming convention to make both the end users’ and administrators’ lives easier. Whatever convention you settle on, it should be used for names assigned to retention labels, label policies, retention policies and adaptive scopes. Having the naming convention established before you start is important due to Pointer #1 (you can’t change the name after-the-fact!).

Retention label example: When you decide on a retention label name, you are basically making a “land grab” for the name. No other department/division/business area can use that retention label for a different purpose or different retention requirement. A real-world example of this is a statement of work (SOW) in an organization, where the retention requirements may differ by department. If Finance is the first team onboarded to Purview and they take the retention label name SOW, then what does Facilities take when they onboard a few months later if they have different retention requirements? SOW – Facilities? Although that would technically work, a naming convention such as below would provide more consistency for reporting and searching and simplifies end-user training and adoption:

Label Policy and Retention Policy example: It is very helpful if the policy name indicates whether it is a label policy or a retention policy, particularly when using the Policy lookup screen and you need to determine at-a-glance the type of policy from the list displayed. Without a naming convention to indicate this, it is impossible to tell from the Policy lookup screen. In the screenshot below, you can tell by the policy name whether it is a label policy or a retention policy:

Adaptive scope example: Although this is an administrative benefit only, it is particularly important in tenants where there will be a lot of adaptive scopes defined over time. Adaptive scopes are selected when creating label policies and retention policies. Having an easy-to-understand, searchable adaptive scope name will allow administrators creating the policies and updating the scopes to quickly determine the right one.

Pointer #3: Understand retention label priority.

Although there isn’t a retention label priority order you set in the Purview interface like there is for sensitivity labels, a priority still exists. The priority will change depending on if it’s during the retention period or at the end of the retention period. Why is this important? These “rules” will go into your overall retention label plan to ensure the right content has the right label to enforce your retention requirements.

During the retention period, there are 3 rules followed:

Rule #1: Like sensitivity labels, if an end-user manually applies a retention label to a file/email, the label will take precedence over all other methods. This means it will never be overwritten by a default label or an auto-applied label. Ever.

Rule #2: If a retention label has been set as default at a document library or folder level, it will automatically apply a retention label to all documents within except for any documents that have had a manual label already set (Rule #1). If there are nested folders, each with their own default retention label set, the items within each folder will inherit the default retention label set at the closest folder level in the hierarchy above.

Rule #3: An auto-applied label is the lowest priority label as it will only apply a retention label if an item doesn’t already have a retention label applied. If there are multiple auto-apply label policies, the first policy to run and find a condition match will set the retention label assigned to the label policy on a document if it doesn’t already have a retention label applied.

At the end of the retention period, there are 2 rules followed:

Rule #1: If the retention label has been configured to automatically apply a different retention label at the end of the retention period, that label will overwrite whatever retention label is currently on the file regardless of how it was applied to the file.

Rule #2: If the retention period has been configured with a disposition review, and a disposition reviewer applies a different label during the review process, that label will overwrite whatever label is currently on the file regardless of how it was applied to the file.

Pointer #4: You can (almost) make a retention label required.

Making a retention label required is a common request I hear from records managers; however, there is no “required” configuration setting for a retention label. Fortunately, there are a few ways you can come close to making a retention label required:

Option 1: An auto-apply label policy will re-apply a label if the label was removed, no other label was applied, and the item still meets the condition of the policy. Although this doesn’t prevent an end-user from removing the label, the auto-apply label policy will continually re-apply the label each time it runs.

Option 2: A record retention label cannot be removed from a file by contributors of the library; only the site collection admin (including Group owners) can remove it. This effectively makes the record retention label required for members of the site.

Option 3: A regulatory record retention label applied to content is the most immutable option for applying controls. This type of retention label cannot be removed by anyone, including owners, records managers, and even tenant administrators. Due care and attention are required before using this type of retention label in your environment due to the irreversible nature of the control it applies.

Option 4: Custom code running on a library can set a retention label based on conditions you specify in your code. This would always ensure a retention label is applied even if an end-user removes it.

Regardless of the option chosen from above, an important additional control to have in place is auditing and monitoring. If a retention label is removed, that activity is logged in the Microsoft 365 Unified Audit log. In regulated organizations, this type of activity should always be closely monitored and built into operational processes.

I hope you found my four practical pointers helpful as you start to plan your own retention label and policy configurations with Microsoft Purview.