You should know by now that the key to managing records in Office 365 is not SharePoint Online, but Retention and Record labels.
Many organizations have retention starting with an event instead of date-based retention. The event could be contract expiry date, closing facility, an employee leaving the organization, and that retention should be X days or Y years after the event happens.
The below image shows how this could be set up in SharePoint Online with HR records for employee 1234 and 4567 with retention: Life of contract + 1 year and destroy. Employee 1234 is terminated 01.05.2020, which triggers the 1-year retention to start for HR files for just this employee. After one year, the HR files are disposed as required for employee 1234. This example is very relevant for ensuring GDPR compliance with requirements for data minimization and storage limitation.
Configuring event-based retention for records management with SharePoint Online requires the following three steps:
Implementing this makes sense in the paper era, but often not always in the digital era. Why not? Here are the three main reasons for minimizing the use of event-based retention for records management with SharePoint Online or in any other content management solutions:
Increased workload for business (SharePoint) users - event-based retention require a unique identifier (AssetID in the above image for records management with SharePoint Online) to identify relevant files. This could be contract number for contractors, facility name or number for facilities, employee number for employees, etc. This unique identifier needs to be added as metadata by users every time a file is stored or a record is declared. It is sometimes possible to automate this, e.g. dedicated library for each facility with facility name or number as default metadata that files automatically inherent, but often it requires users to manually add the unique identifiers every time storing a document or declaring a record.
Increased complexity for Line of Business Application Admin - event-based retention require triggers for the event to happen (event instance in the above image for records management with SharePoint Online). This could when a contract is cancelled, the business decide to close down a facility, an employee decides to leave the company, etc. Sometimes you may know the expiry date when records are declared (e.g. contract expiry date, facility is leased for 10 years), but this is often subject to change (e.g. contract is cancelled, lease is extended) or unknown (e.g. future termination date for employees). This means event-based triggers often has be gathered from 3rd party IT solutions, e.g. get employee termination date from your ERP or HR system, or you have to set up a regular and manual review of events that have happened to trigger the event, e.g. list of people leaving the company.
Increased complexity for Compliance Admin - The above will only work if events are created AND users add the unique identifier (AssetID) as metadata every time storing a file. And if users forget to add the unique identifiers / systems doesn´t force them to add it, then the event-based retention will fail...
The above challenges are not due to limitations with event-based retention for Records Management with SharePoint Online, - you will face the same issues in any content and records management system. What is then a better approach? Here are three things to consider.
Date-based retention based on information lifespan - determine what is the expected information lifespan of the information. If this can be defined, use then date-based retention instead of event-based retention. As an example, if job applications from those that didn´t get hired needs to be deleted when the position is obsolete to ensure GDPR compliance, then consider meeting these requirements with date-based retention plus 6 months or 1 year since most open positions are filled within 6 months or 1 year.
Permanent retention for records with minimum retention requirements - online storage is cheap, and records will only be 5-20% of your overall information. For records with event-based retention and minimum retention requirements (e.g. store for minimum 10 years), consider then date-based retention with permanent retention (store forever). You will then meet your business or legal requirements without relying on event-based retention, but records will be stored longer than required.
Only rely on event-based retention when this is the only way to meet regulatory maximum retention requirements - there will be scenarios where you can´t relay on the first two recommendations. This is often to meet privacy regulations requiring data minimization and storage limitations, e.g. performance reviews and disciplinary warnings/actions has to be deleted X days/years after staff leaves an organization. You should only rely on event-based retention to meet these legal requirements for records to be deleted X days/years after an event happens.
If you want to learn more about modernizing your records management for the digital era, then check out this previous blog post.
Feel free to contact us if you need help changing your event-based retention requirements to date-based retention for implementing this in SharePoint Online or any other ECM systems.
Comments