The EU Data Privacy legislation, known as GDPR, is forcing companies that are processing EU resident data to revisit their customer data management with a “Privacy by Design” approach, which will mean re-engineering your Salesforce org and processes to accommodate the GDPR expectations.
Part 1 (your 30 day wake-up call) was an overview of what to focus on in your final 30 days before GDPR comes into effect. Digging into the detail of the 99 GDPR Articles (legal clauses) there are some specific requirements for responding to personal data requests that will be new to Salesforce customers, and therefore will require customizations to your Salesforce Org.
Articles 15-22 cover the 6 new Data Requests that a customer can make. Article 19 says you have 30 days after a Data Request to respond with a report to the customer of what you have done. Being unpredictable and potentially disruptive to your organisation means there is more reason to ensure the processes for these are well understood, clearly documented, and automated.
This post will cover:
- Recap: GDPR Data Requests
- How to Capture Data Requests
- How to Handle Data Requests
- Your Data Inventory: The Key Piece
- Deeper Dive: The Right to be Forgotten
Recap: GDPR Data Requests
Also known as Subject Access Requests, these rights to data and your obligations as a Data Controller are in Articles 15–21 of GDPR. In layman’s, these are:
- 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 (Article 17); “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 you 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 you holding their data because you have no reason to and that it be deleted.
How to Capture Data Requests
You need to think about how to capture the request. GDPR says it must be electronically; a web form or an inbound email which populates a Case or custom object. Delivering the requests within 30 days is a much bigger issue, at scale, unless you are organized.
This is a simple object but you need to consider how it will be populated automatically from a form on your website, incoming emails or manually added, particularly as the data volume increases. I suggest you set up a dedicated email [email protected] to make it easier to manage. You will also need reporting or notifications to alert you to any requests that are getting close to the 30 day deadline – so leverage the standard case management best practice here.
How to Handle Data Requests
Once requests are recorded in Salesforce, consider how you are going to act on each of the 6 requests that you can potentially receive.
Each of the 6 processes to deliver the Request should be mapped out in order to understand what is required for each. Luckily for you, we have already done the work. Below is an example of the “Right to be Forgotten” process:
The GDPR Process maps are freely available – there are over 12 – and you can access them by following these 3 steps:
Register for free with Elements.cloud
Go to ‘Spaces’ on the left menu bar and select the PUBLIC tab at top of screen and join the “Example: GDPR compliance” Space
Now you can access the process map, copy it and make it your own:
NB: The paperclips on the maps link to the governing GDPR Article and/or supporting notes.
These process maps are a starting point. You will need to take the process maps, review them and develop them for your specific obligations and team structure.
Your Data Inventory: The Key Piece
It all starts with building a data inventory so you know where Personal Data is held. You can build data inventory from your Salesforce metadata and then categorize the fields to mark which hold personal data. Knowing which fields are holding personal data will enable you to pinpoint this data, and pull the information quickly for processing, eg. using an installed 3rd party data management app to delete data at scale.
Here is an example of a data inventory created by Elements.cloud. The Salesforce metadata is synced nightly, ready for the Administrator to categorize each field using a drop-down menu. Some of the fields are pre-categorized by the sync to make life easier. But also it provides information on where a field is used (email template, reports, page layouts, in automation). In the next month, it will also have the Field Trip capability ie. % fields populated.
There is an added layer of information that GDPR requires for fields that are holding Personal Data or Special Data. Using a data inventory, you need to store the other information required by the GDPR such as the reasons you are able to hold the data (Legal Basis) and the retention period at the field-level. Remember, this needs to be kept up-to-date as you add or change fields.
Don’t forget about other apps outside of Salesforce that hold personal data. Now is the opportunity to get rid of spreadsheets and legacy apps, and migrate this data on to Salesforce to simplify data management – or you will have to build a data inventory for them too!
Deeper Dive: The Right to be Forgotten
“The right to be forgotten” is the Data Request that has got everyone talking. On one hand, there’s a reluctance to let go of data that was hard/expensive to acquire, and on the other hand, the difficulty of actually finding and deleting customer data makes admins shudder.
The data inventory built-in analytics show you how many fields have still not been assessed and how many fields hold personal data. By reporting on which fields hold personal data, you can implement automated data deletion or data anonymization programs.
You need to consider how you will delete the data and whether you build your own utilities or will need 3rd party apps to support you. The issue is that you don’t want to, and certainly don’t need to delete all their data. You shouldn’t just hit Delete on that Contact record. Here are some of the considerations:
- You don’t want to delete every related record; Case, Contract, Opportunity, Data permission. If you simply delete the Contact you will blow away these records.
- Do you need to keep the record for legal reasons, such as an ongoing dispute; GDPR allows for this and you can refuse to delete the record?
- Do you want to keep the data for analyzing trends? Again GDPR allows this provided there is anonymization.
So, you need a more sophisticated plan than just “Hit Delete”. You also need to consider what records are deleted and which are anonymized. Finally, customer data sits in backups – but maybe also in Sandboxes. Ouch. I’d forgotten about them.
Responding to the potential 6 GDPR data requests from customers could be a huge disruption to the business if it is not through ahead of time and planned for; web form to capture the request, custom object to track it, documented process of how to respond, and tools to deliver the report to the customer.
GDPR is not all cost, there are benefits. Building that data inventory of personal data fields will help you identify 3rd party apps/spreadsheets that can be migrated to Salesforce. And it will help you work out which fields on objects could be deleted, something you have been meaning to do anyway.
The Right to be Forgotten often gets the knee-jerk reaction of “Delete Contact” but a more sophisticated approach is required to ensure the ongoing operation of the business is not impacted.
Next, we will move on to building the new Salesforce objects and data model to make sure these requests and permissions are recorded correctly and in a manageable way.