A Modern Retention Approach for Office 365 Workloads

Reading Time: 8 minutes

Is your organization in the planning stages of applying retention controls across Office 365? A recent Twitter poll I did revealed the majority of respondents were!

Whether this is representative of the larger population or not is impossible to know, however I suspect there are conversations and planning going on in many organizations right now to determine exactly where and how to begin. To help get you started, I’d like to share an approach I’ve come to embrace for both planning and implementing it.

To apply retention at scale across Office 365 workloads, I believe a Crawl-Walk-Run-Sprint approach is helpful for getting you there. This model fits the implementation of retention controls within Office 365 perfectly, particularly if you’re starting from square one.

What is meant by Crawl-Walk-Run-Sprint? It’s a measured, gradual approach for adopting a technology or new way of doing something to elicit a high-degree of success while allowing for incremental improvements along the way.

TLDR? Skip down to the summary section to see what steps are in each stage.

Before I explain how to apply this model, I first want to summarize my 5-step approach to configuring Retention in Office 365.

---

My Approach

Important to know:

Retention labels are published at a site collection level in SharePoint. Once published, a document library can be defaulted to the label, a library folder can be defaulted to the label, an individual document can be assigned the label or a label can be auto-applied based on content in the document. You can use disposition review on a label. Note: these are not Azure Information Protection labels!

Retention policies are also published at a site collection level but can be defined independent of a label. They apply retention at a site (container) level. End-users are unaware the policy is in effect – they can continue to add, change and delete content. You cannot use disposition review on content only covered by a policy.

Step 1: Define the Crown Jewel Labels

Identify the crown jewels in your organization and define retention labels for each one of them. Publish the labels to the location(s) where the crown jewel(s) will be stored. Typically, I see crown jewel content being well-managed and structured and often lives in a separate site (although it doesn’t have to) and/or library. The crown jewel labels should be well understood by the information workers in your organization who handle them.

Crown jewel examples: Incorporation documents, Patents, Board Meeting Minutes, Executive Meeting Minutes, Contracts, Budgets, Policies, some Procedures, etc.

Step 2: Define the Boilerplate Labels

As you provision SharePoint sites across your tenant (whether it’s a modern Communication site, modern Team site, Microsoft Teams, Groupified Yammer, or Classic Team site), you have a very important decision to make. Will you publish retention labels across all of these sites OR will you leverage a retention policy to apply retention at the site (container) level OR will you do both? If you plan on publishing retention labels to these sites, keep reading this step for my advice on an approach you can take, otherwise, skip this step entirely.

I use the term boilerplate to indicate a standard set of labels to be applied within your organization across all sites in your tenant and therefore should be reusable, time-tested, and well-understood.

By boiler-plating a standard set of labels across your tenant, it will be a consistent experience for end-users. To do this, identify the different types of retention classifications you will typically find within sites’ content across your entire tenant and define labels for each of them. You will want to big bucket the content to come up with these. My recommendation is to come up with a first-cut at these labels thru a joint working session between the Information Management team and the team in charge of end-user adoption. Determining these labels needs to be a joint discussion between these two teams because it’s critical we balance the regulatory retention requirements the organization has against the end-user experience. The intent is to eventually publish these labels to EVERY site in your organization so users will need to understand the meaning of each label to know when to apply it.

Boilerplate label examples:

• Business Record – Retain for 7 years after last modified, then review before delete
• General Team Administration – Retain for 2 years after last modified, then delete
• Convenience Copy – Retain for 1 year after last modified, then delete
• etc.

What is the right number of boilerplate labels? It depends. Not enough labels and the content may not all be covered at a granular enough level and appropriate retention may not be applied. Too many labels and the end-user will become frustrated with too many choices causing end-user experience to suffer. Although there’s no magic number of boilerplate labels you should publish, common sense says it shouldn’t be too high due to a diminishing end-user experience the higher it gets. My recommendation is to definitely keep this under 10. Even better? Under 5.

Step 3: Define the Targeted Labels

Once you have the crown jewels and boilerplate labels defined, there likely will be targeted retention labels you need to apply to content for a specific Site, Group, or Team that doesn’t fit into either of the first two categories for a specific retention requirement. This is where a separate label(s) would be created and targeted to the specific workload(s) that require it. If you find yourself repeatedly publishing the same targeted label to a lot of different sites, then perhaps it’s an indicator it needs to be added to your boilerplate labels.

Targeted label examples: Project documents, Network diagrams, Official system documentation, etc.

