Microsoft 365 includes the capability, subject to licencing, to apply retention labels and non-label retention policies to content stored in Exchange mailboxes, SharePoint Online sites, Microsoft 365 Groups and OneDrive for Business accounts.
Non-label retention policies may also be applied to Teams chats, Teams channel (including private channel) posts, and Yammer messages. For Teams chats and posts, these policies apply to the ‘compliance copy’ of the messages stored in a hidden folder in Exchange mailboxes.
Both retention labels and retention policies work against individual items stored in these location, not the containers (e.g., Exchange mailbox, SharePoint document libraries, OneDrive account, Team chats and channels. This means that individual items stored in those aggregations will disappear (when destroyed) leaving the container still in place.
Creating and applying retention labels and policies is a relatively straightforward matter. For records and information managers, knowing where the labels and policies have been applied is more complex, as this post explains.
Creating retention labels and policies
Both retention labels and retention policies are created in and applied from the Microsoft 365 Compliance admin portal.
The Information Governance section is used to create both: (a) retention labels that can be published as label policies, or auto-applied (E5 licence required), and (b) retention policies.
The Records Management section is used to create retention labels, based on a file plan that can be published as label policies or auto-applied (E5 licence required).
The two other tabs in the records management section are (a) Events and (b) Dispositions. The latter area is where basic details or records due for disposition, and records that have been destroyed, are displayed.
Publishing retention labels
Retention labels do not do anything until they are either:
- Published individually or in groups as label policies to all or selected Exchange Online mailboxes, SharePoint Online sites, OneDrive accounts, or Microsoft 365 Groups.
- Auto-applied (with an E5 licence) including: (a) via keyword searches, (b) based on information sensitivity, (c), based on basic classifiers, (d) as part of trainable classifiers or (e) SharePoint Syntex (linked with a Content Type).
Labels cannot be published to or applied to Teams chats or channel posts, or to Yammer content.
Applying retention labels
Retention policies may be published (applied) to either:
- All or selected Exchange Online mailboxes, SharePoint Online sites, OneDrive accounts, or Microsoft 365 Groups.
- All or none of: Teams chats, Teams channel posts, Teams private channel posts, Skype for Business chats, Yammer community posts and chat messages.
Viewing labels, label policies, and retention labels
Once they have been created, the basic details of labels, label policies and retention policies can be seen in the Information Governance and Records Management sections.
Information Governance > Labels
The ‘Labels‘ tab displays all labels that have been created (including via the Records Management – File Plan section, see below), with the following columns (bold indicates what is visible in the default view for this listing – see also below for the list of labels in the Records Management section). The listing (and individual items when clicked) does not include any information to indicate if the label has been published to what label policy, or auto-applied.
- Name
- Status (active, inactive)
- Based on (trigger – when created, last modified, label applied, event, none)
- Is record (if ‘records declaration’ is checked)
- Retention duration (days, months, years or none)
- Disposition type (auto delete, (disposition) review required, no action)
- Reference ID (File Plan detail)
- Function/department (File Plan detail)
- Category (File Plan detail)
- Subcategory (File Plan detail)
- Authority type (File Plan detail)
- Provision/citation (File Plan detail)
- Created date
- Created by
- Last modified
- Last modified by
Information Governance > Label policies
The ‘Label policies‘ tab displays all label policies with the following columns. Clicking on any retention policy displays the status, description, where the policy has been applied (generally, e.g., Exchange mailboxes, SharePoint sites, not specific locations), the labels that have been included, and if a preservation lock has been enabled.
- Name
- Type (Publish, other options may also be listed)
- Created by
- Last modified by
- Last modified date
Information Governance > Retention policies
The ‘Retention policies‘ tab displays all retention policies with the following columns. Clicking on any retention policy displays the status, description, where the policy has been applied (generally, not specifically), retention period and if a preservation lock has been enabled.
- Name
- Created by
- Last modified
Records management section
Records Management > File Plan
The ‘File Plan‘ tab displays all labels (including those created via the Information Governance – Labels section above) with all the columns shown above for the Information Governance labels. Again, there is no information to indicate if the label has been auto-applied or what label policy it has been published in.
Records Management > Label policies
The ‘Label policies‘ tab displays all label policies that have been created. It contains the same content as the Information Governance ‘Label policies’ details above.
How do you know where retention labels and retention policies have been applied?
As noted above, both retention labels (published as label policies or auto-applied, but not to Teams or Yammer) and retention policies are applied to individual items stored in containers (mailboxes, sites/document libraries, OneDrive accounts, Team chats, Teams channels) in the various workloads.
This model, and the ability for end-users with edit rights to change or remove labels on content stored in SharePoint that is not declared as a record or change a label on emails, can make it very difficult to know (for records managers in particular) what has been applied where.
Microsoft 365 does not provide any out of the box option to view where retention policies have been applied (to individual records). There are currently only two ways to know where retention labels have been applied:
- Post facto – via Content Explorer in the Data Classification section (requires E5 licence), for labels only.
- As part of retention planning.
Both of these options are described below.
Data Classification > Content Explorer
For those with E5 licences, the ‘Content Explorer’ area in the Data Classification section of the Compliance admin portal can provide details of where labels (only) have been (or are currently) applied after the fact.
According to the Microsoft guidance Get started with content explorer, (which includes helpful screenshots) ‘Content explorer shows a current snapshot of the items that have a sensitivity label, a retention label or have been classified as a sensitive information type in your organization.’
It also notes that ‘Access to content explorer is highly restricted because it lets you read the contents of scanned files’, via the second of the two roles required to access this capability:
- Content Explorer List viewer: Membership in this role group allows you to see each item and its location in list view.
- Content Explorer Content viewer: Membership in this role group allows you to view the contents of each item in the list.
So, Content Explorer is helpful, but only to know where retention labels have been applied after the fact. And it requires an E5 licence (or E5 Compliance licence add on).
Documenting retention via retention planning
Planning for retention in Microsoft 365 is an essential requirement for records and information managers. It should always be based on regulatory, archival or business requirements for keeping records.
One of the challenges for the retention model in Microsoft 365 is the application of retention labels and/or retention policies to Exchange Online mailboxes, OneDrive accounts, Teams chats and Teams channel posts (including private channel posts). It is a challenge because the traditional recordkeeping model involved copying content identified as records from the create/capture application to a central recordkeeping system where the records would be subject to retention, whereas in Microsoft 365 the reality is that not all records may (or can) be captured.
Retention and disposal authorities/schedules typically do not include coverage for entire mailboxes or OneDrive accounts, let alone Teams content. In response to this, the United States National Archives and Records Administration (NARA) developed the ‘Capstone‘ (PDF) approach for email, whereby ‘final disposition is determined by the role or position of the account user, rather than the content of each individual email.’ Something similar to this model, also for OneDrive accounts and Teams chats and channel posts (both of which have compliance copies stored in Exchange mailboxes), may also be required.
Tackle retention policies first
Retention policies are sometimes referred to as ‘back-end’ or ‘safety net’ policies because they work in the background and help to capture deleted content that needs to be retained for minimum periods of time after which it can be deleted unless a longer retention (e.g., label-based) applies. Retention policies cannot normally be mapped to retention classes because they target entire workloads not specific aggregations in those workloads (e.g., they target all content in SharePoint sites, not the content in the libraries of those sites).
Retention policies do not include any form of disposal review. The content is either destroyed or ‘nothing happens’ (allowing the content to be destroyed after the retention period expires).
Retention policies can be applied to the following parts of Microsoft 365:
- All or selected groups of Exchange mailboxes
- All or selected groups of SharePoint sites
- All or selected groups of OneDrive accounts
- All or selected groups of Microsoft 365 Groups
- All (or none of) Teams chats
- All (or none of) Teams channel posts
- All (or none of) Teams private channel posts
- All (or none of) Skype for Business chats
- All (or none of) Yammer community posts
- All (or none of) Yammer chats
(Keep in mind that Teams chats and Teams private channel posts are stored in the personal Exchange mailboxes of participants, while Teams channel posts are stored in the Exchange mailboxes of the Microsoft 365 Group linked with the Team, BUT Teams retention policies can only apply to all or none.)
Once a decision is made to create retention policies, this detail should be documented separately from Microsoft 365 – in a spreadsheet or SharePoint list perhaps. The following is a basic example of what might be included in that documentation.
- Senior executive EXO mailboxes – 15 years / date modified / do nothing
- All other EXO mailboxes – 7 years / date modified / destroy
- All SharePoint sites – 7 years / date modified / destroy
- M365 Groups – 7 years / date modified / destroy
- All ODfB accounts – 7 years / date modified / destroy (see also note below)
- All MS Teams chats – 7 years / date created / destroy
- MS Teams channel posts – 7 years / date created / destroy
- MS Teams private channel posts – 7 years / date created / destroy
- Yammer user messages – 1 year / date created / destroy
- Yammer community messages – 2 years / date created / destroy
Keep in mind that retention is based on either date created or date modified, so the content stored in these locations will begin to disappear when the retention period expires. This will leave empty mailboxes, empty SharePoint document libraries, OneDrive accounts and empty Teams. Part of the retention planning needs to include a process for destroying those containers once the content inside them has been destroyed – and documenting that destruction also.
For OneDrive accounts, consideration might be given instead to actively reviewing the accounts of departed employees to removing any content considered valuable to another location (e.g., SharePoint) or account, rather than simply leaving it hidden from view for the period of the retention. This would allow much shorter retention after the employee leaves.
Documenting retention labels
Retention labels will typically be based on individual classes in a records retention schedule or disposal authority (DA). Accordingly, it will be useful to have a listing of all classes in a spreadsheet or SharePoint list with the following details as a starting point:
- Retention schedule class ID
- Retention schedule class name
- Retention schedule class description (or abbreviated version).
Retention labels can then be created based on those classes. Every label includes the following details (see also screenshot below):
- A name that should be obvious to end users who may end up having to choose it or know from a glance what it means. For example ‘5.1.1 Financial records – 7 years’.
- A description – same as the original retention class description, or an abbreviated version.
- A retention period. For example, 7 years.
- A trigger. The options are: ‘When items were created’, ‘When items were modified’, or ‘When label was applied’. (Note that triggers may also be based on events, but these should be used sparingly and only after the full implication of using them is understood.)
- An action at the end of the retention. For example: ‘Delete items automatically’, ‘Trigger a disposition review’ (E5 only), ‘Do nothing’. ‘Do nothing’ is a good option for permanent records as it will stop deletion and tag a record making it easier to find later. There are three other options instead of retain: ‘Retain forever’, ‘Only delete items when they reach a certain age’, and ‘Don’t retain or delete items’.
- (Note: When labels are created from the Records Management section, two additional options appear: (a) Mark items as a record and (b) Mark items as a regulatory record. The implications of using either option needs to be understood).
As each retention label is created the following details should be recorded next to the classes in new columns in the spreadsheet or list:
- Retention label name (may be a combination of the ID and name, and retention)
- Retention period. For example, 7 years.
- Retention trigger. For example, ‘When created’, ‘When modified’, ‘When label applied’.
- End of retention action. For example, ‘Destroy’, ‘Review’, ‘Do nothing’
- Declare as a record: Yes/No
- Regulatory record: Yes/No
As labels are published, individually or in groups, this information should be added to columns in the spreadsheet or list:
- Retention policy. That is, what is the name of the policy where this policy has been published.
- Policy location. That is, the location/s were the policy has been applied.
- Date applied?
- Date for destruction. (Date applied plus retention period)
If the label is being used via trainable classifiers, SharePoint Syntex, or otherwise auto-applied, that information should also be added to the spreadsheet or list.
- Trainable classifier? Yes/No
- SharePoint Syntex? Yes/No
- Auto applied? Yes/No
- Auto applied location.
End product – for all retention labels and policies
The end of product of is either a spreadsheet with two workbooks, or two SharePoint lists (one for the retention policies, one for the labels), that describe what retention labels and retention policies have been created and where they have been applied across Microsoft 365.
Records and/or information managers will need to proactively monitor the Microsoft 365 environment and provide advice to IT about the destruction of content and records, as well as the containers in which that content was stored.
There may be other ways to achieve this outcome, but records and information managers need to understand what capability is available (or not) out of the box to make informed decisions.
Featured image source: https://www.pexels.com/photo/architecture-black-and-white-challenge-chance-277593/
Records about the world 