Controlling the ROT in SharePoint Online

Reading Time: 3 minutes

What’s ROT? It’s an Information Management term and it stands for Redundant, Obsolete, and Trivial. It’s content providing no long-term business value but, at scale, is taking up valuable space and cluttering our digital landscape (and search results).

Historically, there’s been a lot of ROT in Shared network and end-user’s drives after many years of use, neglect, and poor digital housecleaning habits. Before migrating this into SharePoint, many organizations focused on cleaning up their content with the lofty goal of only migrating the “gold” (There’s Corporate Gold in them Hills!). Whether this happened or not was usually a factor of the organization’s culture, the end-users’ availability and the migration project timeline.

Even if the cleanup was done and the ROT wasn’t brought into your SharePoint environment, odds are it will end up there again unless we preemptively configure controls to prevent it, particularly if there has been minimal effort to change human behavior around content management.

Assumption: I’m not talking about the more controlled sites in SharePoint. Those types of sites typically have a fair amount of “content governance” on them already and are usually where the final copy of the corporate crown jewels are stored (Projects, Budgets, Contracts, Board content, Executive content, etc.). I’m referring to the plethora of collaboration sites where information workers have free reign to store whatever kind of content they want on.

A big differentiation between ROT content found in legacy file servers and ROT content found in SharePoint is now there’s something we can do about it!

Here’s my 3-step strategy for controlling the ROT on collaboration sites:

  • Step 1: Apply a blanket Retention Policy to Delete
  • Step 2: Configure Retention Labels for team exceptions
  • Step 3: Configure Retention Labels for regulatory needs

Step 1: Apply a Retention Policy to the site to delete content ‘X’ years after the last modified date and publish it to all collaboration sites. What ‘X’ is will depend on your organization’s regulatory requirements and risk appetite. For purposes of this blog post, let’s say that’s 5 years… if something hasn’t been touched in 5 years, there’s a good chance it isn’t relevant anymore. If it is, then it should be labeled with one of the retention labels from Step 2!

You do this be creating a Retention Policy set to delete instead of retain.

Retention Policy

Step 2: Publish Retention labels for information workers to selectively apply to content they REALLY want to keep in their site AND to meet specific regulatory requirements.

You will need to come up with the set of retention labels that will resonate with your end-users to apply to their content if it needs to be retained past the ‘X’ years or requires a disposition review prior to being deleted.

Examples: Business Record, Team Knowledge, etc.

It’s important to include a good description on the label to help information workers decide which label (or if a label) needs to be applied: (image shows the description when you hover over the label name)

Business Record Label.jpgTeam Knowledge Label

You don’t want information workers to get frustrated and start storing their content in other non-sanctioned locations. Best defense against this is periodically follow up with them to determine if they need a new retention label. Over time, you will likely find common label names across many teams.

Step 3: From a regulatory perspective, have the Information Management team periodically follow-up with the site’s information workers to discover any content being stored in the site that should be retained for longer/shorter than ‘X’ years. This is a chance to set up labels to accommodate that content.

If you’re fortunate to have an E5 license in your tenant, configure some auto-apply retention labels to help catch content that may be stored in your collaboration sites that should have a retention different than ‘X’ years.

My thoughts

I like this model since it empowers information worker to decide what’s important to retain for long-term business value from their own teams’ perspective. If they don’t decide, the content will be deleted automatically via the policy. It also ensures any regulatory requirements will be met assuming there is periodic follow-up and/or auto-application of labels over time.

Goodbye ROT.

Thanks for reading.


Credit: Photo by Pierre Châtel-Innocenti on Unsplash


  1. HI. Does content have to be individually labelled for content to be deleted automatically, or does a ‘policy’ apply as a blanket to the site and then individual labelled items can take president should longer retention be required? Is there a way to exclude files types? – i.e. custom files/html/js etc.

    1. Hi Aaron,
      Yes to your first question. Apply a site-wide retention policy and then retention labels as well to apply to content you need to retain longer.
      Second question… you can add a NOT filetype:js at the end of your condition


  2. Hi, me again. Think I’ve found the answer (so ignore my last comment)!.

    I’ve gone into the policy, chosen advanced settings and have a query of “NOT fileextension:md or NOT fileextension:html” – I misread your comment and was looking for a means to upload a file with the excluded types!

    I’ll wait up to the 7 days to see if that works (I think it runs on a Saturday in my tenant, as I got the email notification over the weekend), but sure it will. Thanks.

    1. Hi Aaron, please let me know if it works for you. I’ve done it with NOT filetype:aspx

      Never tried “fileextension”


Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.