Posted in Compliance, Electronic records, Governance, Information Management, Office 365, Products and applications, Records management, Retention and disposal, SharePoint Online

Planning for records retention in Office 365

Almost ten years ago, in January 2010, I published a post here about the origins of the statute of limitations. The post had the following introduction:

The retention – and eventual disposal – of records is a common business practice, despite occasional concerns about what gets destroyed. Justice Scalia, in Arthur Andersen LLP v United States (No. 04-368, 2004) said as much about the destruction of records relating to Enron by Arthur Anderson:

‘… we all know that what are euphemistically termed “record-retention programs” are, in fact, record-destruction programs, and that one of the purposes of the destruction is to eliminate from the files information that private individuals can use for lawsuits and that Government investigators can use for investigations.’

Almost ten years on, it still seems an appropriate way to introduce a post about the retention of records, this time in relation to records stored in Office 365.

Bottom line – you need to plan for it, and make sure your legal team is consulted.

Blatant plug for a great book

Before you read further, I recommend you have a look at the comprehensive e-book ‘Office 365 for IT Pros‘. This 1000+ page ebook includes, in Chapter 19 – Office 365 Data Governance, a comprehensive description of how to create, apply and manage retention policies in Office 365.

What do we mean by retention?

The retention of records is generally based on business, legal or regulatory requirements to keep certain records for a minimum period of time. In the case of government records, there may also be an archival requirement.

