Perfect CRM System For GDPR Compliance

Does GDPR mean I need to change my CRM system?

I attended the Salesforce world tour last week in my capacity as a Salesforce systems developer and administrator of our Salesforce instance which brought into focus for me something I’ve been banging on about for months.  Do CRM systems need to change to support GDPR compliance?

The reason I have been going on about this for some time is that if you do need to change or modify your CRM database system the two years preparation window is probably only just sufficient time to define, code, test and deploy the changes.  In this blog, I want to consider the evidential record keeping and audit trail implications of the Regulation and how that translates into database systems and architecture.  My experience as a Salesforce developer is useful in informing this blog.

GDPR and accountability

Perhaps the biggest single change in the GDPR when compared to the DPA is the requirement for accountability – for data controllers (and processors) to create and maintain sufficient evidence of compliance.  Article 5(2) states that controllers, “shall be responsible for, and be able to demonstrate compliance with, “the six data protection principles”.  Article 30 requires controllers and processors to, “maintain a record of processing activities under its responsibility” which at first glance appears to be in part the mechanism intended to replace the current requirement for data controllers to register with the regulator but I’m not so sure.  I read into it a broad requirement to maintain records about data processes and data processing per se.  Article 24 refers to controllers being able to “demonstrate that processing is performed in accordance with this Regulation” and there are more references within the 99 Articles and preliminaries that comprise the General Data Protection Regulation.

GDPR and CRM

When I put my Salesforce developer hat on and think about the structure of database records representing individuals I can’t help but start wondering how I might demonstrate for example when and from where I acquired each record.  I can’t help thinking about what I need in order to properly fulfil the right to be forgotten set out in Article 17 – surely I need to know whether I have shared a customer record with any third parties in order to be able to fulfil my responsibility to inform those parties of an R2BF request as required in Article 17(2)?  And when I think about the complications of consent brought about by the Regulation I begin considering how I would reflect a data subject’s objection to one form of processing but not another – surely I need to know what processing activities apply to each CRM record?

Contact Record

So imagine a contact record in a database.  My thoughts are that we need to know how the data subject got into our data systems.  Did we acquire the data directly or from a third party?  My take is that we need to know what privacy notice and/or what privacy information we provided to the data subject at the point of acquisition.  We need to know this for a variety of reasons not least of which is because we need to consider the lawfulness of processing in the event that we wish to extend the processing purposes.  Who signed up when?  What did we tell them when they signed up?  And because we may amend our privacy statements periodically and have different ones on different channels we need to know when the data was captured and via which acquisition channel.  My 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 we are under an obligation to provide them with a range of information set out in Article 14.  So to me it is important that we 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.  I’ve always thought about data retention in two dimensions: a) on a record-by-record basis, and b) at the field level.  What I really mean here is that a customer record may itself have a retention period but it may also contain information within its fields with varying retention periods.  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.  So I’m thinking that my ideal CRM system would perhaps allow me to set retention periods in each field.

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 we cannot verify they are not on the TPS suppression list.

And GDPR requires us to have greater control over retention by providing data subjects with retention information at the point of data capture.

Purposes

On a related matter, GDPR says that we may only process personal data for specific, explicit and legitimate purposes and when I used to build databases I often wondered what the fields on records were meant for.  Database fields have labels, names, and descriptions within the metadata but they don’t have a “purpose”.  Maybe my ideal CRM database could allow me to record in the metadata 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 related to good information governance controls?

Consent

Consent is an interesting concept too.  Most modern CRM database systems have Boolean flags to indicate opt-in or opt-out for calls and emails and in a database such as Salesforce, you can of course create your own additional Boolean fields.  So if I am a controller with some complex processing going on such as a social housing providing, a local authority, a professional football club, a charity even; I think that I might need to add more detail regarding the nature of the consent I’m handling.  What if a data subject wants to withdraw their consent for a certain type of processing such as direct marketing or profiling which they are entitled to do under Article 21; how are you going to reflect that in a database that doesn’t provide the ability to carry such nuances and detail?  And let us not forget that consent must be as easy to withdraw as it was to grant according to Article 7(3).

Going a step further what if you are processing information about under 16s now classified within the GDPR as children?  It is not just the child’s consent that you need but you also need the parent or carer’s consent what’s more Article 8(3) tells us that we need to make reasonable efforts to verify in some cases that it is genuinely the child’s parent giving consent and not young Billy’s 14-year-old mate!  How should we record parental consent in our data systems?

DSAR response

In relation to responding to data subject access requests where personal data have not been collected from a data subject GDPR says that “any available information as to their source” is to be provided (Article 15(g)).  Now I have personally chased down several junk email marketing companies to find out where they got my data from and on the whole – they have no idea and cannot pinpoint the exact source which is an extremely poor show and likely to not be compliant under the GDPR.  But what if the data subject has entered your data universe through several sources?

The right of access also includes, ”the recipients or categories of recipients to whom the personal data have been … disclosed”.  The easy route here would be a response simply setting out a bunch of categories of organisations that data may have been disclosed to such as, “marketing companies, shady telesales companies” etc. but surely the spirit of the Regulation is to know for sure each time a data subjects’ personal information is transferred to a third party?  And I can’t think of any other efficient way to do this other than to record each transfer against their CRM database record?

I could go on and on about this but hope to have sparked a thought as to whether your legacy CRM and other database systems are really fit for purpose or supportive of your obligations under the new General Data Protection Regulation.

Philip Brining 19^th May 2016