On the Record: Improving Records Retention with Microsoft 365

There are strict requirements for organizations to retain confidential client, employee and corporate information for a period of time. However, storing such documents for an extended period may introduce additional security and regulatory risk. It is imperative that organizations establish well-defined records retention and records management policies while considering regulatory requirements. Records retention refers to methods and practices used to maintain important information for a required period of time for administrative, financial, legal and historical purposes. It also includes being able to defensively dispose of content, according to its retention schedule, after its retention period has expired.

Microsoft 365 addresses these requirements by helping organizations manage their legal obligations, providing the ability to demonstrate regulatory compliance. It also increases efficiency as items that are no longer required to be retained, no longer of value or no longer required for business purposes are regularly disposed.

With Microsoft 365 records retention capabilities and content type functionality, users can apply rules-based retention policies, driving the records retention period of a document by its records classification and a key date field on the file.

While this functionality has been around for a while, many companies have been slow to adopt it. The barriers I’ve seen most often come down to the following:

• Old habits die hard – The built-in functionality depends on content types and metadata, and users remain accustomed to building out document libraries with deep, complex folder structures.
• Redundancy of metadata – For many documents, the metadata that would be applied tend to all be the same, based on where the document is stored. Users don’t see the value in (and thus avoid) applying metadata to every single document in a folder or library in cases where every single document being stored in that location would have the same value.
• Information timeliness – For many documents, some of the metadata might not be known at the time the document is first created or uploaded and doesn’t become applicable until much later. For example, a records retention schedule for project-centric documents would likely be based on a project end date (plus X years), which would obviously not be known until the project ended. At that point, the project team would have amassed hundreds of documents, making it painful to go back and enter the project end date.
• Rule complexity – The typical definition of a content type-based trigger in SharePoint is based on a simple formula – i.e., contract end date plus three years, employee termination date plus seven years, etc. However, some content types can have much more complex rules. For example, one recent client, an international corporation in the finance industry, was bound by their legal department’s requirement that matter-centric documents needed to be retained for seven years after the court’s final decision could no longer be appealed. But the appellate rules differ, not only based on the type of matter being handled (copyright, labor, bankruptcy, etc.) but also based on the local jurisdiction of where the case was handled. Complex logic such as this could simply not be boiled down to a simple formula.
• Easy to forget – Given the other factors mentioned above, the volume of documents that information workers tend to deal with, and the ease with which a user can bulk upload or sync documents to SharePoint libraries, it can be easy to forget to go back later and tag documents with metadata.

Protiviti’s approach

Protiviti has established a proven framework to address some of these limitations. The central tenets of this approach are:

• Folder-based content types – Just like every other content type inherits from a parent content type, folders can also follow the inheritance model. SharePoint allows users to create folder-content types and define metadata values for that folder. For example, HR might create a “personnel folder” content type, with metadata fields for employee name, hire date, termination date, etc. Throughout the employee’s tenure with the company, all relevant documents related to the employee (resumes, performance appraisals, disciplinary reports, etc.) could be stored in that folder. This allows the HR director to follow the familiar practice of grouping documents by folder while still capturing the necessary metadata to adhere to the corporate records retention policy.

• Content owner field – Every content type following this approach should have a content owner field. The content owner should default to the person who created the folder but should be editable if the original folder creator leaves the company (or if the folder was created on behalf of someone else). The content owner will play a role in the workflow processes described later.
• Records retention trigger date – This field, which may go by other names (i.e., destruction date or expiration date), is the field that will be used to trigger when the folder and its content can expire. For some content types with complex retention logic, this field might need to be set by the content owner manually at the appropriate time. For other content types, it could be calculated using another date-based field on the content type.
• Workflow reminders – Since some metadata might not be known right away, and since users can quickly forget, we suggest a periodic email reminder to update the metadata on relevant folders. The email can be automated via a Power Automate or Nintex Workflow that groups all relevant content by the content owner. Each content owner would get an email once per month (or quarterly or any cadence that makes the most sense for the use case), summarizing all their related content that is still missing relevant metadata. Each item listed in the summary email would include a link to the folder/document, as well as another link to the item’s properties. Items that have all relevant metadata, including the retention trigger date, values can be excluded from this email.
• Workflow for trigger dates – Another workflow, also in either Nintex Workflow or Power Automate, would run based on the applied retention trigger date. There are multiple approaches, depending on each organization’s requirements. For some, the trigger can mean automatically moving content to an archive location or automatic destruction of the content. For other companies, the workflow might simply remind content owners that the retention trigger date has passed. In this latter approach, content owners would get another periodic email summarizing their content that has expired. In a hybrid approach, content owners might get one email as the retention trigger date is approaching, giving them an opportunity to review and update any content and metadata. And then a month later, the workflow could delete the content.

The approach described above helps keep a focus on records retention and timely destruction of expired content. It helps information workers keep their electronic records tidy and ensures that records are cleaned up in a timely manner. This helps reduce an organization’s risk associated with maintaining records for too long.

For most organizations, the volume and complexity of information increases daily, even hourly with email, documents, instant messages and more. Effectively managing or governing this information is important. Utilizing the suite of features in Microsoft 365 and SharePoint to help maintain records retention can automate the administrative processes and keep organizations in compliance with internal policies and privacy regulations.

To learn more about our Microsoft consulting solutions, contact us.