Ask an Architect: 3 Recommended Steps to Building a Data Retention Policy

In this era of “big data,” nonprofit and higher ed institutions are able to use technology to collect more and more data every day. Whether migrating from legacy on-premise systems with decades of data, or engaging with millions of supporters or students in the cloud, institutions collect data for any number of reasons, including gaining insights to better serve their students or meet their social change mission. When the data is clean, relevant, and up-to-date, institutions may also see a significant increase in the return on their CRM investment.

However, organizations and institutions don’t always make data-related policies and procedures priorities. For example, sometimes adding storage to an on-premise system seems inexpensive and easier rather than creating a system and process for deleting it. Alternatively, the organization may give in to the temptation of the ‘one day’ factor, as in ‘one day I might need this data.’

Unfortunately, such approaches by organizations, in addition to potentially limiting optimal use of data, could invite legal and market risks. Over the last few years, the processing of data, especially personal data, has come under ever-increasing scrutiny. With the European Union General Data Protection Regulation (GDPR) having gone into effect this past May, and high-profile cases of data misuse appearing regularly in the news, the need for robust data management practices (covering areas like data retention) are becoming more apparent (learn more about Salesforce and GDPR).

To help your organization make the best use* of the Salesforce platform, support compliance, and avoid usability issues with large data volumes, organizations should consider creating a data retention policy and procedures to implement and enforce that policy.

3 Steps to a Data Retention Policy

A data retention policy is a statement agreed by all the business stakeholders of how long data will be stored by the organization, with some organizations also including details around the if, when, where, and how the data is deleted, anonymized, or otherwise treated. Sounds easy, right? Not always, but getting this policy in place is an important step.

1. Catalogue your data

Create a table that lists the type of data you collect and how your organization uses it. This is probably the most time consuming, but easiest, part of the journey towards a data retention policy. The following is an example but note that there are few one-size-fits-all recipes for what goes in your table, and how detailed to go, as those answers must reflect the needs of your organization

Below is an example, but you may choose to have a different approach, including adding more detail such as format of the data, medium, location, who has access to the data, etc.

2. Review your data and make some critical organizational decisions

Look at each item of data that you have in your catalog and begin to make some decisions.

Should you have this data in the first place? Are there restrictions on how long you may keep the data?

Consider if the data is covered under legal, regulatory or other obligations. Is there a legal requirement mandating or industry best practice expecting you keep certain records for a period of time? Are you required or expected to delete certain records after a period of time? For example in the UK, declaration records regarding a government tax rebate scheme for nonprofits known as “Gift Aid” should be kept for 6 years (source). The principles underlying the GDPR also require organizations only keep data as long as needed to satisfy the purpose for which it was originally collected and/or otherwise processed.

Do you need the data?

Determine whether you actually need the data to accomplish some goal, or whether you are retaining certain data that has no associated defined purpose or use. For example, do you really need to store a Supporter’s date of birth? Well, if you provide special incentives on the Supporter’s birthday, or you need to know when a Supporter moves from Junior to Adult status, then yes. Otherwise, barring some specific reason to the contrary, the date of birth information may not be necessary and you could consider deleting it.

If your answer to these first two questions is no, then skip to step three.

Do you have a plan to use the data you are collecting?

Answering this question can be more challenging, as different people inside your organization may respond differently depending upon their use of or relationship to the data. Much like change management, this is where the hard work is done, nurturing agreement and consensus across your teams.

For example, if you need to provide a supporter with the amount they have donated to your organization for tax purposes, then you likely need to keep enough data to enable you to calculate that figure. Or if you want an instant view of every student interaction with the Bursar’s office, then again you likely need to store the required amount of data. But there may be other fields collected along the way that are not necessary for these limited purposes, and are not used for some other ancillary purpose, e.g., you presumably don’t need to know the supporter’s email or political affiliations to keep a log of donations.

A best practice is to store only that amount of data your organization needs to provide those regular reports, drive useful dashboards, and make critical operational decisions.

When should you consider deleting or archiving data?

Consider that in some cases you may only need aggregated data, rather than specific and detailed records. Bear this in mind as this may require some configuration in Salesforce.

For other data items you will need to develop retention rules that reflect your organization’s unique use cases. For example, considering the following;

As a nonprofit, let’s assume you have millions of contact records for your supporters. You would like to keep all of them, as you believe they could all be potential donors or clients. But are they? Are you most effectively prioritizing your resources? Or are you adding cost/confusion by keeping these records?

Outside of a compliance context, you may be better off only maintaining those supporters who are “active” with your organisation. If so, you could develop a data retention statement that defines that you will only keep supporter details for those who are ‘Active’, where the definition of ‘Active’, includes the following (again, only an example):

• They have a current donation schedule;
• They donated in the last year; and
• They volunteered in the last year, etc.

How you define the parameters is up to you.

The resulting data retention statement may then be “Any supporters that have not been Active, as defined in this policy, in the last two years will be removed/archived.”

That is a bold statement to make, but, again, consider how the effort of your teams might be better used gaining new supporters and interacting with those who are active in your mission.

Once your parameters and decisions are more refined, add your policy decisions and actions to your table, and do this for each data item in your catalog. In Salesforce terms, you could put a retention policy/statement against each object.

One important area to address is the relationships between objects in your data model. There may be minimal value to putting a retention policy on contacts of two years, but you want to keep six years of opportunities. There are ways around that involving changing record ownership, or creating custom roll up objects, but that is for another time.

3. Establish procedures for the removal of data

Once you have a data retention policy that has been approved by your legal and business stakeholders, you need to put your policy into practice. A retention policy that is not implemented or enforced may not mean much. Consider creating a way within Salesforce to indicate when records can be deleted/archived, such as using or adding a simple date formula field, or by looking at the AppExchange for products that can assist.

If you are deleting data, then you may need to build the relevant processes to delete the data from Salesforce, keeping in mind things like the relationships between objects, the recycle bin, and connected applications.

If you want to archive data there are similarly lots of options out there and we’ll walk you though some of those options in the next blog in this series.

While this blog is not a substitute for legal advice,* we hope this helps you get thinking about how to improve your data management to provide a great experience for your constituents, supporters or students. Feel free to ask questions of your attorney for further details.

* The statements provided in this entry solely reflect the personal opinions of its author, and do not constitute official statements from or on behalf of Salesforce. The statements also solely are informational and reflect considerations for organizations when planning data retention programs and/or policies. Nothing in this entry constitutes legal advice or counsel, or provides any guarantees of compliance with a given law or other requirement. Each organization must determine for itself what approach is best for them, and whether that approach satisfies any applicable laws or other obligations. You should contact your attorney to obtain legal advice with respect to any particular issue or problem.