Step 4: Define the “Auto-apply” labels

When you define a retention label, you can auto-apply it based on industry sensitive information types as well as words or phrases found in the document. If you have retention labels you can apply this way, definitely do it since it will eliminate the need for end-users having to manually apply a label to a document. This type of label can be applied across all workloads to ensure you are applying retention to the content regardless of where it lives.

Auto-apply examples: Any document with a credit card, customer #, personally identifiable information, etc.

Step 5: Define the “Catch-all” policies

This is where default retention policies fit. If you have chosen not to publish retention labels to all sites across your tenant (boilerplate labels), you will want to publish a retention policy. When a retention policy is defined within the Data Governance section in the Security & Compliance Center, you can apply retention to workload(s) at a higher “container” level (SharePoint site, Office 365 Group). This policy will work silently in the background in conjunction with any retention labels and policies published to the same location to determine the retention for any one piece of content at any given point in time. If content doesn’t have a label applied, it will be covered by the retention policy. It becomes important to understand the hierarchy of rules in the Principles of Retention for those situations where there are multiple policies covering the same piece of content.

You can have numerous retention policies defined in your organization. A great idea is to map policies to different site templates. For example, if you have provisioned a Project Site Template and you have a requirement to retain all project content 2 years after the end of the project, you may want to have a retention policy specific for Project sites and publish it to them. This would ensure all project sites would have the same retention policy applied to content within it.

I really like the container model for applying retention (using Retention Policies) due to the growing number of collaboration sites being provisioned in tenants today. Tenant-wide policies, in combination with boilerplate labels, is one way of ensuring all content in collaboration sites is under retention across your tenant.

It will become very important for information management teams to follow up with collaboration site owners to review their content and to publish more specific labels to their site as required. It’s important to ask team owners the type of content they will be storing in their collaboration site prior to the site being provisioned – this can be done thru a site request form filled out by the site requester and is a good reason to implement a site-provisioning process in your organization!

As of the time of this writing (June 2018), you cannot publish a retention label to Microsoft Teams’ chat and channel conversations. You can, however, publish a retention policy to them, therefore if you need to apply retention to Teams’ chats and channels, you need to use a retention policy.

---

Crawl-Walk-Run-Sprint Model

Let’s get back to the Crawl-Walk-Run-Sprint model and how to apply the results of the above 5 steps against it.

Throughout all stages in this model, a common thread is end-user training. As more capability is introduced at each stage, make sure to educate end-users in your organization so they understand what the labels and policies mean for content they’re working with.

Crawl

Start with (some of) your crown jewels. This content is most at-risk and end-users who work with this content are usually aware of its importance making this a relatively easy place to start. Design the appropriate information architecture for how you’ll store each of the crown jewels in Office 365, create Retention labels for them and publish to the workload(s) they live on whether it’s a SharePoint site, Office 365 Group, or Exchange email.

Note: although you can also publish a retention label to OneDrive account(s), you should never be storing crown jewels there!

Walk

Add the remaining crown jewels if you haven’t done them all in the Crawl phase as well as the targeted labels I referred to above. This is also a great time to test out your boilerplate labels with a small cross section of teams across your organization as a proof-of-concept (POC) to allow for feedback and adjustment(s).

Don’t be afraid to go back to the drawing board if the first-cut at your boilerplate labels didn’t work. It’s important for these label names to resonate with end-users as they will eventually be published to every site in your tenant so you need to get this right!

Run

By now, you should have a good understanding of the Retention Label adoption across your organization for the crown jewel, targeted, and the POC boilerplate labels (Label Activity Explorer – image). Based on feedback you receive from the POC, make any required adjustments to the boilerplate labels and publish them to all remaining sites across your tenant.

Sprint

Now is the time to include any auto-apply labels and default Retention policy(s) you’ve defined. This will ensure ALL content across Office 365 is covered by retention whether or not a retention label has been applied.

---

Summary

Here are the steps in each stage:

• Crawl: publish some Crown Jewel retention labels
• Walk: publish remainder of Crown Jewel labels, Targeted labels, and POC Boilerplate labels
• Run: publish finalized Boilerplate labels to all sites across tenant
• Sprint: publish Auto-apply labels and Retention policies

I’m currently recommending this model with organizations I work with and feel it’s a manageable, pragmatic approach to implementing retention at scale.

Thanks for reading.

-JCK

---

• Credit: Photo by Hunter Johnson on Unsplash
• Credit: Photo by Church of the King on Unsplash
• Credit: Photos by rawpixel.com from Pexels