GDPR: What? I don’t have to delete data.
Handling “Right to be Forgotten” and the other 5 GDPR requests
Of all the areas of GDPR, Article 17, the “Right to be Forgotten” seems to get the most exposure. Understandably, because the implications are huge. You need to be able to delete a customer’s data EVERYWHERE it is hiding in your systems including backups and archives.
Where is that data?
The first challenge is identifying where all this data is held — building a data inventory.
But don’t think of this as a cost of GDPR. This is an opportunity to rationalize and delete data sources. How much data could be migrated to the existing Salesforce objects or to create new objects? And then delete the spreadsheets and obsolete apps. Then you can benefit from the Salesforce platform — control, encryption, backup, extensibility, data privacy. All of which are required for GDPR compliance, but are also critical for a well-run marketing business.
You can also set policies that certain apps, like event and video conferencing, only hold transient data and the data is deleted. This can be when the app closes, at the end of the day, or after the transfer to Salesforce. That way you do not have uncontrolled personal data.
A recent Financial Times article was quite disparaging about the loose and ambiguous drafting of the GDPR, but had a great quote from Jason du Preez CEO of Privitar — “GDPR is a massive shift and creates an opportunity for businesses to compete on the basis of privacy”.
Auto generate data inventory
So, back to the Right to be Forgotten and building that data inventory. The key areas are the platform (Sales, Service & App Cloud and managed packages), Marketing Cloud and Pardot. One approach is to copy and paste field names into a spreadsheet. Aaaaghh!!
Fortunately, Elements.cloud has built an affordable app that will sync all Salesforce platform config (metadata), Pardot and 3rd party apps into a Ref Model, which is a nested list.
Once you have the Ref Model you can categorize the fields as Personal Data, Special Personal Data and add all the other field information that is required by GDPR such as retention period, sources and destinations. All other fields should be set to Not Applicable, which can be done with a single click.
As the Ref Model syncs, it will look at the field names and types and perform some categorization for you, marking some fields as Not Applicable and others as Unassessed — Potential. The nightly sync will notify you of any new or changed objects and fields.
You also get a ton of other useful features which are really helpful when understanding your data or documenting your Org;
- Org analytics
- where are fields used
- which profiles and permission sets have field access to data
- linking to documentation and process diagrams
- Prod and Sandboxes comparison
Coming soon: field population “think FieldTrip” — just because a field exists doesn’t mean it holds any data!!
The initial setup for Salesforce platform takes less than 10 minutes. The sync depends on the size of your org; a dev org takes 2–3 mins and client with 65k items takes 2–3 hours. The Pardot sync is very quick as there is often less configuration data.
The key thing is: it is way quicker and more sustainable than building and maintaining spreadsheets!!!
So now what?
You can run reports that give you a picture of where Personal Data is held. You can export the report to XLS. You can now use this to plan how to respond to a Right to Erasure “Right to be Forgotten” request. But also the other requests such as Subject Matter Access “where do you hold my data”. The notifications of field changes can ensure the plan stays current as the Org changes and matures.
Facebook and Cambridge Analytica have heightened consumer’s awareness of how their data is manipulated, shared and misused. Just a few months ago, people would have told you that Cambridge Analytica was a font. Once people learn that they can simply email you a Right to Erasure or Subject Matter Access request and you need to respond with 30 days, you could be hit with a barrage of requests. These could be genuine requests or a malicious attempt to bog down your operation by a competitor or action group. Regardless, your plan needs to be able to handle these requests at scale and must consider not only live data but also those copies you’re storing in your data archives.
To delete or not
It is not as simple as just “delete Contact”. There are some related records you will want to keep. There may be legal reasons why you cannot delete the customer data. You may want to keep an anonymized copy so you use it to develop trend data. There are provisions in GDPR (Article 17–3) to allow for this. However, “it is too hard” is not a valid reason.
GDPR Article 17–3
Paragraphs 1 (erasure) and 2 (data made public) shall not apply to the extent that processing is necessary: (a) for exercising the right of freedom of expression and information; (b) for compliance with a legal obligation which requires processing by Union or Member State law to which the controller is subject or for the performance of a task carried out in the public interest or in the exercise of official authority vested in the controller; (c) for reasons of public interest in the area of public health in accordance with points (h) and (i) of Article 9(2) as well as Article 9(3); (d) for archiving purposes in the public interest, scientific or historical research purposes or statistical purposes in accordance with Article 89(1) in so far as the right referred to in paragraph 1 is likely to render impossible or seriously impair the achievement of the objectives of that processing; or (e) for the establishment, exercise or defence of legal claims.
And remember you have 30 days to report back to the person with confirmation of the data you have deleted or the reasons why you cannot delete it. GDPR require you to prove that the treatment of these requests follows a managed process.
This is also true of all 6 GDPR requests:
- Right to Subject Access Request (Article 15); a customer can ask for a report of everywhere you hold their data
- Right to Rectification (Article 16); a customer can ask you to update data that is inaccurate
- Right to Erasure (Article17); “right to be forgotten”, so a customer can request that you delete all data you hold on them. There are provisions to allow you to hold their data for certain valid reasons, such as the need to hold it by law, but it also allows for anonymization
- Right to Restriction of Processes (Article 18); a customer can request that you do not ‘process’ their data because it is incorrect, there is no reason for you to hold it, or they have raised a request to object
- Right to Receive Personal Data (Article 20); a customer can request that their data be provided to them in “structured, commonly used and machine-readable format” so that they can pass it to another company
- Right to Object (Article 21); a customer can object to your holding their data because you have no reason to and that it be deleted
The complexity of these requests lies in the relationship between the Contact, Lead and any related objects. It’s a non-trivial activity: data is not just in records but also in attachments, emails and text fields. Maintaining and navigating these relationships is critical not only to the integrity of your data, but also to achieve GDPR compliance. Ensuring this valuable connection can be greatly simplified through metadata backup and restore with an app such as OwnBackup.
Manually sifting through these records will not only overwhelm Customer Support teams, Salesforce Admins or IT teams, but it will inevitably introduce human error. Nothing does boring, repetitive work as well as an automated process. The options are to custom develop these processes or use an app like Odaseva.
Deletion and archiving at end of production system retention period
Parallel with this is the deletion and archiving of production system data because it has reached its termination date, based on the policies you set in the data dictionary. I hope you’ve been backing up this data all along, but should this data now remain in your backup archive? If so, for how long? What is data lifecycle strategy and how are you going to implement it. It will be triggered by the retention period for that field which is held in the data inventory.
A deletion from production could also be triggered by the retention period on a data privacy permission that is connected to a contact or lead. When a data permission is added. e.g. Came to stand at DF17 on 8 Nov 2017 it will have a retention date based on the policy for that type of interaction. Subsequent data permissions may extent the retention date. e.g. Signed contract on 3 Jan 2018. Once the retention date is reached then the contact or lead record should be deleted, subject to all the earlier points in the section “To delete or not”.
Removing data from production systems may not only help with regulatory compliance, it has the added benefit of reducing overall dataset size which can streamline production system performance. It’s important, however, that archived data retention is just as carefully managed under GDPR. The ability to set up custom retention periods for data that is archived, with an archiving solution, is critical to a successful GDPR compliance strategy.
A key question to ask yourself is for how long we really need to retain backed-up data. Under GDPR, you should not retain data beyond the consented purpose and period. Balancing this with other regulations that require data to be retained for certain periods can mean managing multiple retention periods across your archives. A robust strategy to optimize data retention should be at the forefront of every GDPR compliance plan.
The research shows 57% of the data that is recovered from backups is less than 2 years old and 42% of that is only a year old. So why are you storing data for 5 years?
Production, archives, backups and sandboxes
The strategy for production data will be different from backups and also any data in sandboxes. We’ve discussed before how deleting Personal Data is not a trivial activity because of the complexity of object relationships in your Org. This complexity carries across the different environments you manage: the deletion strategy for production data may be different from backups and archived data, as well as any data in sandboxes.
You need to ensure that the solution you have chosen for backups, archiving or sandbox management can take into account these GDPR requirements. There are ISVs who specialize in backups and archiving; Odaseva and OwnBackup. They have been studying the GDPR Articles, thinking about the implications, and extending their apps to add in specific features to support these GDPR requests. Plus you get awesome back-ups. Did you know that a cost of data recovery request by Salesforce is $10,000?
Perhaps it is quicker and easier to blow away sandboxes and the rebuild them with data you know to be clean. The Elements.cloud Ref Model can help you compare the config (meta) data structures of sandboxes and tools like OwnBackup or SFApex can rapidly build sandboxes complete with data.
The deletion process
You may need a forms-based automation application such as FormAssembly to be able to capture the requests. You can use the web form to auto-populate a Case or custom object so you can track the request and the actions.
You will need to validate the request. Just because PJames@Zenalpha.com has made a request by email or filled out the Contact Us form on your website doesn’t mean you should blindly delete their data. How do you know that it is really Peter James making the request? Remember, it could be malicious attempt to bog down your operation by a competitor or action group. If Peter James is not an EU resident then they fall outside the GDPR so you could take the view that you are not going to support their request. But how do you know their residency?
Then you need to execute the request. That means delete the data, anonymize or say why you can’t delete it. And then produce a report of what you have done.
Finally, you need to format the response to send back to the person making the request.
You should also think about how you report on those requests that have not been fulfilled and may exceed the 30 day cutoff.
The example process diagram below has links (paperclips) to the related Article in GDPR. This diagram and those for the other requests are available in Elements.cloud free process mapping app.
The final word
Deleting data is required by GDPR but there are stringent rules to be followed and a myriad of considerations. Data is your life source. A poorly designed and executed deletion strategy could be life threatening. So, it is worth calling in the experts.
Resources
(in alphabetical order)
