1 – Find, Locate, & Document All Personally Identifiable Data
Building a data inventory is necessary so you know what personally identifiable data your company stores on individuals and all of systems that it is stored. Knowing what and where the data is stored will enable you to fulfill the six types of requests in the GDPR within the legally allotted response time of 30 days. It also ensures that you are able to handle requests thoroughly, accurately, and timely. This is a foundational step to GDPR compliance. Check out https://medium.com/@krisrivenburgh for more details.
2 – Provide Instructions for Staff & Process Map of How Each Type of Request Will be Handled
A process map with instructions is necessary for each of the 6 request types. This gives your company a game plan of what actions you will need to take in Salesforce and Pardot when you receive one of these requests. The six types of potential requests are outlined below. I’ve elaborated on a few of them and how you might handle them in Salesforce and Pardot.
Subject Access Request (a report of where you hold that person’s data)
This is pretty much the same request as a Right to Receive Person data (see below) except you don’t need to provide all of the data; just the locations, server information, etc. of where the data is stored.
Rectification Request (a request to update inaccurate data)
Consider implementing a customer facing capability where they can update their information directly. An internal master data management (MDM) utility where data can be updated in a centralized fashion and then synced across all of the business systems is very useful for handling this type of GDPR request. For Pardot and Salesforce this could mean having to update Salesforce (typically regarded as the master system in the Pardot-Salesforce integration). For fields that are not mapped between Pardot and Salesforce you may need to update them in Pardot directly.
Erasure Request (a request to delete all data you hold on a person)
At this time it is necessary to log a support ticket with Pardot support to fully purge Prospect Data. It is anticipated by May 25th that Pardot will release a self-service purge feature. Purging a prospect deletes all data including any tracked behavior such as web page visits, email opens/clicks, etc. Salesforce Sales Cloud data can be purged by deleting the record from the database (either via the user interface or a batch tool like Data Loader).
Consider implementing a consumer facing tool that uses the Salesforce and Pardot APIs to automatically purge data and sends the requester a confirmation email upon completion (contact us for more info). However you process your erasures ensure your step-by-step process is well documented.
Restriction to Process Data (a request to not actively process or use the data but not to delete it–most likely because they want to file a request to update it or are bringing a legal claim and don’t want you to delete evidence)
Utilize the archive feature in Pardot to stop processing data but the preserve it until further notice. For Sales Cloud create a custom ‘freeze/lock’ ability on the record so that the person can no longer be contacted according to the defined communication rules.
Right to Receive Personal Data (a request to furnish all personal data you have on a personal in a common readable format such as a CSV)
Both Pardot and Salesforce provide CSV export functionality. Again your step-by-step process map and instructions should detail how to handle extracting data from these systems to comply with Article 20, Right to Receive Personal Data.
One question that has arisen is if you need to provide the requester their tracked activities (i.e. Pardot Activities) as a part of this request. Pardot doesn’t seem to think so because they do not provide this information in their CSV export. However, this information can be retrieved via the Pardot API and is included in our full compliance offering.
If you have PII in Sales Cloud in addition to Pardot you will need to be able to easily export that person’s information. From the Sales Cloud side, people have asked if they also need to include related records such as chat history. Exporting related records using Salesforce’s standard export feature is pretty tricky and time consuming. If your interested in a compliance solution that exports all information from multiple systems feel free to reach out to us.
Right to Object
This goes along with an erasure request. I don’t really see anything specific to provide other than an acknowledgement and potential follow up for the person’s requested action.
3 – Requesting & Tracking Customer Permission and Consent
On your website it is necessary to activate the “Opt-in Preference by Country” feature in Pardot if you are using Pardot’s tracking code. This should be set up such that so when a website visitor comes to your site and they are located in a country that is governed by the GDPR they have the option to consent or decline to cookie tracking. Unfortunately, to my knowledge, there isn’t a way to automatically pass this feature a parameter. This would be useful to have if you already ask for consent for cookie tracking as a collapsable header on your website for European users, so that visitors only have to answer it once for all cookies — Pardot or otherwise.
4 – Defining Communication Rules for Operations & Record Keeping
Each time an individual gives you some sort of consent you should track that to ensure that only communicate with them via channels and on topics for which they have consented. This also allows you to prove permissions that have been given should the need arise. When a user gives consent, such as allowing cookies from your website, being added to your email newsletter via a form, or joining a email list by updating their email preferences via the email preference center you should track each of these items on the Lead/Contact record via a Communication Rule record. These Communication Rules are enforced automatically in the system so that you do not accidentally communicate with an individual on a topic or via a channel they have not consented. They also automatically update global settings as as “Do not call” and “Do not email” tracked on the Lead/Contact record.
5 – Identifying Individuals in Your Database to Whom the GDPR Applies
A common question that the GDPR has arisen for marketers is, “Do I need to re-run a permission pass for my European prospects?” You’ll get different answers when asking different lawyers. A conservative approach involves identifying your European prospects and validating their communication rules. If you’re only using email to contact prospects this is pretty easy because you can use the or Landing Page or even the Email Preference Center.
If you’re a global business you don’t need to run a permission pass for prospects located outside the EU. Location can be determined by many means including email domain, IP Address, and the Country field in Pardot. For European Prospects who do not actively opt-in it is recommended to archive their Prospect records until they re-engage with you.
6 – Deduplication of Salesforce & Pardot Databases & Setup of Duplication Rules or Implementation of the Individual Object in Salesforce
De-duplication of your Salesforce & Pardot databases is a necessary step to become GDPR compliant. For example, if an individual files a Right to Erasure but you have duplicate records for personally identifiable information on that individual, but only erase one of the records then you will be liable for monetary penalties and fines. In addition, Salesforce duplication rules should be setup correctly to ensure no duplicates enter your database moving forward.
If you Salesforce CRM has been setup to have multiple records in the database of the same person Salesforce has introduced a new object called “Individual” where you can link all records back to the single Individual record.
As alluded to in section 2 it is a good idea to have a game plan with respect to how you will receive and process GDPR related requests. Many companies are setting up email addresses such as firstname.lastname@example.org. However, it is not recommended to utilize the Case Management functionalities of Salesforce, particularly when handling erasure requests. It is sufficient to keep a record of the erasure request in email or legal letter, as well as, documentation that the request was processed and closed.
Disclaimer: This blog post should not be construed as consulting or legal advice, and no consideration has been exchanged to author this blog post.