| Package: Compliance |
GDPR: Data Origination and Record of Access
Record Source Ownership and Usage
Contact Record
You need to know:
-
How the data subject got into our data systems. Did you acquire the data directly or from a third party?
-
What privacy notice and/or what privacy information we provided to the data subject at the point of acquisition.
You need to know this for a variety of reasons not least of which is because you need to consider the lawfulness of processing in the event that you wish to extend the processing purposes. Who signed up when? What did you tell them when they signed up? And because you may amend our privacy statements periodically and have different ones on different channels you need to know when the data was captured and via which acquisition channel.
Our bet is that people whose data was acquired via a Facebook competition, through our App, or our website, or via a form at an exhibition have all seen different privacy notices - and furthermore that these have changed and evolved over the course of time. It seems to me that we need to know which version of which Fair Processing Notice we provided to each data subject and importantly - does that information comply with the requirements in Articles 13 and 14? Another important consideration is if the data were not acquired from the data subject in which circumstances You are under an obligation to provide them with a range of information set out in Article 14. So to me it is important that You add this layer of metadata on to our CRM customer records in order to be processing personal data fairly, lawfully and transparently as required in DPP#1.
Retention
Now let's think about data retention in two dimensions: a) on a record-by-record basis, and b) at field level. For example the name and address is likely to have a longer retention period than say the market segment or a credit score, or a socio demographic indicator used in profiling or to predict some aspect of behaviour or which may become due for erasure under your retention guidelines. A trick I have used a few times as a Salesforce developer to aid PECR compliance is to hide from view a telephone number on a prospect record when the TPS date goes beyond a pre-set tolerance. This kind of programmatic control means that the phone fields on certain records become invisible to the sales team if You cannot verify they are not on the TPS suppression list. And GDPR requires us to have a greater control over retention providing data subjects with retention information at the point of data capture.
Purposes
On a related matter GDPR says that You may only process personal data for specific, explicit and legitimate purposes. Database fields have labels, names, and descriptions within the meta data but they don't have a "purpose". Maybe my ideal CRM database could allow me to record in the meta data the data processing purpose or purposes that a field relates to? In fact maybe the database architecture should revolve around the concept of data processing activities and data processing purposes: that every field and every object, every workflow rule and APEX trigger should have an explicit reason for being relating to good information governance controls?