The retention period may relate to or be based on a statute of limitations that governs when potential legal actions expire. For example, simple contracts generally need to be kept for a minimum of six or seven years (depending on jurisdiction after they expire. More complex contracts (including deeds) may need to be kept for much longer.

Records that need to be retained should not be deleted and must remain accessible for the period of time during which the integrity, authenticity and reliability of – and often the context for – the retained records must remain inviolate.

Retention is not IT back up or (or for) disaster recovery

Retention management is not about IT backups or ‘archiving’, or disaster recovery programs. These activities are focused more on the ability to recover data and records.

On-premise to online – a different paradigm

Many organisations have (or should have) records retention schedules, also known as disposal or disposition authorities. Records retention schedules and authorities define what needs to be kept and for how long.

Most records are managed in similar ways:

  • As paper (usually printed from digital records), stored in files and/or boxes. These records may be tracked in a database.
  • As digital records, uploaded to a third-party electronic document management system (EDMS), while leaving the original records stored in Exchange mailboxes or File Explorer.
  • As entire business systems (with little thought given to individual records).
Goonellabah_2.jpg
An example of old-style paper file storage. These records are around 20 years old and are well overdue for disposal. 

Into the on-premise mix:

  • MRM policies may be enabled on Exchange mailboxes, allowing end users to apply retention tags to emails. An archiving policy may be in place as well.
  • Individual user mailboxes and ‘home drives’ may be retained for a period of time after the user account is deactivated.
  • There is a backup regime.

Many of the options above will not, or may not, exist (at least in the same way) in Office 365.

On the other hand, Office 365 now includes a range of records retention options that can be used to better manage retention.

Why you need a plan for retention in Office 365

Implementing Office 365 retention policies without a good plan to transition from the on-premise environment, is fraught with potential failure, potential confusion, uncertainty, and legal risk.

To quote from page 882 of Office 365 for IT Pros:

‘… it is wise to take time to chart out how retention will work across the tenant for all workloads before you create any policies. Fools rush to implement retention without thought!

A good starting point is to contact the records management team and get a copy of the organisation’s records retention schedules or authorities to understand what needs to be kept and for how long and also – importantly – where the records are currently stored.

Retention options in Office 365

In simple terms there are two types of retention that can be applied to records in Office 365. The following paraphrases parts of chapter 19 of the book Office 365 for IT Pros.

Explicit (visible) retention policies

This option involves (a) creating retention labels that define a retention period (and if a disposition review is required), (b) publishing the labels as retention policies to specific Office 365 workloads, and (c) applying them manually (including via PS scripts) to content that needs to be retained.

Retention labels published as explicit retention policies can be applied (including automatically, in certain circumstances and/or with an E5 licence) to the following workloads

  • Exchange email (all/select)
  • SPO sites (all/select)
  • ODfB accounts (all/select)
  • O365 groups (all/select)

ExplicitRetentionPolicy.JPG

Implicit (invisible) retention policies

This option involves (a) creating retention policies (that do not include a disposition review) and then (b) applying them to all or specific Office 365 workloads.

Implicit retention policies can be applied to:

  • Exchange email (all/select)
  • SPO sites inc O365 Group sites (all/select)
  • ODfB accounts (all/select)
  • O365 groups (all/select)
  • Skype for Business (specific users)
  • Exchange public folders (all)
  • Teams channel messages (specific teams)
  • Team chats (specific users)

The first four workloads are the same for both types. Which one should you choose – explicit or implicit?

ImplicitRetentionPolicy.JPG
Implicit retention policy

Keep in mind that explicit policies take priority over implicit policies.

Retention policy limits

Both explicit and implicit retention policies have specific limits. You can create:

  • Up to 10 organisation-wide retention policies. For example, all mailboxes, all OneDrive accounts, all SharePoint sites, all Office 365 Groups. 
  • Up to 1000 narrow/specific retention policies. Each of these can point to up to 100 sites, 100 ODfB/O365 group accounts, and 1000 mailboxes. 

These limits, and the difference between explicit and implicit, show why planning for retention is essential.

Questions you might want to ask

Some questions to consider as part of the planning process:

  • For Exchange mailboxes, is it better to have (a) a single implicit policy to keep all  mailboxes for x years, or (b) a single implicit policy that targets only certain mailboxes (e.g., senior managers only), or (c) multiple explicit policies that end-users can apply? What do you do now with Exchange on-premise? Do you journal emails? How will you do that if you go completely online? Could a single implicit policy achieve the same outcome as backing up mailboxes?
  • For OneDrive accounts, is it better to (a) have a single implicit policy to keep all ODfB account for x years, or (b) rely on the ODfB admin storage setting to keep the content after an account becomes inactive (default is 30 days), or (c) have an explicit policy that end users can apply themselves?
  • For SharePoint sites, is it better to (a) have a single implicit policy to keep all SPO sites for x years, or (b) have a single implicit policy applied to up to 100 sites at a time, or (c) create multiple explicit policies that end-users can apply?
  • For Office 365 Groups, is it better to (a) have a single implicit policy, or (b) focus instead on MS Teams channel retention and/or (c) a retention policy for the associated SharePoint sites? Do you have AD premium where Group expiry can be implemented? If yes, should you enable or disable it?

And for all of the above – how will you keep track of what has been applied where?

Recommendations

My suggested recommendations would be:

  • Exchange mailboxes. If the organisation keeps back ups of on-premise mailboxes so these can be recovered after a period of time, remove the default MRM policies and create a single organisation-wide implicit retention policy.
  • OneDrive for Business. For similar reasons to the Exchange mailboxes, create a single organisation-wide implicit retention policy to retain content in user accounts for a given period of time (say, 7 years). Also change the default storage period from 30 days to the same period of time.
  • SharePoint Online. My sense is that a single implicit retention policy for all SharePoint sites is unwise. Retention options should be considered when sites are created. For example, try not to mix (or allows users to mix) content that may have different retention requirements in the same document library – aim to apply the aggregation to the highest level of ‘aggregation’ – site or library. Create labels for and publish a small number of specific explicit retention policies (mapped to the organisation’s records retention schedule). Create one or more implicit policies for specific groups of sites (for example, all inactive project sites). Whatever model you implement, ensure you know if you need to record what was destroyed, including unique metadata from document libraries.
  • Office 365 Groups. The SPO part of Groups can be covered by the SPO retention policy, the email by the Exchange mailbox policy. You may need to consider if you need to create teams chat or channel retention policies.

What happens at the end of the retention period?

So far this post has raised questions about the type of policy you might apply to different workloads.

But what happens when the retention period ends? Should you allow records to be deleted without any kind of disposition review, or check first? This single point may be a key factor in your decision around what type of policy to create and implement, and where.

Some questions to ask:

  • Is is appropriate in your environment for end users to destroy business records by applying a policy?
  • Should someone review the content before it is disposed of?
  • Do you need to keep the metadata associated with content stored in SharePoint document libraries? If yes, where is it going to be stored?
  • Do you need a permanent record of what was destroyed?
  • What do you do if you dispose of something that should not be disposed of?

The answers to these questions may differ depending on the workload to which the retention policy has been applied and whether the retention policy is explicit or implicit.

What does a retention plan look like?

Pages 880 and 881 of Office 365 for IT Pros has an excellent model plan for retention in Office 365. The following (slightly edited) points should be documented for every retention policy that is created and published.

  • Name: It seems obvious, but naming can be important especially for explicit policies. Consider, for explicit policies, adding the retention period to the name, e.g., ‘Company Financial Records – 7 years’.
  • Purpose: What is the purpose of the policy?
  • Retention settings: How long should the content be kept for? Should this be based on when it was created, modified, or when the label was applied? Should there be a disposition review? Who will review the content when it is due for disposition?
  • File Plan: Explicit retention policies can be mapped to a file plan and thereby linked to the retention schedules. If they do, what part of the File Plan should the policy map to?
  • Type: Will the policy be implicit (invisible to users) or explicit (visible to users)?
  • Scope: What Office 365 workloads will this policy cover?
  • Broad or Narrow: Will this policy be applied across an entire workload or to specific mailboxes, sites, accounts? If an explict policy uses retention labels, what are those labels?
  • End of retention: What should happen when the retention period expires? For example, does the metadata need to be kept, should a record be kept of what was destroyed?
  • Lock (optional): Is the content that comes under the scope of the policy considered to be a formal record for the company and if so, is a preservation lock needed? (This option requires additional PowerShell work)

Joint planning is a must

Your organisation is almost certainly going to have business, legal or regulatory requirements for keeping records.

Records managers know how to interpret and apply these to records, and what to do when records reach the end of their retention period. It’s a good idea to consult with these experts, and with your legal team.

It would be a very brave IT shop that unilaterally applies retention policies to records stored in Office 365 without reference to or consultation with records managers, legal teams, or records retention schedules.

Author:

I am an experienced information management professional based in Melbourne, Australia. I have had close to 40 years of practical working knowledge across the full spectrum of information, records and content management issues, and direct and practical experience with contemporary and emerging business and information and enterprise content management systems. My product knowledge includes SharePoint 2010/2013/Online and OneDrive (SharePoint Administrator), Office 365 (including as a Global Administrator), Yammer, Sway, TRIM Context (R6.2 & 7.1), ECM Documentum, Alfresco Share; and other online systems. www.andrewwarland.com.au

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s